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