XEMBED: Preventing focus loops

[Andreas Aardal Hanssen]

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. This is
where we get the

if (version >= 0.5) sendXEmbedMessage(a);

and

case XEMBED_MESSAGE_X:
  if (version >= 0.5)
    processMessage();
  else
    issueWarning();

>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) :-).

>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.

>If we did something like that, it allows a somewhat more free-form
>extension of the protocol. We could even do dynamic assignment
>of message numbers:
> 0x00010000 - 0x0001ffff: messages for first extension
> 0x00020000 - 0x00020000: messages for second extension
>Though there is some definite question of how fancy it makes sense to 
>get here.

Of course. But since the possibilities are so many, and considering that
the protocol spec today works fine in most cases and even has GTK+/Qt/Wine
implementations, I think it's the right time to do research like this on
how to enhance the protocol.

If a suggested enhancement doesn't make sense, we can just discard it. :-)

Regards, Andreas

-- 
Andreas Aardal Hanssen