Shell and components dependencies definition
Ivan Čukić
ivan.cukic at kde.org
Wed Jun 12 10:59:28 UTC 2013
Hi all,
I've been investigating a few approaches regarding the way we could define the
rules for when a component should be loaded (for example: virtual keyboard <-
no real keyboard, desktop shell <- mouse and keyboard and a nice screen,
netbook shell <- m&k and a small screen etc.*)
At first, I intended to present them all here, but most of them were either
underpowered or required too much work without any benefits to the one I'll
present.
The input/output device detection (and potentially other stuff) will be in a
separate, for now private library called solidx** (as discussed earlier) that
will be made properly qml-accessible.
The loading for the specific components will then be able to be based on the
ConditionalLoader. This will lead to a nice and lightweight implementation.
This will work for the normal rules (such as virtual keyboard one mentioned
earlier) but it will not be sufficient for shell choice because shells have an
additional requirement - there needs to be exactly one loaded***
It can be overcome by having a priority between shells. For example, if the
environment says that both desktop and netbook are suitable, the priority
would be given to the desktop. This will introduce a bit more complex decision
maker than the ConditionalLoader can provide, but is necessary.
If we want this to be generic enough, it could produce an evil brother of
ConditionalLoader that would have 'willing' (as opposed to 'when' :) ) and
'type' properties and 'when' would be privately set to willing &&
shouldLoad(this, willing, type).
I'll stop my ramblings, any thoughts?
Cheerio,
Ivan
* just examples, not necessarily the rules we'll use
** should be merged into solid at some point
*** per screen
--
So much complexity in software comes from trying to make
one thing do two things.
-- Ryan Singer
More information about the Plasma-devel
mailing list