Re: Comments on 1.0pre3/pre4

----- 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 [1] 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
> then
> _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
> reserved
> 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
> sense
> 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
> performed
> 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
WM -
> reparents it into its own window. It is kinda implemented in most
> swallowing
> apps, like Wharf etc. But some special communications are needed in order
> for
> WindowManager to keep such iconized window in the list of clients.
> Currently
> if you swallow an icon - WM considers this app to be withdrawn and removes
> it
> 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
right size,

I think the cleaner solution is what we have now: the iconbox instructs the
to not display icons.


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