For Plasma 2, we are aiming to have one plasma to rule them all, but not in the way the others are doing it. We still believe that different form factors need different UIs (I refuse to use UX instead of UI, so sue me :) ). We just want the same application to be able to load the fitting interfaces for the desktop, netbook or tablets. And we want it to be able to dynamically switch between those.
The dynamic switching part I’m working on is almost finished. Namely, everything is prepared for the last step - integrating the new system with the current shells.
Each shell needs the following components: * A simple and lightweight loader object * And an actual shell implementation that can be done as a C++ plugin or a pure QML thing to make it easier for the common people to create the custom ones.
How does it work?
Note: To avoid confusion, from now on when I write Plasma, I mean the plasma-shell executable that loads the actual shells.
Plasma first gets all the loaders. Loaders need to have two properties defined:
- ‘willing’ which tells whether it wants to be loaded for the current environment (for example, Plasma Active shell would say ‘yes’ when we have a touch-screen);
- and ‘priority’ which will allow Plasma to choose between multiple willing shells (for example, an alternative desktop shell that the user installed).
None of these are hard-coded, so a loader can change its mind and, for example, the Desktop shell can set its priority to be as high as possible if we have more than one screen while having a lower one compared to the Active otherwise.
When a suitable shell is found, the loader is requested to create it.
When the environment changes, and the ‘willing’-ness of a loader has been changed, Plasma checks whether it should load a new shell or stick to the old one.
Great insight! I 100% agree with the architecture you are implementing now. I can't wait using it :)