Re: Handling Qt/KDE widgets within Gtk+ message loop

["Dmitry M. Shatrov" <erdizz rambler ru>]

В Срд, 15/06/2005 в 16:02 -0400, Tristan Van Berkom пишет:
> Dmitry M. Shatrov wrote:
> [...]
> > Given that I'd like to ask:
> > 1) Should I deeply mix Qt and Gtk+ main loops so that all of the
> > functionality is implemented? e.g. gtk's 'init' and 'quit' functions
> > that are queued and executed in gtk_main etc. Are things such as
timeout
> > handling and ability to insert additional GSources critical for
plain
> > Gtk+ programs?
> 
> My gut tells me that you need to handle all event sources all the time
> if you want the program to function properly.
> 
> > 2) If the whole X Window freezes, couldn't it be an XEmbed
> > implementation issue?
> 
> The whole window or the whole server ?

The whole X freezes, there's only a static picture and a responsive
mouse cursor. Clicking anywhere does nothing. The keyboard is lost too,
but I still can switch to text console.

I've compiled a test with Qt and Gtk+ main loops running simultaneously
in two different threads as usual without any penetration. And the
results were just the same - the program freezes in the cases described
above. These cases do not raise if I do not use XEmed widgets, so it
should be that.

I've also ran a sample program that goes with qtxembed tarball called
"swallow". It embeds a window with a specified window id into its own
window. Here is the test (it doesn't involve gtk+):

1) I compile a sample program that shows a kpdf part widget as its
toplevel. Then I get its winid with xwininfo and type it in 'swallow',
then press a button to do embedding. My kpdf widget appears inside
swallow - everything works. This is non-XEmbed embedding, as I
understand.
2) I make a change: create QtXEmbedClient widget and add kpdf part
widget into it as a child. QtXEmbedClient widget is then shown. But when
I try to embed it into 'swallow' it hangs! This time only the area
inside 'swallow' is non-responsive, though it is evident that kpdf tried
to draw something there. Original 'swallow' buttons still work.

So I conclude this IS an XEmbed issue. I hope I use it properly, as I
simply follow the instructions in QtXEmbed docs to build a client and
use a pre-shipped sample program as a container.

My intermediate results are:
1) Something is wrong when I use one thread and mix message loops, so
that the whole X freezes
2) Something is wrong when I use two threads, one for Qt and the other
for gtk+, still the whole X freezes
3) There is an issue with embedding even if I use Qt-only widgets in
different processes.
In all three cases it looks like a problem raises in the same cases,
especially when I embed a KParts::MainWindow that is probably advanced
enough to trigger a bug.

In overall it looks like the problem raises if I do something special
(maybe, try to show a tooltip or do something else) inside a widget that
is participating in XEmbed link. I'll try to catch a strict crash-case
this weekend.

I can't conclude anything still as I'm not familiar enough with X
internals. My first impression is that XEmbed is a protocol for two
processes to speak and Xserver is only slightly involved. Now I'm going
to look at a specification at freedesktop.org etc. to understand what is
there inside. I feel that I'm in already, you now :)

What about thread mixing, two simultaneous message loops seem to be
responsive enough. I just haven't notice any difference, so this is a
real and practical option.

> IMO This project seems highly experimental, begs for disaster and
> laughs in the face of reason, in other words; I love the idea
> and wish you the best of luck in your noble cause :)

Oh, thanks. Simply when I decided to learn how to write a true GNOME app
and figured out that there are so many opinions on the subject.. Well,
the cost of the choice is too high today. You write either for GNOME or
for KDE and your code cannot be reused in both simultaneously. There
should be such opportunity.

Regards, Dmitry