[haiku-development] Re: click-through and AmigaOS mouse mode (patch)
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 07 Mar 2009 22:22:40 +0100
Hi,
> ----- "Stephan Assmus" <superstippi@xxxxxx> wrote:
> > I always found that whole behavior a bit strange. It looks to me like
> > Be first decided that windows needed to be active to receive any mouse
> > events. Then later they found that awkward during use, and instead of
> > fixing it, they introduced B_ACCEPT_FIRST_CLICK. Which is probably
> > what Tracker is using. (Tracker windows are perfectly normal windows,
> > only the desktop window uses a special window flag unavailable to
> > regular apps, but only so it always stays bottommost.)
>
> Tracker windows indeed use B_ACCEPT_FIRST_CLICK. However, in a lot of
> places in the Tracker source code, windows are explicitly being brought to
> front on a click, scroll or drag. Also in interface-kit/MenuBar, the window is
> explicitly activated on a click. I believe this is not the right place for
> this and prevents the implementation of the AmigaOS mouse mode unless I
> make Tracker aware of the different mouse modes. The latter does not seem like
> a good idea.
>
> I have removed the explicit activation of the windows from Tracker and
> MenuBar. Of course, behavior for the other mouse modes has changed as a
> result. Do we want to mimic BeOS behavior or do we want a consistent interface
> (Tracker windows act like any other window)?
When watching people use BeOS/Haiku, who are not very familiar with it, they
will very often click a menu bar to make the window come to the front,
especially if the machine is already configured to FFM mode.
I don't think that changing this traditional behavior is such a good idea. I'd
rather have these places actually check the mouse mode.
[...]
> I found it quite counter-intuitive how to detect when the user releases
> the RMB while still holding the LMB. This is because the message does not
> contain information on which mouse button was released but only on
> which mouse buttons are still being pressed. Is there a better way?
There was a decision in BeOS to not generate B_MOUSE_DOWN events for additional
buttons when the mouse is already pressed. I think I've asked that once on the
BeDevTalk list. Haiku copies this behavior and I believe a lot of applications
could be confused, since they do not check the specific button in
MouseDown()/MouseUp(). However, each MouseMoved() event does contain a bit
field of the buttons, so that you can still detect when other buttons get
pressed additionally, or released while others are still pressed. So yes,
that's the way and there is no better way. :-)
[...]
> > That would be me, I guess. :-) Dirty regions are to be taken
> > literally. These exist only during the time that the app_server knows
> > a region of a window needs to be repainted, until the client has
> > repainted them. Your initial guess of comparing the visible region
> > with the full region should have worked. You can just use the
> > operator==() of BRegion to compare them.
>
> That was the idea :) There is not operator== in BRegion however. I didn't
> quite feel up to adding it however. Will two identical regions report the
> same Rects? I'll have a go at it later.
Oh, there isn't? We should add that. Yes, BRegions are deterministic. In
another words, if you add the same rects to two BRegions in different order,
then iterating over the resulting rects will produce the exact same rects in
the same order for both regions. The original Haiku implementation was not like
that, but at least Dano's was. I don't think the BeBook makes claims to these
effects. But anyways, it's like that on Haiku. operator==() could be
implemented with memcmp() on the region data.
Best regards,
-Stephan
Other related posts:
