Brief: * A C++ library for working with GTK+, with several unusual twists. Why, Tim, why? * I like the idea of creating UIs in XML, but I wanted a cleaner XML format than Glade. * I wanted a better way to connect events to C++ code. * I wanted a way to eliminate the 95% of UI coding that's repetitive and simple, without making it difficult to handle the other 5% with native GTK+. What SDPGTK isn't: * An applications framework. It doesn't provide model-view-controller classes, document classes, etc. It doesn't play games with the event loop. It has no problem integrating with "regular" GTK+ code. * Clever C++. The widget classes wrap their respective GTK+ counterparts. That's it. There's no attempt here to try and weld C++ concepts like virtual overrides, etc. on top of GTK+, or to provide a framework for creating new types of widgets. What SDPGTK is: * A very different way of looking at a UI. The focus is on creating a "container" (sdpGtkObjectContainer) full of widgets, and then forgetting about the structure. If you need to refer to a widget, you can do so by name, regardless of its position in the actual GTK+ hierarchy. * A way to keep your code small! You get all the benefits of Glade, without the ugly static callback functions. You'll never have to worry about the prototype of a callback function again, since events are handled with human-readable names. * Easy to integrate with existing code. SDPGTK classes can be used in regular gtk_XXXXX functions, and SDPGTK classes can be "attached" to existing GTK+ widgets at will. * Very clean, human-friendly XML. Each XML element represents a GTK+ widget, or an event. This makes the layout of a UI hierarchy *much* easier to follow. What's unusual: * The lifetime of GTK+ widgets isn't bound to the lifetime of the SDPGTK class instance. Dismayed? You'd be surprised at how well this works. The heart of an SDPGTK UI is an instance of sdpGtkObjectContainer, which loads the UI from XML, and manages its lifetime. You can still create widgets from scratch, if you'd like, but you'd be missing most of the benefits of SDPGTK. * No signal callbacks at all (unless you want them). In your XML document, you assign names to events. You then derive from sdpGtkObjectContainer, override OnEvent(), and handle events by name. * You can nest sdpGtkObjectContainers. There's no requirement that a container=top-level window (although this is usually pretty natural). I've used sdpGtkObjectContainer to encapsulate "custom controls" that are composites of other GTK+ widgets, and can then be inserted into other containers. Status: * SDPGTK has been around for about a year now. I've hesitated to announce it on the list until I was supporting a majority of the GTK+ widgets, which is now the case - I believe I have 7 more to go. * The code is quite stable, with no known bugs. * Current version: 0.1.7.0 Intrigued? * http://www.k-3d.com/libraries/gtkml/documentation.html and http://www.k-3d.com/libraries/sdpgtk/samples.html are highly recommended reading. Where to get it: * http://www.k-3d.com Questions/comments/flames: * [EMAIL PROTECTED] -- To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
