В Срд, 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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
