Re: Proposal: _NET_WM_STATE_MINIMIZED

[Havoc Pennington <hp redhat com>]

On Fri, 2004-06-25 at 16:48, Lubos Lunak wrote:
> 
>  But shaded window == SHADED !HIDDEN breaks the purpose of HIDDEN - shaded 
> windows shouldn't be visible in the pager (and in general, I think a shaded 
> window should be considered to be hidden - you can't see the contents after 
> all, just like you don't see them when minimizing to icon or taskbar, 
> although in all cases you can see something, be it the titlebar, icon or 
> taskbar entry).

That seems logical.

> > For apps though they generally *should* want to know it's hidden, not
> > that it's minimized to taskbar.
> 
>  I actually think apps shouldn't care about that at all.

Yeah, I tend to think that too but of course app authors never agree.
Both Qt and GTK export this information I'm pretty sure.

> > Reiterate this. The spec needs to specify things in a lot of detail
> > here, and specifically address taskbar vs. WM vs. applications/toolkits.
> 
>  Actually I think the spec should say in more places what's intended for apps 
> and what's intended only for desktop components communication. E.g. if you 
> look at the FAQ of the Ion WM regarding the EWMH 
> (http://www.mail-archive.com/ion%40list.rt.fm/msg01199.html) I think it's 
> quite obvious the Ion author didn't get this and considers EWMH full of 
> useless over-engineered crap, although without it e.g. Metacity wouldn't work 
> very well with KDE.

He seems to be against the whole idea of GNOME/KDE ;-) and he's right
that EWMH encodes much of the basic UI model of GNOME/KDE in the spec.
In my opinion this is unavoidable though for the pager/taskbar to WM
interaction, again justifying STATE_MINIMIZED_TO_TASKBAR as you say.

I do agree with you, we could probably sprinkle in a good bit of "this
should not be used by apps/toolkits" type of comments. The stuff
apps/toolkits are using needs to remain as policy-free as possible.

> > > > I guess we're at the point where someone needs to draft the
> > > > implementation note for the spec, specifically noting what WM, task
> > > > bar, *and* applications should do. It should also define what the old
> > > > WM_STATE style hints mean, on startup, and when apps try to change
> > > > them, and when the WM sets them.
> >
> > Need to do this ;-)
> 
>  Agreed. Now, who's going to be the brave soul to do that :) ?

I'm traveling the next week. ;-) It should be pretty easy though since
we seem to have consensus.

Havoc