[haiku-development] Re: click-through and AmigaOS mouse mode (patch)
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 06 Mar 2009 11:05:54 +0100
Hi,
> As a means of introducing myself to the Haiku source code, I decided to
> add a click-through option. When this is enabled, mouse clicks will
> register also in non-active windows. This enables closing an inactive
> window without having to activate it first, for example.
>
> I have also added an extra mouse mode to the list of FFM modes to simulate
> AmigaOS mouse/window behavior. This basically is the same as the default
> Haiku behavior, but When a window is activated it is not brought to front
> automatically.
>
> I have noticed that tracker windows behave differently than other windows.
> A tracker window's scroll bar will not respect click-through, for one. On
> the other hand, a click on a file listed in an inactive tracker window will
> always select this file (= click-through), also when click-through is
> disabled. As for AmigaOS mouse-mode, tracker windows will always pop to front
> on activation when clicking inside the window contents. I am assuming the
> tracker windows are implemented on a lower level than 'regular' windows? I
> also assume this is not the intended behavior?
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.) Maybe there are cases where an application wants the user to be
able to click anywhere without actually doing something to bring the window to
front first. But that should have been the other way around
(B_DO_NOT_ACCEPT_FIRST_CLICK). Maybe I am missing something, though.
> 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.
> 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. Any region with "content"
in the name refers to the region inside the window that the client application
can draw to. But otherwise window regions in the app_server refer to the full
region, ie including the decorator. So to know whether a window is overlapped
by another, you would use GetFullRegion() and compare that with VisibleRegion().
BRegion fullRegion;
GetFullRegion(&fullRegion);
if (fullRegion == VisibleRegion()) {
// Window is not overlapped.
}
The reason that the full region is not cached, is because it is usually
irrelevant. The method is usually used during calculating the visible region,
and to do so, the full region is used as a starting point.
> I have added the extra fields to the Window preferences applet.
> Unfortunately, I'm afraid its font sensitivity is now even more broken than
> before. I
> didn't spend much time trying to fix it however, as I understand all GUI
> code should be changed to use the new GUI layout kit?
Yes, that's preferred whenever touching the old code. :-)
> I have attached the diff of the changes that I have made. It not cleaned
> up and still dumps debug info in the syslog. I simply included it here
> for who wants to give it a try.
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 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.
> As for inclusion in the Haiku tree. I think the click-through feature
> will be appreciated by a lot of people. I'm not sure the same is true
> for the AmigaOS mouse mode, though. I will just hope that there are
> some Amiga fans among the powers that be :)
IMHO, the click through feature should just replace the old behavior, it's one
of the reasons I could never use Haiku if FFM didn't exist. I don't see why
having to click a window twice on the close button to close it is helpful. That
being said, I use Haiku in FFM mode, so this should better be discussed among
non-FFM mode users. :-) I believe the window decor behavior should just be
changed to always accept the first click.
Best regards,
-Stephan
Other related posts:
