21 Oct
2002
21 Oct
'02
2:58 p.m.
On 19 Oct 2002 09:22:13 +0100, Steve Harris wrote:
look, there are ways to do this, but they are a mess. people have
managed to integrate GTK+ widgets into Qt programs with a design like
this, but if you read the white paper on this (sorry, no URL handy)
the code is full of hack after kludge after hack to deal with nasty
situations that arise. i read the paper full of optimism and came away
feeling like i had to wash my hands.
On Fri, Oct 18, 2002 at 11:37:46 -0700, Josh
Green wrote:
does anything speak against opening a second socket and connecting to X
(so X Server sees two clients) then knowing the ID of the X window the Please enlighten me, what was the problem then
with multiple GUI
toolkits? IIRC it had to do with not being able to integrate multiple
applications together very well (at least as far as the user interface).
Its to do with the X event loop. Only one toolkit can receive the events
and the others just sit there. Some tollkits can be made to play nicly
(eg. GTK1.2 IIRC), but not all, and maybe not in a standard way. plugin window could be swallowed into the host.
you'd have to have some way of querying the plugin to know *which*
event loop it needed ("are you a
GTK[1|2]/Qt[1|2|3]/FLTK/XForm/Motif/... plugin?"). which event loops
will you support? what if the plugin wants a different one?
basically, none of the existing toolkits save GTK+ (which is making
moves in this direction but isn't there yet) are written to be used in
situations in which they are not the "first receiver" of X
events. they just don't have the code structure to support:
while (1) {
ev = XGetNextEvent();
loop = find_event_loop_by_window (ev->window);
loop->dispatch (ev);
}
this kind of thing totally messes up their multiplexing of timeouts,
other file descriptor I/O etc. into their central event loop.
you could consider a design on their part. or not. whatever you think
of it, its what we've got for all of them.
--p