i'm about to embark on an attempt to implement an API for a GUI "toolkit" called libvstgui, used to implement GUI's for plugins used in Steinberg's Virtual Studio Technology system. a bunch of us on the Linux Audio Development mailing list feel that adopting libvstgui for the Linux audio plugin system known as LADSPA is a highly beneficial move all around. we've spent over a year knocking around proposals to use XML to specify GUI's in a portable fashion, and many other ideas. some of us have given up: there are some really cool plugins that already use libvstgui, and its an excellent design and very cross-platform in its outlook.
the question arises: at what level to implement libvstgui? its a GUI toolkit based on primitives (and not very many of them) that allow the plugin to create a highly customized (frequently "chromed") appearance for its GUI. rather than using any standard widget appearances, plugins using libvstgui generally use bit/pixmaps to control how various control and display elements appear. its also a C++ API. it would be much faster to use an existing high level toolkit and just bolt libvstgui over the top of that. actually, the Canvas comes to mind in a number of ways too. but there is a serious disadvantage in doing that. it means that applications that want to host these plugins but that don't use the chosen toolkit are completely out of luck - they will be running a main event loop that is incompatible with the one expected by the port of libvstgui (and the underlying toolkit). looking at the API (its very well documented; the headers are available and even contain some useful stuff) it appears that it wouldn't be incredibly painful to use Xlib directly. but then again, doing anything directly with Xlib tends to be fairly painful. it would delightful to use GDK, but i have a strong feeling that GDK is thoroughly rooted in the g_main_loop() abstraction, and so is not suitable. doing it in Xlib would allow the library to be used by any application using X, regarding of which toolkit it was based on. if anyone has any thoughts on this, they would be very welcome. --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
