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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel