Motif Hints [was: Re: Fwd: Draft 1]

[Matthias Ettrich <ettrich troll no>]

On Mon, 21 Jun 1999, Michael Rogers wrote:
> > NO NO NO, this is a common missunderstanding and many wms get it wrong.
> > WM_TRANSIENT is a hint meant for normal dialogs. It may be slightly less
> > decorated (for example there's no need for an iconify or maximize button) but
> > it should have all handles required to move/resize it.
> > 
> > DECORATION_TOOL is something like the small tools with titlebar known from for
> > example CorelDraw. 
> 
> How often is this going to be useful? Full-sized window decorations are
> full-sized for a reason - if they were any smaller they would be
> difficult to use.

Well, put it this way: It's pretty common on MS-Windows. The tool windows are
still reasonable usable with the mouse _and_ look clearly distinct from fully
decorated windows. Since they are usually used over the main window (they stay
on top, of course), the reduced titlebar saves spaces.

Personally, I like this feature. Support for it is trivial: it's one line in
the specs and it's still just a hint. I.e. the WM can chose not to obey it and
use a full decoration instead.


> 
> > TINY is almost like DECORATION_NONE but has a small frame
> > around it (no titlebar) so the window can be resized/move with the window
> > manager.
> 
> So basically it's exactly like a transient window!
> This could also be specified by switching off all MWW decoration hints
> except BORDER.

yes, you are right, but.... (see below).

> 
> > If we have all this, there's absolutely no need to do without DECORATION_NONE,
> > even if the old MOTIF hints offers a way to achieve this.
> 
> I think everything that's really necessary in the new proposal could be
> achieved with MWM hints, and applications would not have to be updated
> to use a new set of hints.

I don't see many applications that make acutal use of the MOTIF hints, in
particular the no-decoration hint. If it's gnome applications you are talking
about, I assume the hints are encapslutated in a nice API anyway, so changing
is trivial without even touching a single line of code in the apps.

You are right, we can achieve quite some things with the MWM hints. But I
somehow don't like them, they don't feel right and I think that they don't fit
into X.  The main problem is, that they are not logical hints, but purely
visual ones. They define for example, whether or not a window should have a
minimize button. Now, a dialog should IMO never have a minimum button. So I
would program my toolkit in a way that dialogs don't set this hint. Isn't that
slightly weird? Shouldn't we rather define classes of windows and let the
window manager decide how to decorate them and how to present the window to the
user? 

If I - as a user - prefer dialogs with a huge maximize or close button, I want
to tell this my window manager and get the desired effect. That means: the
hints of the applications will regularly be ignored anyway.

I'd say, it's the task of the window manager to define the look and feel of the
windows. The applications should give logical hints, what kind of window it is.

Apart from the this, the motif hints are not complete: there's a CLOSE or
STICKY button missing, for example.

Matthias




> 
> 
> Michael Rogers
> 
> 
> -- 
> To unsubscribe: mail wm-spec-list-request@gnome.org with "unsubscribe"
> as the Subject.