This file is meant to contain a little documentation about the GdlDock and related widgets. It's incomplete and probably a bit out of date. And it probably belongs to a doc/ subdirectory. Please send comments to the devtools list (gnome-devtools@gnome.org) and report bugs to bugzilla (bugzilla.gnome.org). Also check the todo list at the end of this document. Have fun, Gustavo Overview -------- The GdlDock is a hierarchical based docking widget. It is composed of widgets derived from the abstract class GdlDockObject which defines the basic interface for docking widgets on top of others. The toplevel entries for docks are GdlDock widgets, which in turn hold a tree of GdlDockItem widgets. For the toplevel docks to be able to interact with each other (when the user drags items from one place to another) they're all kept in a user-invisible and automatic object called the master. To participate in docking operations every GdlDockObject must have the same master (the binding to the master is done automatically). The master also keeps track of the manual items (mostly those created with gdl_dock_*_new functions) which are in the dock. Layout loading/saving service is provided by a separate object called GdlDockLayout. Currently it stores information in XML format, but another backend could be easily written. To keep the external XML file in sync with the dock, monitor the "dirty" property of the layout object and call gdl_dock_layout_save_to_file when this changes to TRUE. No other action is required (the layout_changed is monitored by the layout object for you now). GdlDockObject ============= A DockObject has: - a master, which manages all the objects in a dock ring ("master" property, construct only). - a name. If the object is manual the name can be used to recall the object from any other object in the ring ("name" property). - a long, descriptive name ("long-name" property). A DockObject can be: - automatic or manual. If it's automatic it means the lifecycle of the object is entirely managed by the dock master. If it's manual in general means the user specified such object, and so it's not to be destroyed automatically at any time. - frozen. In this case any call to reduce on the object has no immediate effect. When the object is later thawn, any pending reduce calls are made (maybe leading to the destruction of the object). - attached or detached. In general for dock items, being attached will mean the item has its widget->parent set. For docks it will mean they belong to some dock master's ring. In general, automatic objects which are detached will be destroyed (unless frozen). - bound to a master or free. In order to participate in dock operations, each dock object must be bound to a dock master (which is a separate, non-gui object). In general, bindings are treated automatically by the object, and this is entirely true for automatic objects. For manual objects, the master holds an additional reference and has structures to store and recall them by nick names. Normally, a manual object will only be destroyed when it's unbound from the master. - simple or compound. This actually depends on the subclass of the dock object. The difference is made so we can put restrictions in how the objects are docked on top of another (e.g. you can't dock a compound object inside a notebook). If you look at the whole docking layout as a tree, simple objects are the leaves, while all the interior nodes are compound. - reduced. This is only meaningful for compound objects. If the number of contained items has decreased to one the compound type object is no longer necessary to hold the child. In this case the child is reattached to the object's parent. If the number of contained items has reached zero, the object is detached and reduce is called on its parent. For toplevel docks, the object is only detached if it's automatic. In any case, the future of the object itself depends on whether it's automatic or manual. - requested to possibly dock another object. Depending on the type's behavior, the object can accept or reject this request. If it accepts it, it should fill in some additional information regarding how it will host the peer object. - asked to dock another object. Depending on the object's internal structure and behavior two options can be taken: to dock the object directly (e.g. a notebook docking another object); or to create an automatic compound object which will be attached in place of the actual object, and will host both the original object and the requestor (e.g. a simple item docking another simple item, which should create a paned/notebook). The type of the new object will be decided by the original objet based on the docking position. DETACHING: the action by which an object is unparented. The object is then ready to be docked in some other place. Newly created objects are always detached, except for toplevels (which are created attached by default). An automatic object which is detached gets destroyed afterwards, since its ref count drops to zero. Floating automatic toplevels never reach a zero ref count when detached, since the GtkWindow always keeps a reference to it (and the GtkWindow has a user reference). That's why floating automatic toplevels are destroyed when reduced. REDUCING: for compound objects, when the number of contained children drops to one or zero, the container is no longer necessary. In this case, the object is detached, and any remaining child is reattached to the object's former parent. The limit for toplevels is one for automatic objects and zero for manual (i.e. they can even be empty). For simple (not compound) objects reducing doesn't make sense. UNBINDING: to participate in a dock ring, every object must be bound to a master. The master connects to dock item signals and keeps a list of bound toplevels. Additionally, a reference is kept for manual objects (this is so the user doesn't need to keep track of them, but can perform operations like hiding and such). GdlDock ======= - Properties: "floating" (gboolean, construct-only): whether the dock is floating in its own window or not. "default-title" (gchar, read-write): title for new floating docks. This property is proxied to the master, which truly holds it. The title for the floating docks is: the user supplied title (GdlDockObject's long_name property) if it's set, the default title (from the master) or an automatically generated title. - Signals: "layout-changed": emitted when the user changed the layout of the dock somehow. TODO LIST ========= - Functionality for the item grip: provide a11y - Implement notebook tab reordering - Implement dock bands for toolbars and menus. - A dock-related thing is to build resizable toolbars (something like the ones Windows have, where the buttons are reflowed according to the space available). - Redesign paneds so they can hold more than two items and resize all of them at once by using the handle (see if gimpdock does that). - Find a way to allow the merging of menu items to the item's popup menu. Also, there should be a way for the master to insert some menu items. - Bonobo UI synchronizer. - Item behavoirs: implement the ones missing and maybe think more of them (e.g. positions where it's possible to dock the item, etc.) - Make a nicer dragbar for the items, with buttons for undocking, closing, hidding, etc. (See sodipodi, kdevelop)