Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
dev:monitor-plugin [2013/03/18 10:01] – [Essential] nick | dev:monitor-plugin [2013/03/19 21:26] – [Optional] hjudt | ||
---|---|---|---|
Line 4: | Line 4: | ||
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. | 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. | ||
+ | |||
+ | Question: should this mechanism allow independent applications communicate with the plugin (e.g. via dbus) and display " | ||
====== Basic Architecture ====== | ====== Basic Architecture ====== | ||
Line 16: | Line 18: | ||
Preferably, the library should provide a base class of a monitor-logic object, with some virtual functions populated. | Preferably, the library should provide a base class of a monitor-logic object, with some virtual functions populated. | ||
+ | Note: I had started some months ago a skeleton of a gobject monitor plugin, intending to merge all monitors inside it, and using libgtop & upower for data collection. See http:// | ||
====== Features ====== | ====== Features ====== | ||
Line 23: | Line 26: | ||
* A user readable and translatable name, | * A user readable and translatable name, | ||
* A user readable and translatable description, | * A user readable and translatable description, | ||
- | * An icon (48px?) | + | |
+ | | ||
* Icon-name. The item dialog show dnd size icons (32px) | * Icon-name. The item dialog show dnd size icons (32px) | ||
* Monitor-logic should not call any UI operations directly, i.e. it should not have no direct access to XfcePanelPlugin object. | * Monitor-logic should not call any UI operations directly, i.e. it should not have no direct access to XfcePanelPlugin object. | ||
Line 39: | Line 43: | ||
* Should be translatable when it makes sense, | * Should be translatable when it makes sense, | ||
* (should support Pango markup?) | * (should support Pango markup?) | ||
+ | * (what about custom widgets like the weather plugin' | ||
* If icon and labels are shown, Monitor-UI should arrange them in one of the following layouts: | * 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. | * 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. | * Horizontal grouping - icon on the left, on the right a vertical stack of labels. In this mode, all objects should be aligned left. | ||
+ | * In this mode, the plugin could default to a " | ||
* Perhaps this should be configurable at the panel level, not in each plugin separately. | * 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 labels are shown, they should be stacked vertically and centered. | ||
Line 48: | Line 54: | ||
* Calls a specified callback in Monitor-logic. | * Calls a specified callback in Monitor-logic. | ||
* Opens a menu specified (but not created) by Monitor-logic. (How to specify the menu? Glade?) | * Opens a menu specified (but not created) by Monitor-logic. (How to specify the menu? Glade?) | ||
+ | * Should this menu be merged with the context-menu of the plugin instead? This is what plugins do at the moment, and frees them to use LMB click for other purposes (indicator plugin makes these menus separate, though). --- // | ||
* Displays a popup with a range widget (e.g. for setting audio volume) | * Displays a popup with a range widget (e.g. for setting audio volume) | ||
* Displays a popup with a text entry field. | * Displays a popup with a text entry field. | ||
+ | * For each button, Monitor-UI should provide a tooltip information, | ||
+ | * An icon, | ||
+ | * A (pango formatted?) label. | ||
* Provide a standard XfcePanelPlugin context menu shown when right mouse button is clicked. | * Provide a standard XfcePanelPlugin context menu shown when right mouse button is clicked. | ||
* If " | * If " | ||
* " | * " | ||
* There can be a set function to enable about (like xfce_panel_plugin_menu_show_about) and a vfunc/ | * There can be a set function to enable about (like xfce_panel_plugin_menu_show_about) and a vfunc/ | ||
+ | * Or we can build in at least a basic " | ||
* Icon, name and description displayed in the "Add New Items" dialog box. | * Icon, name and description displayed in the "Add New Items" dialog box. | ||
* Extracted from the desktop file, no need to set that twice. --- // | * Extracted from the desktop file, no need to set that twice. --- // | ||
+ | * Which object should do the extraction, Monitor-UI or Monitor-logic? | ||
* Copyright, as provided by the Monitor-logic. | * Copyright, as provided by the Monitor-logic. | ||
* A detail description, | * A detail description, | ||
Line 67: | Line 79: | ||
* Note: this assumes that Monitor-logic would then display a config dialog, which would require it to perform some UI operations. (any better solution?) | * Note: this assumes that Monitor-logic would then display a config dialog, which would require it to perform some UI operations. (any better solution?) | ||
* Maybe it should always provide basic appearance settings, so user can configure this (the backend is only responsible for the data, not the display). When building the dialog the plugin can populate its own frame/box for additional settings that are required for the data collection. --- // | * Maybe it should always provide basic appearance settings, so user can configure this (the backend is only responsible for the data, not the display). When building the dialog the plugin can populate its own frame/box for additional settings that are required for the data collection. --- // | ||
+ | * Yes, appearance settings could be handled directly by Monitor-UI, but what about settings related to the actual function of the plugin? (e.g. location in weather plugin) --- // | ||
+ | * This part sounds tricky; Alternatively, | ||
+ | * Basic appearance settings could simply be provided by an entry in the context menu. I'd somehow rather associate this with the panel, or with the genericness of the plugin, e.g. font size, font color. | ||
===== Optional ===== | ===== Optional ===== | ||
Line 78: | Line 92: | ||
* (Monitor-UI should draw the " | * (Monitor-UI should draw the " | ||
* Monitor-UI or panel should generate periodic (configurable? | * Monitor-UI or panel should generate periodic (configurable? | ||
+ | * The idea is nice and I thought about that too some time ago, but then there are plugins that update their widgets quite frequently and more frequently than others, so the questions here are more like: "Is it worth all the engineering? | ||
+ | * Decision needed: Font size and color selectable in the panel or in the plugin? | ||
* A recommendation: | * A recommendation: | ||
+ | * Currently without a use-case, but perhaps it could be useful: Support reacting to external signals, e.g. via D-Bus? | ||
+ | * Not sure this belongs here, but... as an alternative to making a plugin " | ||
====== UI mockups ====== | ====== UI mockups ====== | ||
Line 179: | Line 197: | ||
| | ||
secondary_action_text_entered (text) | secondary_action_text_entered (text) | ||
+ | | ||
+ | | ||
+ | //tooltip --- // Andrzej 2013/03/18 10:58// | ||
+ | | ||
+ | has_tooltip() | ||
+ | | ||
+ | get_tooltip_icon() // | ||
+ | | ||
+ | get_tooltip_label() | ||
+ | | ||
+ | signal tooltip_changed() | ||
| | ||
| |