Xfce Wiki

Sub domains
 

This is an old revision of the document!


Human Interface Guidelines for Panel Plugins

Find below the HIGs for the panel plugins. Keep in mind that those are here for reference and most probably for new plugins. There is a secondary page with proposed HIGs where you are free to add any HIGs you find useful to be noted.

For information about strings style please refer to this page.

About

Rationale

UI consistency is an important aspect of a mature desktop like Xfce. On the other hand, there are tons of panel plugins out there, developed by many different people. A written set of UI guidelines will help those developers ensure their plugins maintain some basic level of consistency.

Process

We're trying to do this in a wiki fashion, so everyone is welcome to improve this. When you add something new, put “[draft]” before it. This way, plugin developers know to keep an eye on it, and people can provide their comments. If you aren't sure how something should be handled but think it should be discussed, put “[rfc]” (request for comments) before it.

Plugin Classes

Most guidelines apply differently based on the plugin class. (“Class” here means bin or category - it is not used in the GObject sense). The document is split into sections for each of these classes. The guidelines that apply generally are listed in the “General” section.

General

Context Menu

The right click context menu provides items with default actions like “Move”, “Delete”, and “Configure the panel”. It is possible to add predefined items like “About” and “Properties”.

The About item is seldomly used, which makes it recommended to not include it at all. But that option is left open to the plugin writer. In any case use

gtk_show_about_dialog()

Some plugins add a custom Help item inside this menu, but it is more common to put a Help button inside the properties dialog. Usually the user will want to open the properties dialog to have a better idea of the plugin. If you don't provide a properties dialog, you can have a reason to add a custom item.

Properties Dialog

In all Xfce applications it is common to apply the settings as they are changed in the dialog. Unless you are making more complex changes, avoid removing the sensitivity or to set the properties dialog modal.

If you are using a RC file to store the settings, you will need to save the settings when the dialog closes. This makes sure the user gets his settings back at any time when he has to restart the panel.

With Xfce 4.6+ you can use Xfconf, in which case the settings are saved as soon as they change. The Xfce 4.8+ Panel provides the macro xfce_panel_plugin_xfconf_channel_new() to acquire the Xfconf channel.

On a completely different note, when the properties dialog is open, the context menu must be blocked with xfce_panel_plugin_block_menu(). When the properties dialog is closed, it can then be unblock again with xfce_panel_plugin_unblock_menu().

The properties dialog should be created using xfce_titled_dialog_new_with_buttons() A subtitle can be set using xfce_titled_dialog_set_subtitle(), and a window icon reflecting the plugin should be set using gtk_window_set_icon_name().

Main UIs

The main UIs that are often reused between the plugins are described as close as possible below. So far there are 3 main UIs for a plugin: the button, the input and the monitor. Currently each plugin is written with custom Gtk+ widgets, and to make this more common it will be good to write GObjects at least for a common button and monitor.

Button

Example of plugins using a button as their main UI: menu, places, notes, launcher, window list, mount, …

The main purpose of the button is to open an external window or to display a menu. In the case of a menu, it must be a toggle button and keep the state pressed as long as the menu is displayed.

Usually an image is put inside the button but it can have a label put besides it. The label has to be short to conserve space and it must be properly capitalized (e.g. “My Button”).

The button has to display the image at the left or at the top given the panel's orientation.

Input

There are not many plugins using an input field for their main UI (for example verve and the dictionary).

The main UI is composed of an optional button (refer to the button class above) with only an image, and an input field (usually a GtkEntry widget).

Monitor

Many plugins display a monitor and give the user the option of showing a label with a value reading, or both. The more “complete” plugin displaying as a monitor is the FS Guard plugin, it can display up to an image, a label with a value and a meter.

Plugin examples: system load monitor, battery monitor, sensors plugin, …

The different elements are contained inside a box, the border width of the box is 0, and the spacing between the children is 2 pixels. For the comments about the labels refer to the button class.

Panel properties

mode

The panel (starting with 4.10) has 3 modes : horizontal, vertical and deskbar. A plugin should layout its widgets following those rules :

  • use a vertical XfceHVBox if the panel is in vertical or deskbar mode, horizontal otherwise.
  • labels should be oriented vertically (using gtk_label_set_angle()) in vertical mode.
  • progressbars should be oriented vertically in horizontal mode, horizontally otherwise.

size

plugins should be tested to still render fine in all panel sizes, starting from 16px to 40px at least.

number of rows

plugins should set the small property (using xfce_panel_plugin_set_small()) only if they are intended to render on a single row, and not in deskbar mode. size-changed callback should take care of setting the widgets size taking into account the amount of rows. A common construct is to use

size /= xfce_panel_plugin_get_nrows (plugin)

before setting size on the various widgets.

Action widget

The right-click menu should be accessible through all (if possible) widgets of the plugin. Generally you only need to use xfce_panel_plugin_add_action_widget() on the containing XfceHVBox to achieve that.