← Back to team overview

unity-dev team mailing list archive

Re: RFC: syslets

 

Hey,

On Wed 22 Feb 2012 09:39:21 GMT, Mikkel Kamstrup Erlandsen wrote:
Hi all,

We seem to have a recurring item that we can not cleanly address currently.

Consider these two bugs:
https://bugs.launchpad.net/ayatana-design/+bug/681348
https://bugs.launchpad.net/ayatana-design/+bug/868423

The common theme is that we want some sort of simple app-like-thing that calls into some deeper system hooks.

Sure - this can all be done as full fledged apps with their own .desktop files and packaging an all, having compiz or unity expose public api to do this, but that just seems to me as the wrong solution. Exposing semi-internal stuff as public api, extra packaing snafu etc, or new config options, etc.

I am toying with the idea of having Unities dynamically export a set of "syslets" available on the session bus, and exposed in the apps lens via a special scope or something. This would be a Q feature of course, we'd need s stop gap from P.

Since syslets would be dynamically exported and have some shared DBus activation conventions (perhaps simply GActions and GMenuModel) it would remove packaging overhead and the need to expose internal api or weird config options.

This way different Unities and different setups could expose different syslets, making sure we only show stuff that works.

Another huge benefit is that we can more easily accept "speculative" or experimental features and expose them as syslets.

Thoughts?

I like the general idea. In addition to the scope, we could have another BAMF backend that reads these and exposes them to the Unities, with all their properties, right? Or were you thinking of another way?

--
Neil Jagdish Patel | System Architect
Desktop Experience Team
Canonical
27 Floor, Millbank Tower
London SW1P 4QP
Ubuntu - Linux for Human Beings
www.canonical.com

Follow ups

References