window decoration for multiwindow mode

window decoration for multiwindow mode

[Ralf Habacker]

Hi, 
i just saw the xfree development page and recognized a missing feature in the 
multi window mode, which is is at least interesting for kde, but I assume 
also for other x applications.  

Currently the server does not handle modal dialogs like expected (currently 
modal dialogs are independed windows)  and does not support windows without 
regular windows title border. (This could be verifyed for example with 
kicker, the KDE panel, which is bordered with a regular window title, while 
it is shown without any additional border as expected using an X-window 
manager like kwin. 

The relating standards for this topic could be found at 
http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html

_NET_WM_WINDOW_TYPE, ATOM[]/32


 This SHOULD be set by the Client before mapping to a list of atoms indicating 
the functional type of the window. This property SHOULD be used by the window 
manager in determining the decoration, stacking position and other behavior 
of the window. The Client SHOULD specify window types in order of preference 
(the first being most preferable) but MUST include at least one of the basic 
window type atoms from the list below. This is to allow for extension of the 
list of types whilst providing default behavior for Window Managers that do 
not recognize the extensions. 


Rationale: This hint is intended to replace the MOTIF hints. One of the 
objections to the MOTIF hints is that they are a purely visual description of 
the window decoration. By describing the function of the window, the Window 
Manager can apply consistent decoration and behavior to windows of the same 
type. Possible examples of behavior include keeping dock/panels on top or 
allowing pinnable menus / toolbars to only be hidden when another window has 
focus (NextStep style). 

_NET_WM_WINDOW_TYPE_DESKTOP, ATOM
_NET_WM_WINDOW_TYPE_DOCK, ATOM
_NET_WM_WINDOW_TYPE_TOOLBAR, ATOM
_NET_WM_WINDOW_TYPE_MENU, ATOM
_NET_WM_WINDOW_TYPE_UTILITY, ATOM
_NET_WM_WINDOW_TYPE_SPLASH, ATOM
_NET_WM_WINDOW_TYPE_DIALOG, ATOM
_NET_WM_WINDOW_TYPE_NORMAL, ATOM


 _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a 
single window containing desktop icons with the same dimensions as the 
screen, allowing the desktop environment to have full control of the desktop, 
without the need for proxying root window clicks. 


_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window 
Manager would keep such windows on top of all other windows. 


_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and 
pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from 
the main application). Windows of this type may set the WM_TRANSIENT_FOR hint 
indicating the main application window. 


_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such 
as a palette or toolbox. It is distinct from type TOOLBAR because it does not 
correspond to a toolbar torn off from the main application. It's distinct 
from type DIALOG because it isn't a transient dialog, the user will probably 
keep it open while they're working. Windows of this type may set the 
WM_TRANSIENT_FOR hint indicating the main application window. 


_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen 
displayed as an application is starting up. 


_NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If 
_NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST 
be taken as this type. 


_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. 
Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be 
taken as this type. 

Re: window decoration for multiwindow mode

[Harold L Hunt II]

Ralf,

I believe Kensuke's new window manager for multi-window mode does this 
(the one that works with miext/rootless).  The code is not yet 
completely checked in, but check the archives for messages he has posted 
pointing to some test versions.  You can check out the code for the 
server from our xorg repository on freedesktop.org, but the xwinwm code 
is on Kensuke's personal site until I get it checked into the xclients 
repository.

I believe he may find this reference information useful, though.

I know that he based it off of another window manager, so he should be 
handling most of the ICCCM specs for window decoration, etc.

Harold

Ralf Habacker wrote:

