Re: Comments on 1.0pre3/pre4



> > > 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.
> > 
> > I'm sure such
> > hints could be compatibly added in a later version of the spec, if
> > people are loath to add any more features at this stage.
> 
> Yes, I just wanted to point out the need for this. 
> Any ideas how this could be done ? 
> I had thought about having the WM put a _NET_SUPPORTED property 
> on each toplevel to indicate what commands it will accept for the window.
> It may be less burdensome to use a _NET_NOT_SUPPORTED property though.

I had more or less the same thoughts.  The main question I think is
which atoms it makes sense to include.  Looking through the spec, I'd
say those you mentioned are the only ones that make sense:

_NET_WM_STATE_MAXIMIZED_VERT
_NET_WM_STATE_MAXIMIZED_HORZ
_NET_WM_STATE_SHADED

The alternative is to have "reverse" versions of each of these;
something like 

_NET_WM_STATE_NOT_MAXIMIZABLE_VERT
_NET_WM_STATE_NOT_MAXIMIZABLE_HORZ
_NET_WM_STATE_NOT_SHADEABLE

and just throw them into the _NET_WM_STATE array.  But that may tempt
application authors to treat them as requests that they can set before
mapping; whereas really it's the WM's job to determine these.
eg. Maximize-ability would depend on both the maximum size hints and
the size of the current _NET_WORKAREA.

Ouch...  That makes me think: if _NET_WORKAREA is smaller than the
hinted maximum size of such a window, the window is maximised, then a
strut disappears and _NET_WORKAREA gets bigger than the hinted maximum
size, what would be the proper thing to do to that window?

There's no terribly nice answer to that -- enlarge it, ignoring the
maximum size hint?  restore it to its previous size?  (user wonders
why that happened...) keep it at the same size, but no longer
maximized? (user can no longer restore it...) keep it the same size,
and still consider it maximised?  (user wonders why hitting the
maximise button restores it) -- any of these would provide a poor user
experience.  

Perhaps all windows that set maximum size hints should be considered
unmaximizable... there are not really a lot of them anyway; it is
almost always used to indicate non-resizability (max-size==min-size);
and most of them are things like gkrellm, that no-one would even
consider maximising.  If we accept that approach, then there is no
need to explicitly set a property indicating that maximisation is not
supported; taskbars can infer it from reading WM_SIZE_HINTS.

But we'd still need a not-shadeable hint, and for extensibility
_NET_NOT_SUPPORTED would get my vote (for what it's worth).

-Rob





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