Re: Can I mix Xlib and Gtk+ in one app?



>The question to solve was to mix Xlib ang gtk+ though it may not make any
>sense. It's not correct to answer a possibility question simply by: You
>are stupid if you think about that, 'cause you won't need it.
>
>Ok, Xlib is wrapped by gdk. No problem, but what's about old motif code
>that I want to embed into a new gtk application. 

Old Motif code is not Xlib code. Its Motif code. It operates at the
same level of abstraction as GTK+ (widgets) rather than those of Xlib
(windows, drawables, areas).

>						  It would be very hard to
>wrap any request with gdk. The answer shouldn't be that you don't
>appreciate such problem. I don't think that gdk catches my motif events,
>from an existing application loop, when I insert some gtk windows to it.

I've probably spent a lot more time thinking about cross-toolkit
integration than you imagine. Its a critical and central problem in
the Linux audio development community in which I am extremely active.

Any time someone wraps a GUI system in a layer that includes an event
loop, they have created a toolkit that is somewhat inimical to
integration with other toolkits that include their own event
loops. There's nothing inherently bad about that - its just a fact of
this kind of design. Its true on Windows just as much as it is with X
Window. There are questions about how easy they make it to add new
entities created using the lowest level of the GUI system (here,
Xlib). Some toolkits make it impossible (they have no notion of
foreign windows), some make it possible but fragile (they don't
properly handle all events delivered to foreign windows) and some
contain extensive and ugly hacks that make it completely workable
(such as the KParts integration of GTK+ into KDE apps).

GTK+ (and GDK) mostly fall into the middle category. 

     gdk_window_foreign_new() 

is a useful helper function to know about. but you will find that, at
least in GTK+ 1.2, it does not offer perfect integration. it may have
improved in the 1.3/2.0 series code.

>In fact I have done this with a qt window that I integrated into a motif
>application last year. It wasn't very hard to do so. I simply had to
>select the qt controlled windows and dispatch qt events for them.
>Everything else was done by motif. That worked with just one display.

Then perhaps you should use Qt.

--p



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]