Re: Work in Progress: draft 1.9a

[Marko Macek <Marko Macek gmx net>]

Matthias Ettrich wrote:
> 
> On Sun, 04 Jul 1999, Matthias Ettrich wrote:
> > On Sun, 04 Jul 1999, Marko Macek wrote:
> >
> > [snip]
> >
> > Thanks for your work Marko (I'm, unfortunately, running a bit out of time).
> >
> > Regarding decorations: Didn't we agree on dropping the DECORATION hint and use
> > the Motif hint instead?  At least someone argued heavily for that and finally
> > convinced me.
> >
> >
> 
> Hi (again),
> 
> after reading more about the MWM hints, I changed my mind once again, I'm
> afraid. I don't mind how motif does the decoration hint, but I don't like its
> tight connection functions and inputMode. For those not familiar with MWM, the
> hint is basically a struct
> 
> struct PropMotifWmHints
> {
>   int      flags;
>   int      functions;
>   int      decorations;
>   int      inputMode;
> };
> 
> Anyone out there who knows more about inputMode? I read a reference to "modal"
> so I assume it has to do with modal dialogs.

> Do we need something like this? At first, I thought: yes, we do. But now I

Is there a reason to replace MWM hints? IMHO both MWM_HINTS, and
MWM_MENU should be supported (I still have to implement menus in icewm -
I only plan to implement user menu items and use the default icewm
window menu for the wm operations).

> think ICCCM handles that just fine: applications with modal dialogs should
> request the WM_TAKE_FOCUS protocol and take care themselves that the modal
> dialog gets the focus.

One thing usefull in MWM hints is that a WM can prevent the parent
window from being focused by default.
 
> Back to the MWM hints. The idea to put all window hints in one struct, is
> right. I suggest we do exactly the same with all application window properties.
> 
> So there should be one _NET_WM_HINT property, containing a big struct (plus a
> flag member, I guess).

We need two properties:
- One for hints only set by application. 
- Second one for hints where application sets the default and WM then
updates.

I propose the following format instead because of extensibility:

(CARDINAL[]/32 format)
<atom><count><data>...

Atom is the type of the property.
count is # of longs following the header

If this is OK, I will update my draft to mention this. (It doesn't
change the meaning much).
 
> Rationale: notable speedup when mapping windows. Remember: each single property
> requires one roundtrip between the window manager and the X-Server.
> Transporting larger amounts of data is cheap, but the roundtrips really matter.

I agree about speed.

Mark
-- 
... GUI: WPS.
------------------------------------------------------------------------
Marko.Macek@gmx.net                 http://www.kiss.uni-lj.si/~k4fr0235/