I mentioned the system tray progress the other day in my blog, but Marco blogged about it extensively today, including a couple of videos and a nice description of why we're doing what we're doing.
This is something long overdue, and I'm very happy to see interest from other projects such as E17 in this as well.
I just wanted to add to Marco's blog entry that we're very open to feedback from potential consumers of the new system, both application developers as well as desktop shell projects.
One fellow left a comment on my blog the other day with some thoughts about how to improve the D-Bus service specification. I looked at the xml, whipped up a small patch (though against the wrong branch *sigh*), and then Marco took it from there and incorporated it into the rest of the codebase.
So check out Marco's blog and if you are someone who works with system tray icons, please give us your feedback.
I'm elated about the whole thing because this is several years in the coming. The first time I shared my concerns about the specification some 4+ years ago, it was met with incredulity and denial. Now we're actually doing something about it, and in a way that can be easily used by anyone who cares to.
I am particularly happy that we haven't had to break backwards compatibility in either direction to make this happen either, making it a perfectly seamless transition for the user who will simply see things get magically better without regressions. As can be seen in Marco's second video, applications using the KDE class dynamically switch between the XEmbed icon or the D-Bus based method as needed (so that KDE apps will continue to run just fine in any environment) and our system tray widget is multi-protocol so supports all possible entry points (meaning apps using the XEmbed approach still work as they always have).
The new possibilities this opens are tremendous though. Marco mentioned multiple views on the same set of icons, but there's also the ability to have completely different kinds of views. The ability to put messaging icons together into a "communications area", to merge application entries with their taskbar representations or to provide more accessible representations such as larger or high contrast icons, text only or even audio system trays ... and with none of the painting and positioning stupidity we've had to deal with over the last year in Plasma.
*slightly giddy*
Oh, and we have an improved device notifier on its way into kdebase soon, too ... :)
Subscribe to:
Post Comments (Atom)
3 comments:
Please get buy-in from Gnome Shell. The new panel and UI have been written mostly by Red Hat beginning in November 2008 so the code base is brand new and they are in the process of refining their support for the XEmbed method. There's lots of interest in radical new ideas and new solutions to old problems so I think they'll be fairly receptive to your proposal.
And there's pretty much complete agreement that this is the future of Gnome. So, get 'em while they're young!
Hopefully we'll all be on the same page on notifications by the time Gran Caneria comes around!
In any event, great work. I love this design.
It would be great to be able to manually group system tray icons as well, kinda like it's possible to do in the taskbar.
Does this also mean we'd be able to create different clients if we want to have a different kind of functionality? It seems like a great idea wwhich could really lead to some unexpected results in the concept of system trays.
@Jason: i'm hoping (and working) for that, yes.
@Javier: "It would be great to be able to manually group system tray icons as well, kinda like it's possible to do in the taskbar."
i think it'll eventually happen, yes :)
"Does this also mean we'd be able to create different clients if we want to have a different kind of functionality?"
absolutely. and you could even run multiple clients simultaneously. no limitations! :)
"It seems like a great idea wwhich could really lead to some unexpected results in the concept of system trays."
that's one of my hopes, yes.
Post a Comment