Hello, You're right to some degree that lipstick does have too many responsibilities at present, and that some splitting would be a good idea.
<jolla hat on> We have not been working on any of this at the present time as we are focusing on stabilization and performance in order to launch our first device (and initial software) this year. <jolla hat off> After some thought and talking to some of the other guys on our side (Vesa Halttunen, Mikko Harju) I think your proposal for splitting is a little too vigorous, as speaking from experience, splitting the compositor and the home screen interaction leads to some very difficult design issues, even to the point of making some things impossible. If you were familiar with the N9 architecture (mcompositor, meegotouch-home, and meegotouch-systemui), it had splitting done similarly to how you describe (compositor separate from home screen, dialogs/lockscreen/etc split away from those in systemui) and we wasted considerable development effort for minimal gain to satisfy what were some quite tame design requirements. That having been said: it is our opinion that lipstick as-is does too much. My personal proposal would be to introduce a new component with similar design to lipstick, let's call it mascara. This would be responsible for parts of the system UI that do not comprise of anything directly home related, like most dialogs (SIM pin code entry, bluetooth pairing, mobile data connection, etc, etc, etc). The architecture there would be fairly simple: it would offer up a library consisting of a dbus service with the capability to invoke all these different dialogs and functionality, an implementation would then take this library, write a simple C++ application surrounding it, and insert QML to offer up all the necessary functionality. Quite like the existing lipstick design. This then results in significantly less baggage being put into one basket, and should at least be a good initial step towards your desired result of stability, while retaining the ease of customisation/prototyping that we're very happy about with the current approach. BR, Robin (on behalf of the Jolla home screen/compositor guys) On 24. okt. 2013, at 14:07, Mikko Hurskainen <[email protected]> wrote: Dear all, > > We have been thinking to split up the lipstick based home screen into > separate processes. Currently a crash in one of the components will bring the > whole stack down. Also currently QPA Wayland plugin does not seem to be able > to reconnect to compositor after a crash and thus applications and home > application need to be restarted. > > The components would be: > - Compositor process: Wayland compositor tasks and interacting with other > system components > - Home process: Desktop and the applications menu > - Task switcher: separate application that can switch between tasks > - Lock screen: handles the lock screen > > The home process, task switcher and lock screen are handled as special > applications by the compositor. The special applications have a different > rules what comes to window ordering etc compared to normal applications. > > The lipstick library would be also be splitted into two parts. One that > handles the home screen related functionality and one that handles compositor > related functionality. The base lipstick would look same as it did before > wayland transition. It can be then used to implement home screen related > functionality in any application in the system. > > We are currently evaluating this and hoping to get comments on design. It > would be interesting to know whether this kind of design would be beneficial > also for someone else and whether there are some cases it would fit or not > fit. > > With Best Regards, > -- Mikko Hurskainen > > >
