>> The problem isn't making chrome easy. It isn't the available >> widgets. Its the presence of an event loop that is incompatible >> with another toolkit. At least, thats the problem that I see and >> was referring to. [ ... ] >Anyway, *why* are people doing this "hidden event loop" thing over >and over again...? I've implemented several simple GUI toolkits for >various environments, and I haven't really seen a case where chosing >between that model and an "open" read_event() + process_event() style >interface is critical to the implementation. It's basically just a >matter of wrapping some parts of the loop up as API calls, and then >moving the loop into the application. I have yet to see a platform >where it's not possible to use either approach.
i think there are a couple of reasons. an event loop featuring only one source is trivial to write. it gets more difficult when it involves more than one, then more difficult still if the event sources are of different "types", and even more difficult if you want to code it in a fairly platform independent way. toolkit writers these days are aiming at Linux/Windows/Solaris/MacOS compatibility, and this frequently means starting with code in a general portability library. for GTK+, this means glib, which encapsulates event loop control in a completely platform independent way. of course, it isn't used by Qt or FLTK, so you can't use it with either of them. if they don't do this (and note: glib 2.0 has split the event loop into several smaller pieces to make it theoretically easier to integrate it with other approaches the same problem), then they push the task of platform independence on the developer, and they also force the developer to handle different event source types. keep in mind that under windows you can sleep on a semaphore (something sorely missing under POSIX). what would be nicer is a toolkit that knows about various portability library event loops, and offers functions to provide access to the relevant data in formats that can be used to hook the toolkit into those libraries' event loops. for example, a toolkit would provide access to its connection to the X server as a g_io_channel for glib, and in some other form for, say, Qt. AFAIK, this hasn't happened yet. if it did, then you could use GTK+ directly "inside" the Qt (non-GUI) event loop handler, or FLTK "inside" an application using glib (with or without GTK+). and pigs might fly .... :( --p
