Re: Other window managers

[Christopher Armstrong]

Hi Wolfgang

On Mon, 08 Nov 2010 16:00 +0100, "Wolfgang Lux" <wolfgang.lux@gmail.com>
wrote:
> > 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?

Eric's response was correct for this - we plan to have some sort of
toolbar, but we could devise another solution. I'm not attached to
whatever we end up wanting to implement.

> > 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.

> > 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. 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. 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 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.

Cheers
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au