Re: Quick question about spec



On Tue, 22 Feb 2000, Tim Janik wrote:
> On Fri, 18 Feb 2000, Paul Warren wrote:

> > > Window Movement
> > > 
> > > According to the ICCCM, applications should not see unnecessary differences
> > > between running with or without a window manager. Therefore window movements
> > > for already mapped windows, such as ones requested by
> > > XMoveWindow(Display, Window, X, Y) have to move the window Window to the
> > > coordinates (X, Y) and not cause the window's window manager frame window
> > > to end up at (X, Y).
> > 
> > Yep - sounds reasonable.  There is clearly confusion over which of the two
> > alternatives is "correct", hence different WMs implement it differently.
> > Far more important than getting it right is making it consistent.
> 
> well that, or demand non-compliant wms to set a property. but i'd much prefer
> simply mandating ICCCM compliance with the wm spec doing some clarification on
> that issue.

I definitely for mandating ICCCM compliance, and if that means deciding
what ICCCM compliance actually is first, then so be it :-)

> > > > o Expand on write up of _NET_ACTIVATE.
> > > 
> > > what was that for?
> > 
> > Sorry, that should be _NET_ACTIVE_WINDOW, and more specifically the
> > degrees of activation, as described on:
> > 
> > http://www-jcr.lmh.ox.ac.uk/~pdw/wm-spec/wm-spec-1.9d/x55.html
> > 
> > What is the purpose of the degrees of activation?
> 
> i don't know, who braught that issue up?

I think it was Dominic Vogt.  I think that the idea is that a pager can
specify in what manner the user wants the pager to "activate" a window.

For example, focus it, but only if it is on the current
workspace, but that kind of thing can be done without such a message, so I
don't really see why it is necessary.

> > > > o Context help - implement basic protocol for WM to invoke context help on
> > > > client window.
> > > 
> > > has anyone suggested an implementation for that at all?
> > 
> > Yep, Matthias suggested a wm protocol.  See:
> > 
> > http://www.gnome.org/mailing-lists/archives/wm-spec-list/1999-December/0006.shtml
> > 
> > and Owen Taylor then suggested adapting the xdnd protocol to this
> > purpose:
> > 
> > http://www.gnome.org/mailing-lists/archives/wm-spec-list/1999-December/0008.shtml
> > 
> > I'm not familiar with the xdnd protocol, but what he suggests sounds
> > good - allowing the application to give some feedback as to whether the
> > user is going to get any help when they click.  
> > 
> > We never got any feedback on this idea.  I would like to include both
> > possibilities - the Matthias' suggestion is pretty simple to implement
> > on the WM.  The best way to do Owen's suggestion involves the WM
> > implementing some of the Xdnd protocol, which I suspect some WM authors
> > would be reluctant to implement.  It would be nice to have the first
> > protocol as a fall back for the second.
> 
> i'm not so sure specifying two protocols is a good idea. 

Yes, I had rethink and figured that two protocols was probably bad.

> we've had some lengthy discussions on this on gnome-hackers and on
> irc, and basically something like the Xdnd protocol is required for
> sane context sensitive help (having no feedback is really annoying for
> newbies, and they are actually the ones that need this feature the
> most). however, you also have a valid point with wm authors may be not
> willing to implement the required overhead, at least not at this
> point.

I had a quick look over the Xdnd protocol, and AFAICS there it would not
take a lot to implement.  We need to standardise on a particular
mime-type, and a client property to indicate that a window wants to
receive context help messages.  Possib/ly a way to indicate that the WM is
willing to play the context-help game, too.

> so because this issue hasn't yet been finally settled, my personal
> feeling is, we should leave it out of the spec for now. we can still
> have an addendum at a later point.

Yeah, probably the best idea.

yours,

Paul



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