XEMBED: Preventing focus loops

[Owen Taylor]

On Fri, 2003-08-22 at 15:49, Andreas Aardal Hanssen wrote:
> On Fri, 22 Aug 2003, Owen Taylor wrote:
> >> A big however must be that both embedder and client implement the _exact_
> >> protocol, and never (1) send undefined messages with type _XEMBED, never
> >> set undefined properties on a window with type _XEMBED_INFO, and never (2)  
> >> extend the protocol by using unused fields in defined messages.
> >>Defined and undefined refer to the protocol version in use.
> 
> >I'm not sure I understand how this last paragraph correlates with 2 -
> >first you say that "messages... are sent regardless of the version
> >mismatch". Then you say clients must never send undefined messages
> >where defined refers to protocol versionm in use.
> 
> Okay, I'll rephrase it: 
> 
> I meant that either 1 or 2 must be used.
> 
> Either (1) the client and embedder be allowed to send the _XEMBED messages
> that they should send, considering the version that they implement, in
> which case the client and embedder both must discard any _XEMBED messages
> they do not recognize. The idea here is that I use any additions and 
> enhancements I have in my embedder, not caring what protocol version the 
> client supports. This will work fine, because the client will just discard 
> what it does not recognize.
>
> Obviously, the requirement for this to work is that there is a common
> minimal set of features that allows basic functionality.
> 
> Or (2), they must only send messages that correspond to the protocol
> version that they have agreed on using (min(myversion, peerversion). In
> case (2), it makes sense to treat unrecognized messages as bugs. 

[...]

OK, yes, that makes sense.

> >Also, note that the the requirement is more precisely, not that:
> > - Every message that a embedder/client sends must be defined in
> >   the spec
> >But rather:
> > - Every message ID used must be reserved in the spec so that it
> >   cannot be confused with another message.
> 
> I would like the constraint that it is not allowed to make up a message
> like XEMBED_DO_MAXIMIZE under the message_type _XEMBED. So that _XEMBED is
> considered a protected range of messages.
>
> >As an artificial example, we could for example, say in the
> >spec that message IDs from 0xf0f00000 - 0xf0f0ffff are reserved
> >for Qt-specific extensions, and then Qt could send them without
> >needing to define each message in the spec.
> 
> But in this case, could not Qt define a different message type called for
> example _XEMBED_QT? Instead of having Qt specific extensions end up in the
> spec (which is not optimal) :-).

That's equivalent certainly. Let me use a less hypothetical example
for what I meant. In order to fix up GTK+'s usage of message ID's 108
and 109, I don't
need to:

 A) Stop using those message IDs
 B) Make their definitions part of the spec

All I need to do is:

 C) Say in the spec that they are used by GTK+

> >Another thing to think about in this context is Denis Mikhalkin's
> >proposal for allowing a list of XEMBED capabilities/extensions:
> >https://listman.redhat.com/archives/xdg-list/2003-March/msg00071.html
> 
> This is very interesting. IMAP has this feature too, and IMO it works very
> well.

It certainly brought IMAP to my mind as well.

Regards,
							Owen