Re: Decorations (again)



On Tue, 16 Nov 1999, Michael ROGERS wrote:

> >I hadn't noticed that we had dropped the Desktop and Dock categories.
> >Sorry.  I think that they should be categories, as they are two distinct
> >types of window that require special treatment.
> 
> I see the categories as visual rather than functional descriptions, hence the 
> undecorated category. Functional categories would be nice, but we would have 
> to specify a large number of categories to accomodate all possible
> behaviours. 

I don't think you can seperate visual and functional descriptions.
Indeed, if we do, how have we improved on the MOTIF hints?

I understand that we need to compromise being offering enough categories
to categorise all windows, and offering few enough to be easily
implementable.

> The combination of visual categories and layer hints allows more
> versatility - for example, instead of adding a "pinnable menu" category, we
> can combine "toolbar" decorations with the "on top" hint.

And end up with the pinnable menus from toolkit A setting the "on top"
hint and the pinnable menus from toolkit B not - inconsistent behaviour
from pinnable menus - hooray.  If it's a pinnable menu, call it a pinnable
menu, and let the WM decide where it gets stacked.

> I think a combination of the "undecorated" visual category with the 
> "below/desktop" hint is enough to distinguish desktop features from other 
> windows. Docks might need their own category because the WM will probably 
> want to keep them in the same place when the viewport is scrolled. However,
> they are not visually any different from other undecorated windows, so it
> might be better to add a "sticky" hint (no stacking order connotations 
> intended). This would also allow decorated windows to request this behaviour.

Hmm.  As I see it, the only one of our "categories" that cannot be
construed as functional, as well as visual, is the undecorated category.
This is why I felt that it should perhaps be a hint, rather than a
category.

> >As for only needing 3 layers, what I meant was that a normal window should
> >only be able to hint itself into three different positions - normal,
> >ontop, below.  We are no longer prescibing how many "layers" there should
> >be.  Instead, we tell the WM what *types* of window we have (using the
> >categories above) and the WM can sort them into internal "layers" as (and
> >if) it sees fit.
> 
> I don't think we need layers to allow application windows to be kept on top 
> or kept below according to the user's preference. As Dominik has pointed out, 
> that option is best provided by the window manager. 

Yes, I now agree..

> However, layer hints allow an application to specify that a window is
> *not* a normal application window, and should be stacked differently
> *by default* (eg pinnable menus, desktop shortcuts).

I think that applications should indicate that it is not a normal window
by means of a *functional* hint.  I do not believe that functional
descriptions are unworkable - in fact I believe our current category list
comes close to being exactly that.  I think functional hints have a lot of
useful, extra functionality to offer.

Paul



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]