xembed test example, gtk-client sending strange message

[Owen Taylor]

On Tue, 2003-08-19 at 04:33, Andreas Aardal Hanssen wrote:
> Hi, there.
> 
> I'm testing gtk-client.c in the xembed-0.5/tests dir with my xembed 
> embedder. My client plugs right in, no problem. But if I try gtk's 
> client with my embedder, I see strange results.
> 
> Compiled the client with gtk+-2.2.2 using RedHat's 3.2.2 20030222 gcc
> compiler.
> 
> gcc -I /home/andreas/opt/gtk+-2.2.2/lib/gtk-2.0/include -I 
> /usr/include/atk-1.0 -I/home/andreas/opt/gtk+-2.2.2/include 
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I 
> /home/andreas/opt/gtk+-2.2.2/include/gtk-2.0 gtk-client.c gtk-common.c 
> -L /home/andreas/opt/gtk+-2.2.2/lib -lgtk-x11-2.0 -o gtk-client
> 
> I start my embedder, then run:
> 
> ./gtk-client 0x4200007
> 
> The first that happens is that gtk-client sends 6 XEMBED messages to my
> embedder, whose l[1] field has a value of 108, which doesn't really make
> any sense to me.

To quote from gtk+/gtk.h:

/* Non standard messages*/
#define XEMBED_GTK_GRAB_KEY             108
#define XEMBED_GTK_UNGRAB_KEY           109
 
And the issues section of the spec:

 Complexity of accelerator handling
 The current specification for accelerator handling is a little complex.
Most of the complexity (the accelerator IDs) comes from the need to   
 handle conflicting accelerators. GTK+ currently implements a simpler 
 scheme where grabs are identified only by key symbol and modifier and
 conflicting mnemonic resolution doesn't work across embedder/client 
 interfaces. 

Before trying to implement what I wrote down in the spec for
XEMBED_REGISTER/UNREGISTER_ACCELERATOR I was waiting to get some 
feedback from the Qt people in particular, but that never happened.

If you don't care about accelerator handling, you can ignore the
GTK_GRAB_KEY/UNGRAB_KEY messages. If you want to interoperate
with GtkPlug/Sockett, then you can also implement them, I won't change 
the way they work. 

The fields data1/data2 are as described for REGISTER_ACCELERATOR 
(You should note that <Control><Shift>a is sent as <Control>A and so forth.) 
detail is always 0. There is no equivalent to XEMBED_ACTIVATE_ACCELERATOR; 
accelerators are just forwarded as keystrokes.

> I also get no ReparentNotify, the event catch to initialize the client. So
> my questions to this list are:

You don't get a ReparentNotify because GTK+ simply creates the window
inside the parent - 

 Implementations may choose to support an alternate method of beginning 
 the protocol where the window ID of the embedder is passed to client 
 application and the client creates a window within the embedder, or  
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
 reparents an existing window into the embedder's window.

Regards,
					Owen