Re: Comments on 1.0pre3/pre4
- From: "Matthias Clasen" <Matthias Clasen poet de>
- To: <wm-spec-list gnome org>, <Sasha_Vasko osca state mo us>
- Subject: Re: Comments on 1.0pre3/pre4
- Date: Wed, 1 Nov 2000 16:35:49 +0100
----- Original Message -----
From: <Sasha_Vasko osca state mo us>
To: <wm-spec-list gnome org>; Matthias Clasen <Matthias Clasen poet de>
Sent: Wednesday, November 01, 2000 16:00
Subject: Comments on 1.0pre3/pre4
> So Here is the proposed
> description :
> The names of the first N desktops. This is a NULL spearated list of
> in UTF-8  encoding with an additional NULL at the end of the list.
> This property MAY be changed by a Pager or the Window Manager at any time.
> Note: that N could be different from _NET_NUMBER_OF_DESKTOPS. If it is
> _NET_NUMBER_OF_DESKTOPS - then all the desktops with numbers greater then
> are considered to have no names. If N is greater then
> then names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be
> in case number of desktops is increased.
> Rationale: Names are not nessessary attribute of the virtual desktop. As
> the result
> this list of names could be empty, shorter or longer then number of
> desktops without
> any impact on Virtual Desktop functionality. Since names are set by users
> and users
> are likely to preset names for fixed number of desktops - it does not make
> to shrink or grow this list when the number of available desktops changes.
Very clear now, thanks. This should be included.
> > And a list of allowed values for _NET_SUPPORTED (although I strongly
> > question the usefulness of _NET_SUPPORTED):
> As was noted before Selections mechanism is much more standard and
> way to implement that. Since this topic is still under disscussion - may
> it would be better to change specs to use Selections ?
With a widely-deployed implementation (KDE2) of the stuff described in the
current spec and considering it is named 1.0pre3, I think it would be unwise
to change this now. But we should try to clarify what clients can expect
to find out via _NET_SUPPORTED.
> > What about windows which can't be maximized or shaded (e.g. because they
> > are
> > not decorated with a titlebar) ? This information is not currently
> > available
> > to pagers/taskbars, so they can't remove the corresponding items from
> > their
> > menus.
> That calls for another property, similar to MWM_FUNC_* and MWM_DECOR_*
> from Motif hints, which would list all the functions that could be
> on window :
> Resize, Move, Minimize, Maximize, Close
> Althou it is kinda redundand, since some of it can be set via standard X
> properties :
Yes, the one I mainly had in mind is shading, but it would also be useful to
prevent a pager from offering to move the panel.
> > _NET_WM_ICON_GEOMETRY Is this really a good idea ? It feels very hackish
> > to
> > expect the WM to display an animation, but not handle the icons. I'd say
> > we
> > should rather add instructions for detecting the window transition from
> > normal
> > to iconic state by third-party apps. Then the iconbox can handle the
> > animation
> > itself.
> Perhaps "Icon Hijacking" mechanism ? When Window Manager iconizes app
> and maps its Icon - Iconbox comes into play and "steals" the icon from
> reparents it into its own window. It is kinda implemented in most
> apps, like Wharf etc. But some special communications are needed in order
> WindowManager to keep such iconized window in the list of clients.
> if you swallow an icon - WM considers this app to be withdrawn and removes
> from the list of client.
Now this sounds very dangerous. According to the ICCCM, clients are not
to do much with the icon windows provided by the WM. But I don't see how the
ICCCM would imply that stealing the WM-provided icon window initiates a
to withdrawn state. But most serious, the WM-provided icon window may not be
for the iconbox, since it contains WM decorations and may not be of the
I think the cleaner solution is what we have now: the iconbox instructs the
to not display icons.
] [Thread Prev