-
Notifications
You must be signed in to change notification settings - Fork 22
Wishlist
This is the wishlist for Multiload-ng.
Everything listed here is not into Multiload-ng because I didn't have necessary time and/or knowledge. These things will certainly be implemented sooner or later, either by me or by a keen contributor.
You are free to submit the code for these features, or suggest another one.
Aim to support as many desktop environments (and their panels) as possible.
GTK2-based panels are the easiest to port. This is because plugin itself is coded against GTK2.
lxpanel, mate-panel and xfce4-panel are all GTK2-based.
Starting from v1.1.0, plugin fully supports GTK3. This allow to port to GTK3-based panels too.
Gnome Shell and Cinnamon: Their applet architecture require them to be written in JavaScript. This makes almost impossible to port Multiload-ng to these panels, at least in its current state. I'm leaving those two in Wishlist because in the future someone will be able to write a wrapper or something similar. There is an indicator applet for both panels, so one can use libappindicator-based plugin when it will be ready.
Budgie Desktop panel is GTK3-based. It's applets are written in C. This port seems to be feasible.
Ideally should be possible minimize the amount of toolkit-dependent (read: GTK+) code, down to the bare minimum of:
- a single container widget
- drawing routines
This would open up a whole world of possibilities. Multiload-ng could then be ported to:
- KDE4 (Plasma 4)
- KDE Frameworks 5 (Plasma 5)
- LxQt
- ...
Support to external docks would be nice too. I think that some of these doesn't use a widget toolkit, but rather primitive drawing routines; so implementation method could be different. Some external docks are:
- Cairo-Dock
- DockbarX
- Docky
- ...
Translation in other languages would be great. Translators are welcome!
Note: there are original multiload plugins (for MATE, Unity, etc) that are very well localized, some strings (about 30% I think) are identical so they could be taken from there.
Enhancements on the usability side.
Some panels could allow some behaviors while other panels not. A place should exist (like an extra tab in Preferences dialog) where these additional settings could be placed in a clean manner.
These extra preferences should be coded in a new file in panel-specific directory. This file will be parsed at build time to create extra Preferences tab. This way the main code remains clean.
I'll explain this looking at standalone window specific settings:
- show/hide window borders
- move window by dragging graph (useful if window borders are hidden)
- starting position/size
- resizable/fixed size
- transparency
- always on top
These just make no sense for other panels.
In GTK2 and GTK3, GtkTooltip can:
- contain plain text (this is the approach used in 'simple' tooltips)
- contain Pango-markup formatted text (this is the approach used in 'detailed' tooltips)
- embed any GtkWidget
Instead of just showing formatted text, Detailed tooltips could graphically represent information in a simpler, more visually appealing way.
Informations will pack within a smaller area, in a less confusing way (incorporating e.g. pie charts, tables, icons/images...)
There could be some text placed next to every graph, or over them. This text should be optional for every graph, and could show short information about every graph (e.g. total CPU usage percent, or used RAM percent). Position, color, background and other parameters should be customizable (and part of color scheme too).
- Ability to set plugin margins separately (top, bottom, left, right) instead of all at once
Enhancements on the functionality side
Implement other graphs. Some suggestions are:
- Storage (free space, used space)
- Bluetooth traffic
- Audio output?
Instead of have one graph per type, there could be the ability to have more than one graph per type.
This switch to a object-oriented-like approach would require massive rewriting of core logic. Probably it will never be done (if ain't broke, don't fix it), but who knows.