Christopher Armstrong wrote:
Hi all
I'm trying to write my own window manager for Etoile :-). GNUstep
integration is extremely important, but the way we are trying do
some things, vs the way that GNUstep operates is causing some
conflicts. I was hoping that I might get some advice on these issues.
The first thing is using GNUstep with click-to-focus mode. We need
click to focus in Etoile for normal application windows because we
don't have title bars and allow the user to move windows when they
don't have the focus by just dragging them (none of this applies for
palettes or inspectors, which are traditionally decorated).
Just curious, how can you close or miniaturize normal windows if they
don't have a title bar?
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.
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.
There are some things we could possibly use:
* Style masks - these say whether a window has a close button, title
bar, minimise etc. we could say that windows without minimise flags
are "utility" windows.
* -[NSWindow canBecomeMainWindow] and -[NSWindow
canBecomeKeyWindow]. Although panels by default cannot become main
windows, this doesn't always help. For example, Gorm allows its
palettes to become main.
* -[NSWindow hideOnDeactivate] - as silly as it sounds, this one is
quite good because only normal windows don't hide on deactivate.
* window levels - not entirely useful, because palettes and other
auxiliary windows don't need to use NSFloatingPanelWindowLevel.
* The class type of the window (e.g. NSWindow, NSPanel, etc) -
probably not the best idea again, because a NSWindow subclass can
behave like a panel.
I'm happy to prepare patches and test any proposed changes for these
things.
Before starting to patch -back (let alone -gui), first try to get
things done with the _GNUSTEP_WM_ATTR property. If things are missing
there then we might discuss how back could provide you that information.
Wolfgang
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
