On 2008-04-23 09:32 +0300, Tuomo Valkonen wrote:
> 3. I will provide a list of some suggestions I have for Ion3plus,
> some of which might get into Ion4, in another post.
Here are some. There may be others that I can't recall right now.
* Statusd improvements: should use a proper protocol, and support
multiple independent daemons; perhaps one for each monitor,
written in the author's language of choice. It really sucks
that every clone-statusbar author duplicates the work that
goes into writing and maintaining those monitoring
scripts/plugins. (That's typical FOSS: lots of redundant work,
although it's supposed to foster cooperation. But nobody ever
bothers to write properly reusable code -- across languages --
which I'm trying to encourage here.)
DBus is in principle the right protocol for this, although I
really don't like the UTF-8 monoculturism [1] inherit in DBus and
all the commercial-quality crap that this powerful FDO clique of
paid developers spews out. One could also use mod_ionflux [2]
as a base, improving the protol slightly to be similar to the
present statusd protocol, and to support arbitrary commands.
[1]: http://iki.fi/tuomov/b/archives/2006/08/26/T20_16_06/
[2]: http://iki.fi/tuomov/ion/misc.html
* Statusbar improvements: multi-line support, perhaps pointer
action support for fields, etc. (If one wants
support for the over-complex FDO systray protocol, it has to
be a separate module. Complete support is very difficult,
because it depends on the brain-damage known as XEmbed:
essentially that means writing a new non-ICCCM window
manager with lots of ugly NIH hacks that work around using
proper existing solutions like XGrabKey.)
* FDO startup notification spec [3] support could be nice.
If more applications supported it, it should allow for proper
placement of windows in their startup frames. As usual, the protocol
is quite complex to implement support for, and should be a separate
module (plus maybe new extra hooks, although I think I
specifically added some already).
[3]:
http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
* Much of libmainloop could be replaced by libevent [4],
improving code reuse and taking away maintenance burden.
[4]: http://monkey.org/~provos/libevent/
* Further drawing engine interface abstraction (I have some more
detailed ideas, if there's real interest).
* Additional drawing engines, with better configurability than
the simple default one.
* An ELisp-style binding command system might be nice, complete with
queries for parameters if not given, although it's extra work to
maintain compared to the mere Lua programming interface [5].
But then again, menus already do contain the same definitions,
so one could just extend the menu definitions, and use menu names
as the commands (with translation support!), a bit like Opera has
clear-text command names.
[5]: http://iki.fi/tuomov/b/archives/2007/02/02/T18_49_51/
* Maybe, especially in conjunction of the previous feature, the
config could be more tree-form, storable in arbitrary structural
files (incl. a single Lua table).
* There are tonnes of minor glitches and incompleteness in Ion3.
--
Tuomo
