mouse focus flag [was: Re: Re: Re: Re: [AD] minor fix]

[Elias Pschernig <elias@xxxxxxxxxx>]

[minor edit compared to the previous reply]
On Wed, 2004-07-07 at 08:13 -0500, allegrovp@xxxxxxxxxx wrote:
> > A has D_WANTMOUSE set, so it will keep
> > the focus, even when B is clicked
> > in the area where they overlap. But
> > that's the opposite of what you were
> > saying.. you wanted the little bits
> > (B) to be clicked. That already
> > happens with Allegro anyway - it loops
> > through all dialogs any takes the
> > topmost one.
> 
> No, I want the bottom one to have the
> mouse, as the top one is just a simple
> decoration: it draws stuff, but it is
> only aesthetic (well, not really, but in
> this example it doesn't matter).
> With Allegro, as you say, it would also
> take the mouse, which I don't want. I
> mentionned non rectangular widgets as
> it is a useful thing you can do with it
> (and my actual widget is actually non
> rectangular (it has a large "hole" in
> the middle, where the map (the bottom
> widget) shows)).
> 
> D_WANTMOUSE just tells the dialog player
> that if any other widget lies over it,
> then don't give it the mouse (except if
> it also says D_WANTMOUSE).
> 

But it's not doing that with your patch. As soon as one widget has the
mouse, no other can get it:

+         if (res & D_WANTMOUSE) {
+            mouse_wanted = 1;
+            mouse_object = c;
+         }
+         else {
+           if (!mouse_wanted)
+               mouse_object = c;
+         }

> My case is further complicated by the
> fact that the decoration widget is also
> clickable, but out of the map boundaries
> (for scrolling) :) I shouldn't have
> mentionned it, as it muddies the waters
> quite a lot, sorry about that.
> 

Well, the problem is, without mentioning that, I'd have told you to set
the decoration to D_DISABLED - so again only the map would get the
focus :)

The solution is, you should use two widgets in your GUI. One for the
input focus, which comes *before* the map dialog (so its input works
exactly like you want), and one with D_DISABLED set, which is *after*
the map, so it overlaps.

This is also what you would have to do in any other GUI - splitting
drawing and input order just isn't something that makes much sense in
general.

If you make a patch so the non-transparent overlapping parts
of the widget in front can be clicked, and other clicks can be let
through to the map widget below, then I will gladly accept such a patch.
So a widget could say, depending on the position it was clicked, "yes, i
agree, I was clicked" - or "no, i wasn't clicked, give the click to
someone else". (And somehow I think that's what you had in mind, but
found too tiresome to implement ;)

-- 
Elias Pschernig