> Hi, 
> i just saw the xfree development page and recognized a missing feature in the 
> multi window mode, which is is at least interesting for kde, but I assume 
> also for other x applications.  
> 
> Currently the server does not handle modal dialogs like expected (currently 
> modal dialogs are independed windows)  and does not support windows without 
> regular windows title border. (This could be verifyed for example with 
> kicker, the KDE panel, which is bordered with a regular window title, while 
> it is shown without any additional border as expected using an X-window 
> manager like kwin. 
> 
> The relating standards for this topic could be found at 
> http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html
> 
> _NET_WM_WINDOW_TYPE, ATOM[]/32
> 
> 
>  This SHOULD be set by the Client before mapping to a list of atoms indicating 
> the functional type of the window. This property SHOULD be used by the window 
> manager in determining the decoration, stacking position and other behavior 
> of the window. The Client SHOULD specify window types in order of preference 
> (the first being most preferable) but MUST include at least one of the basic 
> window type atoms from the list below. This is to allow for extension of the 
> list of types whilst providing default behavior for Window Managers that do 
> not recognize the extensions. 
> 
> 
> Rationale: This hint is intended to replace the MOTIF hints. One of the 
> objections to the MOTIF hints is that they are a purely visual description of 
> the window decoration. By describing the function of the window, the Window 
> Manager can apply consistent decoration and behavior to windows of the same 
> type. Possible examples of behavior include keeping dock/panels on top or 
> allowing pinnable menus / toolbars to only be hidden when another window has 
> focus (NextStep style). 
> 
> _NET_WM_WINDOW_TYPE_DESKTOP, ATOM
> _NET_WM_WINDOW_TYPE_DOCK, ATOM
> _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM
> _NET_WM_WINDOW_TYPE_MENU, ATOM
> _NET_WM_WINDOW_TYPE_UTILITY, ATOM
> _NET_WM_WINDOW_TYPE_SPLASH, ATOM
> _NET_WM_WINDOW_TYPE_DIALOG, ATOM
> _NET_WM_WINDOW_TYPE_NORMAL, ATOM
> 
> 
>  _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a 
> single window containing desktop icons with the same dimensions as the 
> screen, allowing the desktop environment to have full control of the desktop, 
> without the need for proxying root window clicks. 
> 
> 
> _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window 
> Manager would keep such windows on top of all other windows. 
> 
> 
> _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and 
> pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from 
> the main application). Windows of this type may set the WM_TRANSIENT_FOR hint 
> indicating the main application window. 
> 
> 
> _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such 
> as a palette or toolbox. It is distinct from type TOOLBAR because it does not 
> correspond to a toolbar torn off from the main application. It's distinct 
> from type DIALOG because it isn't a transient dialog, the user will probably 
> keep it open while they're working. Windows of this type may set the 
> WM_TRANSIENT_FOR hint indicating the main application window. 
> 
> 
> _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen 
> displayed as an application is starting up. 
> 
> 
> _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If 
> _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST 
> be taken as this type. 
> 
> 
> _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. 
> Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be 
> taken as this type. 
> 
> 

Re: window decoration for multiwindow mode

[Kensuke Matsuzaki]

Hi,

A new window manager XWinWM handles Motif WM Hint and Blackbox hint,
and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox
doesn't use _NET_WM_WINDOW_TYPE atom.

I have to supprot EWMH, but XWinWM has preblem on more basically
window management (Move, resize, iconify etc). So now EWMH
compliance's priority is not high for me.

Test version is here.
http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz

-- 
Kensuke Matsuzaki
mailto:zakki@peppermint.jp
http://peppermint.jp

Re: window decoration for multiwindow mode

[Ralf Habacker]

On Sunday 04 January 2004 01:10, Kensuke Matsuzaki wrote:
>Hi,
>
>A new window manager XWinWM handles Motif WM Hint and Blackbox hint,
>and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox
>doesn't use _NET_WM_WINDOW_TYPE atom.
>
>I have to supprot EWMH, but XWinWM has preblem on more basically
>window management (Move, resize, iconify etc). So now EWMH
>compliance's priority is not high for me.
>
>Test version is here.
>http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz
>
Thanks for this info. Can't say, when I can take a look at this, but I will 
see probably after the kde 3.1.4 release.