[haiku-development] Re: click-through and AmigaOS mouse mode (patch)
- From: Brecht Machiels <brecht@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 7 Mar 2009 21:28:29 +0100 (CET)
Hello,
----- "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)?
> > In the current state of the AmigaOS mouse mode, windows can still be sent
> > to back by means of the right mouse button. Windows can be brought to front
> > by holding LMB and pressing RMB. I was hoping to enable sending a window
> > to front while dragging a window, but I did not manage to pull it off. Is
> > there anything else registering whether a window is being dragged other than
> > fIsDragging in app_server/Window? Keeping fIsDragging true enables
> > continued dragging, but when moving the mouse too fast, the pointer leaves
> > the
> > window decorator and the window is left behind. When later moving over the
> > window again, the window will stick to the pointer again (until we move the
> > mouse too fast again). I'm thinking there must be an
> > 'fIsPointerStuckToWindow'
> > somewhere? Or maybe I'm just missing something.
>
> I've tried to grasp the changes by looking at the patch, but I should
> probably see them in more context to understand what is going on and
> what exactly you tried to change and why it didn't work. The current
> mouse target is also maintained in the Desktop class, but I don't
> think it has anything to do with dragging a window. But it's possible
> that sending a window to the back has some side effects that interfere
> with what you were trying to do.
Uncommenting the bit of commented code in app_server/Window::MouseUp() will
enable the bring-to-front while dragging.
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?
> > Another option would be to only use the RMB. When a window is in front it
> > will be sent to back when pressing RMB. When they are in the back, they
> > will be sent to the back. This is not hard to implement. However, when a
> > window is not in the front-most position but still fully visible, it's
> > counter-intuitive to send it to the front, as the user will see no apparent
> > change.
> > I tried using the windows' visible region and the full region, but there is
> > currently no easy way to compare regions 'by value'. I also thought of
> > checking whether a window had dirty (overlapped) regions, but it seems that
> > this is not what a dirty region is in app_server/Window. Perhaps someone
> > familiar with the app_server code can shed some light on this?
>
> 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.
> I've read through it and you've done a very good job of sticking to
> the coding style and you did the changes in all the right places.
I think these are both the direct result of copy-and-pasting the mouse mode
code. However, I appreciate the comment :)
> I would change the name of B_AMIGA_MOUSE mouse mode to describe the
> behavior though. Like B_NO_AUTO_FRONT_ON_ACTIVATION or something along
> those lines.
Yes, explicit it better. I'll change it.
Regards,
Brecht
Other related posts:
