LXPanel Roadmap

From LXDE.org
Jump to: navigation, search

The panel itself

  • Current multi-panel support is quite dirty and needs some rework

Better infrastructure

  • Implement Panel by subclassing GtkWindow and fully utilize features provided by GObject.
  • Encapsulate some events in a PanelConfig class and expose some notifications with GObject signals, such as:
    • "changed" signal
  • Properties of the panel can be registered as GObject properties, so we can have change notifications provided by GObject system, and all applets can connects to "notify::<property-name>" to get proper notifications. For example some useful properties are:
    • "text-color"
    • "orientation"
    • "position"

Then applets can g_signal_connect(config, "notify::text-color", G_CALLBACK(on_text_color_changed), applet); to change their text color when the user set a new color in panel preferences dialog.

  • Encapsulate useful X11 events in a GObject class: X11Events. This object is a singleton. It provides some notification signals to be connected to:
    • "window-manager-changed"
    • "run-dialog"
    • "show-app-menu"

and some useful properties:

    • "working-area" (so connect to "notify::working-area" can let you know that working area is changed)
    • "cur-desktop"

and also some useful methods: x11_events_get_current_window() x11_events_list_windows() Basically this should work similar to libwnck, but it only implement the most basic things. This should provide enough abstraction and prevent the applets from the need to directly handling X11 calls. Taskbar applet may become much cleaner once this is done.

Better GUI layout management

  • Use new LXButton and LXGrid classes
  • Utilize GtkOrientable interface? (is this needed?)
  • Seperation of GUI and non-GUI parts if possible. So it will be much easier to upgrade to gtk+ 3 or even to change GUI toolkit in the future.

Enable the use of some applet outside lxpanel

Implement a simple container embedded in GtkSocket, and add the lxpanel applets in it. So lxpanel applets in dynamic plugins can become systray applications. The possible way to launch this is like:

lxpanel-applet batt

The program lxpanel-applet create a systray socket, and load the batt plugin. Then, embed the plugin inside systray. The same way can be used to implement gnome-panel appets and hence enable the use of lxpanel applets in gnome-panel, but I don't want to support gnome-panel. :-P

Consider using dbus in optional plugins

  • Implement a new battery plugin with dbus + upower

Audio volume mixer plugin

  • Should calls external tools like volume controller of pulse audio or gnome-volume-control
  • should handle multiple channels cleanly.
  • Let the user set the channel modified by this applet

Integrate date/time applet with existing date/time admin tools

  • Integrate this with time-admin or other possible alternatives if they're available
  • May provide basic facilities to change system time.

Move some plugins like netstat to seperate projects

  • netstat plugin is deprecated and should be removed later unless Fred or someone pick it up again.
  • netstatus plugin need some examinations and fixes.

Application launcher

  • Should allow adding customized applications defined by the users.

Application menu

  • Create a separate plugin specifically for applications menu is much better than mess up with the existing menu plugin. In this way we can add more features to it without the compatibility problems with the original menu plugin originated from fbpanel.