[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Other window managers
|
From: |
Wolfgang Lux |
|
Subject: |
Re: Other window managers |
|
Date: |
Mon, 15 Nov 2010 18:57:50 +0100 |
Christopher Armstrong wrote:
I started to implement click-to-focus, but I've noticed that when
you transfer focus away from a non-GNUstep application and then back
to GNUstep, it ignores the first mouse click in the window after it
has been focused. I confirmed the behaviour with lwm too (note that
it can't be replicated in WindowMaker, as it explicitly disables
click-to-focus for GNUstep apps). I tracked this down to the window-
ignore_take_focus flag. What problem does this flag solve, and can
it be removed?
This flag is just there to implement the OpenStep/Cocoa semantics
without help of the window manager. In general windows are supposed
to
ignore the click by which they are focussed. While some window
managers (e.g., WindowMaker) can be configured to not send the mouse
click that focusses a window to that window, this obviously interacts
badly with windows that are configured to process the first click
into
the window. In an environment where we do not have control over the
window manager, there is hardly an alternative to this
implementation.
Okay, this is as I thought - the globally active focus model that
GNUstep uses is incompatible in every sense with click-to-focus,
because
it deprives GNUstep of the ability to make focus decisions based on
where the mouse was clicked. I guess if a window manager set the
timestamp field to be the same as the button press that caused it, we
might be able to detect the differences between a click in the
headline
bar and a click in the window (and just ignore WM_TAKE_FOCUS when we
know about the button press). In this case WM_TAKE_FOCUS this might
work, but I doubt it all WMs would implement it this way. This stuff
all
works on Cocoa because the title bar is part of the window (and not
the
window manager) and it receives the click that determines the focus.
I think the point is that GNUstep tries to implement the click-to-
focus model all on itself by trying to become key/main window when a
mouse click is received (except in panels with -becomeKeyOnlyIfNeeded
== YES). What you are asking for looks like separating mouse event
processing from activation, i.e., on one hand NSWindow's -sendEvent:
should not call -makeKeyAndOrderFront: and on the other hand the
backend probably should not ignore WM_TAKE_FOCUS. The problem that I
see with such an approach is that it would be extremely difficult to
properly implement the semantics that the mouse click which activates
a window is ignored in general, but handled when the view being
clicked on responds YES to -acceptsFirstMouse:, since the order in
which an application receives the mouse event and the WM_TAKE_FOCUS
event is undefined.
Secondly, I'm using EWMH window type hints to distinguish windows so
that I know how to decorate them. GNUstep really isn't
distinguishing normal windows from palette windows and inspectors
(at least not in Gorm). I know this is a difficult issue, and I
spent some time looking into how we can improve this. The Cocoa API
makes it difficult, because it only allows windows to configure how
they look and behave, not what they are or what they contain.
Why don't you use the _GNUSTEP_WM_ATTR property to determine the
window style and level? The EWMH hints are essentially derived from
this information and trying to recover this information from the EWMH
hints seems a wasted effort.
I've had a look at the files that Eric suggested about this hinting
mechanism. Unfortunately, it confirms my doubts about successfully
using
it. Like the windows backend and the x11 backend for EWMH hints, I
would
still need to create heuristics to work out what type of window
something is. As Eric said, panels don't have to use
NSUtilityWindowMask, and I've already observed that they can become
main
and key like normal windows.
A panel cannot become main window unless the programmer explicitly
overrides -canBecomeMainWindow in an NSPanel subclass, which would be
a rather odd thing to do. And if the programmer deliberately did so,
it may be questionable whether the panel still should be considered a
utility window. So, I wouldn't care much about this possibility and
consider testing whether a window responds NO to -canBecomeMainWindow
a reasonable heuristics to identify utility windows.
About the only things that I can think of
that a utility window should always have is that they can't be
minimised/miniaturised and they hide on deactivation.
In general you are right, but some attention panels may be configured
to not hide on deactivation. I think this heuristics is not as good as
testing -canBecomeMainWindow.
The latter could
easily be added as a flag in the GNUstep window hints. Setting
WM_TRANSIENT_FOR on dialog boxes and windows that hide when the
application deactivates would also be helpful. This hint would mostly
resolve the problem for me and provide better information for other
window managers.
I agree that setting WM_TRANSIENT_FOR for windows that should hide on
deactivation would be a good idea, but I don't think that it solves
your problem (see above).
I was also hoping to avoid replicating the heuristics in GNUstep's x11
backend in yet another place and in a slightly different manner, and
going through EWMH would provide a way for GNUstep to vary the
manner in
which it decides what a window is without dictating to the window
manager how it should render, and leaving the WM to try and resolve
the
mismatch. The GNUstep hints are very similar to Motif hints, and Motif
style hints (that specify what buttons to put on the titlebar and
how to
render it) were rejected in EWMH to allow window managers to decide
their own policy based on a window type (such as normal, dialog,
utility, etc). But, it really doesn't matter, because I can just
implement heuristics as we have been discussing.
Wolfgang