[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]



We are going to start looking at getting the activation framework design
completed. A short recap of the previous discussions on the list:

There were a few wishlist items:

* KDE and GNOME should be able to use it directly or build on top of it
for their activation needs

* We need generic properties and a way to query them (name, description,
icon, ...)

* Handle i18n for things like name and description without degrading

* Take user preference in consideration when sorting a query result

* Need to standardize .desktop format for more than menus if using
desktop files

* Nice if this could be used for other things than just D-BUS services,
in order to decrease duplication

* Implicit activation (optionally activate a service automatically when
messages are sent to it)

Some thoughts and questions that arised:

* Some hesitation about the usefulness of primary/secondary owner

* Only handle activation of D-BUS services or other things like
applications and shared libraries as well?

* Handle activation in a service, in the bus, or client-side in a shared
library? (Remote activation not as transparent with shared lib)

* Use bus for querying everything but only activate D-BUS services in
the bus, and other things separately? (E.g no point in activating shlibs
inside the bus)

* Should use a caching scheme for service/desktop files to overcome
performance issues (lots of files, lots of translated strings)

Our plan is to go through these items, come up with the answers and then
write a design document which should be ready around mid January. It
would be great if any additional comments or ideas are brought up before


Richard Hult                    richard imendio com
Imendio                         http://www.imendio.com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]