See: http://blogs.testbit.eu/timj/2005/07/31/31072005-rapicorn/ (page moved)
I have been asked some about rapicorn recently, so…
In spring 2005, i started working on a gnome-canvas replacement for beast. A bunch of GUI/toolkit design ideas that accumulated over the last few years have influenced the design of this. For a change, i coded this up in C++ so i am not forced to produce the large amounts of boilerplate code that GObject requires. It is only with C++, where typesafe interface lookups for composite widgets can be implemented. That is, a container holding a child of a specific interface (say a box containing a text entry which implements the Text interface) integrates that interface into its public API via:
Text &text = container.interface<Text>();This can be extended to allow passing in widget ids, for instance to tell apart the buttons of a dialog:
Button &button = file_selector.interface<Button> ("cancel-button");And to access the text of the cancel button:
Label &label = file_selector.interface<Label> ("cancel-button"); The core idea is to build larger widgets out of micro widgets (very simple things like frame, label, table, image, rectangle shader, etc.) by writing concise xml statements. This may look like so:
<button hexpand="1" left-attach="50" bottom-attach="59" > <label _text="Expand Button" /> </button>
This would be a button, packed into a table at 50-51 horizontally and 59-60 vertically. Also, the button is expanded horizontally within the table container and contains a label with translated text. These xml style widget definitions were originally developed for Gtk+ code and can be found as “radgets” in recent beast releases. The notation is powerful and conscise enough that nearly all beast dialogs could be defined in a single xml file.
Another major design aspect is strict seperation of model, view and controller logic, down to such simple things like toggle buttons. Most popular toolkits out there already allow seperation between model and view, but fail short on seperating the controller logic and making it pluggable (customizable). Most often this causes code more complicated than neccessary, where the view and controller logics are closely tied up, and result in hacks or code duplication in third party products to change controller behaviour as desired. Turning controller functionality into its own object instance which may be customized or replaced by the toolkit user, will help to reduce third party hacks and increase structure of the toolkit code.
Last but not least, an often heared request for beast was changing its outlook, so it looks more like “cool” music applications found under windows: (AU), (RE), (CU). This will involve working more with images, font rendering, alpha blending and dithering for standard GUI components than is intended with stock Gtk+, so this kind of featurism is also supposed to end up in rapicorn instead.
That being said, rapicorn hasn’t left initial design phase yet and much of what is there or will be there soon may not survive future releases because we’re still testing out new ideas and concepts. Semi frequent releases however will be made available at the rapicorn ftp directory, mostly in response to someone asking me to put up a new tarball.
