I’ve been working for several months in the development of the Modest email client. It was a very interesting work, using gtk deeply trying to improve some internal features of the Gtk UI Manager system.

Modest has lots of strict rules about dimming toolbar icons, menu options, action widgets, …. Most applications don’t have a well designed system to manage this kind of events and that behaviour is shared between several files and classes; sometimes these dimming rules are implemented several times, which causes many runtime errors as well as some problems to extend classes and use cases logic.

During my work in Modest I designed a system to manage dimming logic in Gtk applications. This design is based on GtkUIManager system and tries to solve the same problem: centralize and simplify UI events on a GtkWindow. The following UML diagram shows an example of this system:

Implementation details

The next step should be adding this logic to the Gtk core in order to be part of the GtkUIManager system. It will not be very hard to add this behaviour to that class, because UIDimmingManager pattern has the same structure than the Gtk UIManager.

The classes involved in this design and responsibilities are described as follow:

• UIDimmingManager
• This class stores and handles UI Dimming Rules Groups . Each rules group has a string name, which will be used inside the manager to execute a specific group. This rules group is stored internally in a hash map; however, a different data structure could be used for that purpose.
• The API of this class exports two different methods to execute rules:
• ui_dimming_manager_process_dimming_rules: execute all rules groups.
• ui_dimming_manager_process_dimming_rules_group: execute a specific rules group.
• DimmingRulesGroup
• Stores and handles a dimming rules group.
• It could also manage two different types of dimming rules:
• Common dimming rules: This kind of rules are defined for GtkUIManager items, so they have to be defined previously inside the UIManager structure.
• Widget dimming rules: These rules can be applied to any widget.
• Each dimming rule could have a notification dialog in order to inform the user why some item is dimmed. This notification system is enabled or disabled for all rules defined in a single group.
• DimingRule
• This class actually implements dimming rules behaviour.
• It should receive three parameters at creation time:
• Window: a GtkWindow or CustomWindow instance to apply dimming rule.
• Callback: callback function for checking dimming behaviour.
• Action path: the path to locate UIAction element, registered in UIManager.
• This parameter is optional, because for widget dimming rules is not required.
• UIDimmingRules
• This element was defined as a plain file, with a list of operations to be used as dimming rules callback.
• Its similar to the common file used in UIManager stock items implementation for defining actions for each item.

Once you have defined your UIManager structure, with your xml file for defining stock items and UI actions, you only have to define your dimming data structure, very similar to UIManager
structure:

/* Menu Dimming rules entries */
static const DimmingEntry menu_dimming_entries [] = {

/* Email Menu */
{ "/MenuBar/Menu1/Menu1Submenu1/Menu1Submenu1Item1", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu1/Menu1Submenu1/Menu1Submenu1Item2", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu1/Menu1Item3", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu1/Menu1Item4", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu1/Menu1Item5", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu1/Menu1Item6", G_CALLBACK(ui_dimming_rules_on_rule1) },

{ "/MenuBar/Menu2/Menu2Submenu1/Menu2Submenu1Item1", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu2/Menu2Submenu1/Menu2Submenu1Item2", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu2/Menu2Item3", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu2/Menu2Item4", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu2/Menu2Item5", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu2/Menu2Item6", G_CALLBACK(ui_dimming_rules_on_rule1) },

{ "/MenuBar/Menu3/Menu3Submenu1/Menu3Submenu1Item1", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu3/Menu3Submenu1/Menu3Submenu1Item2", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu3/Menu3Item3", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu3/Menu3Item4", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu3/Menu3Item5", G_CALLBACK(ui_dimming_rules_on_rule1) },
{ "/MenuBar/Menu3/Menu3Item6", G_CALLBACK(ui_dimming_rules_on_rule1) }
};

To test graphical applications on Scratchbox you have several X server to export display (VNC, Xephyr, …) However, i conclude Xephyr is the best option because its very light and fast. I know the most of developers use testing or experimental version of Debian; however, sometimes is not possible to update your machine due several reasons: important legacy services which require Sarge, too much stress to lose time on it :), too much busy system administrator, …

In case you want to develop using Scratchbox and Debian Sarge, you should know there is no available version of Xephyr (a very common problem). However, software developers community is great and they always think in all these things to make our life easier. I found a precompiled version of Xephyr, with required static libraries to run it independently of installed Sarge libraries:

http://www.c3sl.ufpr.br/multiterminal/howtos/howto-xephyr-en.htm

The steps to install and run Xephyr on Sarge are very simple:

1. Download the Xephyr binary here
2. Extract it into your work directory (pwd).
3. Export LD_LIBRARY_PATH environment variable to add Xephyr library path:
• export LD_LIBRARY_PATH=pwd/Xephyr/lib/
4. Execute Xephyr with the following options:
• ./bin/Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac

Obviously, you could add pwd/bin to your PATH environment variable.

This year i have been working quite a lot on Maemo platform to develop some GNOME applications into a cross-compile architecture. It’s being a very interesting experience, especially be part of GMAE and Maemo developer community and try to provide my experience in some projects.

This kind of development its oriented to mobile devices, which requires a different kind of applications and development strategy. As most of you know, mobile devices frequently needs some kind of external device to store data, cause internal memory is very expensive and therefore limited.

Scratchbox (www.scratchbox.org) its a cross-compiling environment to develop applications oriented to mobile devices. However, its very difficult int this environment to develop functionalities which requires access to this kind of external memory devices.

I found a simple way to emulate external memory devices using, for instance, a common usb key, to catch gnome-vfs events and handle them as it were emitted from an external memory card. From GNomeVFS point of view, these devices are managed in a similar way, so you cant test your uses cases in your PC.

• Install mount in sbox.

apt-get install mount

• Edit /etc/fstab file on sbox

  none      /proc         proc   defaults       0 0
  /dev/sdb  /media/memory   vfat   user,noauto    0 0

• From host, set ownerships and permissions to sbox mount and umount commands

chown root:root /scratchbox/users/jfernandez/targets/i386-2007-07-26/bin/mount
chmod 4755 /scratchbox/users/jfernandez/targets/i386-2007-07-26/bin/mount
chown root:root /scratchbox/users/jfernandez/targets/i386-2007-07-26/bin/umount
chmod 4755 /scratchbox/users/jfernandez/targets/i386-2007-07-26/bin/umount

• Insert your USB key

• Mount your virtual file system

mount /media/memory

Now, gnome-vfs monitor could detect mount and umount events of your USB, emulating insertion of an external memory device.