unity-dev team mailing list archive

[Neil Jagdish Patel <neil.patel@xxxxxxxxxxxxx>]

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