Xfce Wiki

Sub domains
 

This is an old revision of the document!


Scope

Every Xfce panel plugin is required to reimplement UI, which makes writing basic plugins more difficult and leads to UI inconsistencies.

There is a need for a generic plugin that provides basic UI (icon, label(s), menu, etc., see below) and allows the plugin writer to implement only data collection logic.

Basic Architecture

The plugin should be partitioned into two components:

  • a library implementing UI consisting of one or more(?) buttons (called monitor-UI),
  • a plugin implementing monitoring logic (called monitor-logic).

The panel should not assume that monitor-logic is implemented as e.g. a library written in C. In the future, this could be used for writing monitor plugins in scripting languages.

Preferably, the library should provide a base class of a monitor-logic object, with some virtual functions populated.

Features

Essential

  • The plugin should be visible in the “Add New Items” panel dialog as a separate item (i.e. not as a monitor-UI plugin that can be later configured to load some module). To populate the list of plugins the plugin should provide (via a .desktop file?):
    • A user readable and translatable name,
    • A user readable and translatable description,
    • An icon (48px?)
  • Monitor-logic should not call any UI operations directly, i.e. it should not have no direct access to XfcePanelPlugin object.
    • Perhaps we should allow creating generic Gtk objects for configuration UI?
  • Monitor-UI should provide following features to the Monitor-logic object:
    • One or more (?) panel buttons logically grouped together and sorted. Each of them displaying at least one of following:
      • An icon.
        • The icon should be provided by Monitor-logic, and Monitor-logic should be able to enable, disable or swap the icon at any time.
        • Should come in multiple sizes and/or .svg format to fit different panel sizes.
          • This means, if possible, Monitor-logic should not use Pixbuf objects as they do not scale well.
        • Monitor-UI should scale the icon in a single panel row size.
        • For UI consistency we should recommend every plugin to have an icon (but probably better not to make it mandatory via API).
      • One or more (?) text labels (not GtkLabel objects, though).
        • The text label should be provided by Monitor-logic.
        • Should be translatable when it makes sense,
        • (should support Pango markup?)
      • If icon and labels are shown, Monitor-UI should arrange them in one of the following layouts:
        • Stacked vertically - icon at the top, labels below. In this case, all objects should be centered.
        • Horizontal grouping - icon on the left, on the right a vertical stack of labels. In this mode, all objects should be aligned left.
        • Perhaps this should be configurable at the panel level, not in each plugin separately.
      • If only labels are shown, they should be stacked vertically and centered.
      • If only icon and is shown, it should be treated as a “small” plugin.
    • For each button, Monitor-UI should provide a default action, configured by Monitor-logic, that, when the button is clicked, does one of following:
      • Calls a specified callback in Monitor-logic.
      • Opens a menu specified (but not created) by Monitor-logic. (How to specify the menu? Glade?)
      • Displays a popup with a range widget (e.g. for setting audio volume)
      • Displays a popup with a text entry field.
  • Provide a standard XfcePanelPlugin context menu shown when right mouse button is clicked.
  • If “About” is clicked, Monitor-UI should display a dialog box with following information:
    • “About” should only be visible if requested by Monitor-logic.
    • Icon, name and description displayed in the “Add New Items” dialog box.
    • Copyright, as provided by the Monitor-logic.
    • A detail description, as provided by Monitor-logic.
    • A list of authors to populate “Credits”, as provided by Monitor-logic.
    • A text of the license to populate “License”, as provided by Monitor-logic.
  • If “Properties” is clicked, Monitor-UI should call a specified callback in Monitor-logic.
    • “Properties” should only be visible if requested by Monitor-logic.
    • Note: this assumes that Monitor-logic would then display a config dialog, which would require it to perform some UI operations. (any better solution?)

Optional

  • For each button, Monitor-UI should provide a secondary action.
    • Same features as for primary action.
  • For each button, Monitor-UI should provide mouse scroll actions.
    • When mouse wheel is turned, a specified callback in Monitor-logic should be called along with the direction of scrolling.
  • For each button (only if Icon is shown?) Monitor-UI should provide a “progress-bar” widget.
    • Monitor-logic should be able to specify whether to enable/disable it and what value to display (in % or so)
    • (Monitor-UI should draw the “progress-bar” on top of the icon, so that it is visible even if only icon is shown).
  • Monitor-UI or panel should generate periodic (configurable?) events for polling external events that are then propagated to Monito-logic objects. Doing this centrally in one place, reduces the number of CPU wake-ups.
  • A recommendation: we should avoid “setters”, “updaters” etc. in Monitor-logic API in favor of “getters” and signals - this makes both sides of the API deal with only its own tasks.

UI mockups

Horizontal panel

Deskbar mode

Vertical panel