[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Other window managers
From: |
Christopher Armstrong |
Subject: |
Other window managers |
Date: |
Mon, 8 Nov 2010 22:36:55 +1100 |
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).
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?
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.
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.
Thanks
Christopher Armstrong
carmstrong@fastmail.com.au
- Other window managers,
Christopher Armstrong <=