on Activities on Plasma2

[Ivan Čukić]

Aaron:
> for instance, if we have a “Presentation Mode” activity template, PowerDevil
> could have settings in the template that are appropriate for presentations
> (turn off screen sleep), kscreen could set up multiple screens in a
> presentation mode (e.g. not clone), and the desktop shell can put some
> relevant applications (e.g. presentation apps) on the panel/desktop.

I have no issues with that part of the story.

So, we need some kind of a new api regarding activity meta-data.

Should we create a uniform api for different types of data or create api for 
each type (currently templates)? (I'm leaning towards the former so that we 
don't end up with dead methods like isEncrypted()).

Currently, kamd supports something I called 'features', generic properties 
handled by the core or the plugins, that can return bools whether something is 
available globaly or per-activity. It can be modified to support QVariant 
values or something. (even if we go for specific/non-generic/fixed api)

It has a simple protocol, but the main drawback is the same one we have for 
plasma's data-engines - missing documentation about features/values a plugin 
provides and the format of the result.

If we go for a non-generic api, all the protocol stuff will be encapsulated in 
the library. Otherwise, it will need to be heavily documented...

Marco:
> i think kamd wouldn't even have to worry if everybody understood that the
> template is changed ?
+1


Cheerio,
Ivan


-- 
Money can't buy happiness, but neither can poverty.
  -- Leo Rosten