Re: GNOME wm hints proposal (Draft)

[Marko Macek <Marko Macek snet fri uni-lj si>]

raster@redhat.com wrote:

> the above is pointelss except for the decorations - all of that is
> already part of X's ICCCM standard and already able to be supported by
> WM's

I agree except for miniicons. See my mail for WIN_ICONS proposal.
 
> E will have much more advanced support than this as of E0.14 - I won't
> go into detail but suffice to say users will configure windo borders on
> a case-by-case basis - or by classes or instances or by properties (ie
> tranisent, chaped, title bar regexp's, size, etc) They wil be able to
> add or delete window border buttons bu dragging and dropping them on or
> off the window borders. E will have a large set of butotn classes liek
> you suggest "close" "minimise" "kill" etc. etc. wiht user defined
> action classes that normally do what is ecpeted (unless the user
> modifes the action class to for example left button minimises, right
> button kills for the minimise action class - or of they are goofy enuf
> they can make left button run xterm and middle button pop up an alert
> box saying "Blumfrub" and make any other buttons do nothing on the
> minimise button action class - it's all the user's choice)

Well, in a well designed/implemented system user should not have to 
configure ANYTHING unless they have some very special needs
(and the wm provides this capability). Decent default decorations set,
icons, ... MUST be specified by applications. If every user has
to configure this, you have the same inconsistent interface X has
now.

> ->  GNOME_DECOR_BORDER lets the wm know if a window wants a border.
> 
> just open the window wiht overrid-redirect flag turned on and u have
> this irrespective of the WM.

Doesn't really work.
 
> ->  GNOME_DECOR_FLOAT is used to indicate that a window is a tear-off
> ->  menubar or toolbar. A window manager may decide to not decorate or
> ->  WinListSkip a floating window.
> 
> same as above.

Not really. A note here: IMO applications that implement application
modal windows (Qt does this) by raising a window whenever user
clicks on some other application window (or even worse if if just
moves the mouse over the application) are severly broken. This 
behaviour is just annoying. Instead there should be a wm hint
that is set in this case.
 
> ->  The miniicon and minimask fields specify an icon and its mask that may
> ->  be used for the system menu button of a window, or an entry on a
> ->  start-button style menu if one is not using the panel and its menu.
> 
> This needs a much more intelligent system than X's pixmap+mask - E
> specifically refuses to honor this for one reason - 99% of X apps
> provide either no icon, or the ugliest icons on the planet.

A agree. We need a way for application to provide more than
one pixmap+mask.
 
> This needs a more intelligent system wherby pixmaps arent limited to the
> size the application provides. often icons provided (see xfig's for an
> example) are way too big for most icon areas - or some are too small,
> or B&W - but you dont want to limit icons to a set size either the user
> should define their preffered size).

We need policy. Like: require icons of 16x16,32x32,48x48,64x46 in 8,24
bpp.
Scaling doesn't really work. It would be nice if there was a system 
for scalable icons like there is for colors, but I'm not aware of one.

> ->  The gnomegroup field can be used to hint to a wm that a window is a
> ->  dialog or tear-off of a main app. A wm can be configured to minimize
> ->  all windows in a gnomegroup when the main app is minimized. Or if the
> ->  main window is moved to another desktop, all of the dialogs will
> ->  follow. The gnomegroup field holds the xwin id of the main window (the
> ->  leader). The leaders gnomegroup field holds its own id. For dialogs
> ->  that need to remain semi-independent of the main app this can be set
> ->  to their own id.
> 
> already in X's ICCCM group leader stuff - read the Xlib programmers
> guide from o'reilly and the X11R6 addendum - it's all in there.

Can you tell me if there is a documented way to do application modal 
dialogs (they stay on top of all app windows). AcroRead does this and I 
will implement it soon in icewm, but I didn't find it documented
anywhere.
 

> actually here's a hint:
> apps use imlib for icons.
> WM sets an atom HINt as to the range of sizes it will accept for icons
> (actually better it just sets THE size - the app may aspect correct to
> fit in that rectangle though -(and a hint as to whihc aspect shoudl be
> used for aspect correction should be given) and the app shoudl then
> provide pixmaps scaled to this size - the wm can broadcast
> clientmessages for apps to re-provide (re-scale) their icon pixmaps if
> the user changes preferences mid-stream. I will be putting this kind of
> stuff into E 0.14 - it will accept a comprehensive array of hints and
> it will boradcast to all client top-level windows via client messages
> hints as to what to do next.

We need to agree on a standard first. Making a new set of wm hints
in each WM makes things worse.

There is an icccm hint WM_ICONS_SIZES which can do some of this, but 
it is not quite enough. Applications could listen for a change in this
item and reset their icons accordingly.
 

Mark
-- 
... MouseDevice "/dev/null"
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si      http://ixtas.fri.uni-lj.si/~markom/