XEMBED: Preventing focus loops

[Owen Taylor]

On Thu, 2003-08-21 at 09:39, Andreas Aardal Hanssen wrote:
> Owen,
> 
> On Thu, 21 Aug 2003, Owen Taylor wrote:
> >My proposed solution to this is to define the currently unused data1
> >of the XEMBED_FOCUS_IN, XEMBED_FOCUS_PREV and XEMBED_FOCUS next
> >messages as a flags field, with currently one flag defined:
> >#define XEMBED_FOCUS_WRAPAROUND         (1 << 0)
> >When sending one of these messages, the flag is set as follows:
> >(...)
> >All other bits in the field are unused and must be set to zero.
> >Notes about the proposal:
> > * The only difficult thing about implementing this proposal
> >   is detecting when XEMBED_FOCUS_NEXT causes a wrap-around
> >   at the toplevel. It required some hackiness to implement
> >   in GTK+. I think most toolkits will be similar - a bit
> >   hacky to do but possible.
> 
> I second this suggestion. Implementation of this feature in the current
> work on updated XEmbed support in Qt is trivial. I'm pleased to see a
> simpler solution to this problem than the serial number / response message
> sketch in the issues section.

Thanks for the feedback

> > * I didn't up the protocol version because it is a highly
> >   compatible addition - there is nothing you would do
> >   differently if you knew that the other side didn't
> >   understand XEMBED_FOCUS_WRAPAROUND.
> 
> I agree in the sense that this suggestion solves a "bug" in the original
> specificaion (although it was mentioned in issues in 0.5). However keeping
> the version number usually suggests there are no changes.

The specification version definitely increases with each change 
(my patch increased it to 0.6) The question is the protocol version. 

What the spec currently says about the protocol version is:

_XEMBED_INFO.version:

        The version field indicates the maximum version of the protocol
        that the client supports. The embedder should retrieve this
        field and set the data2 field of the XEMBED_EMBEDDED_NOTIFY to
        Min (version, max version supported by embedder). The version
        number corresponding to the current version of the protocol is
        0. [Should the version be defined as (Major << 16 | Minor) ?]


XEMBED_EMBEDDED_NOTIFY.data2:

        The protocol version in use (see the description of
        _XEMBED_INFO).
        
Which defines pretty clearly how it is set. But what does it mean?

 - Is a client/embedder allowed to send messages to the other
   end that are not defined in the protocol version in use?
   Are clients required to ignore messages they don't understand?

 - Is a client/embedder allowed to fill in fields that are undefined
   in the protocol version in use?

If we allow both of these, then I don't have much trouble simply
increasing the protocol version for every change. Even if we 
take the (Major << 16 | Minor) interpretation, that's still 65,535
minor revisions we can make.

But I don't want to force implementors to clutter up code with:

 if (version >= 1)
   flags |= XEMBED_FOCUS_WRAPAROUND;

type checks unless they are really necessary. Sometimes you want
to check the version to determine some fallback action, but I 
don't see a useful fallback action here.

Regards,
					Owen