Re: comments on current spec

[Paul Warren <pdw ferret lmh ox ac uk>]

On Thu, 27 Apr 2000, John Harper wrote:
> Paul Warren writes:
> |> _NET_ACTIVE_WINDOW
> |> 
> |> 	should the client message also select the desktop/viewport the
> |> 	window is a member of?
> |
> |Do you mean so that a pager can change the desktop of a window?
> 
> No. I didn't explain myself very well. The draft spec says that an
> application should send this client message to ``activate another
> window''. My point is that the meaning of ``activate'' isn't clear to
> me.
> 
> I guess the removal of the ``degrees of activation'' thing has caused
> this confusion

Indeed.  Degrees of activation was intended to specify this - whether a
window on another desktop/viewport should be focused when activated, by
switching desktop/viewport.

> Presumably the intention is just to focus the window, but this may also
> require activating the desktop that the window is a member of (e.g.
> since unmapped windows may not be focused, and desktops may be
> implemented by selectively unmapping windows)
> 
> So I think the spec should either say that ``activating'' the window
> may not have any effect if the window is not in the current desktop or
> viewport, or that the current desktop or viewport may be changed to
> allow the window to be activated.

Yes - Unless someone would like to argue for the reinclusion of DofA then
it should be at the WMs discretion what happens to off-desktop windows.

On the other hand, if a pager asks to "activate" a window this should be
because the user has explicitly asked to work with that window, in which
case switching desktops to make it visible would seem like the correct
behaviour.

> |> 	also, if allowing resize grab position to be specified why not
> |> 	add the possibility to restrict the movement to a single
> |> 	dimension?
> |
> |I think that this should be left to the WM eg. some WMs might restrict
> |movement of a SIZE_RIGHT resize to one dimensions, others might allow
> |vertical resizing if you drag outside the (extended) boundaries of the
> |window.
> 
> Again, I didn't make myself clear. I meant that if you have the
> capability to define resize characteristics, then it seems logical to
> allow the same for move characteristics (e.g. to request movement in a
> solely vertical direction)
> 
> On the other hand, I'm not sure why an application would need to use
> either of these messages anyway, perhaps it should be left to the user
> to initiate interactive move/resizes?

The point of these messages is that an application can set aside a region
of the window to act as a size-grip (think triangle in bottom right hand
corner of Windows apps) -- the corner of a window is particularly hard to
grab with a mouse.  The move/resizes are still initiated by the user, but
it is left to the WM to actually do the resize so that the behaviour can
be consistent with the WM's normal resize behaviour (eg. opaque or
outlined, showing window co-ords, edge-resistance etc.)

One thing that has just occured to me is that these sizegrips will not
give the same on-mouse-over cursor feedback as the WM's sizegrips.  Hmm.  
I guess this is somewhat inevitable when you start doing things like this
which attempt to blur the X model of a rectangular client area.  
Personally I don't find sizegrips useful - being able to Meta+Right click
in a window is far easier...

As for making movement directional:  There would only be 3 directions -
horizontal, vertical and both.  I'm not sure I can think of a situation
where this would be in any way useful, but if we do seperate the move and
resize messages then we could add these cleanly.

> |Yes.  I would recommend _NET_[WM_]_STATE_STICKY_DESKTOP, and change the
> |existing STICKY to STICKY_VIEWPORT.
> 
> That would be great.

OK.  Are people happy to use the freedesktop CVS as home for the spec?  
Seems like a good plan to me, but I don't want to start changing stuff
there if anyone (Matthias?) is working on a seperate copy.

> |It would be good if this, and any other implementations by members of this
> |list, could be linked to from the spec.
> 
> That's fine, though the code may not be too useful to others (it's
> written in Lisp and may require some knowledge of the sawmill internals
> to be understood)

I think it will still be useful as an example of how the spec is to be
implemented.  Even if the code itself is not reusable, I suspect that most
people will be able to read and understand it.

Paul