On 27 October 2013 08:10, Mikko Hurskainen <mikko.hurskai...@nomovok.com> wrote: > Hi, > > >> 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> > > > Main reason for these changes is to achieve better stability. I understand > that time is now precious for Jolla and this kind of architectural change is > adding lots of effort, but we try to improve the stability in longer > timespan. Also, making this kind of changes takes always a bit time and I > think it won't be ready before first Jolla device ships. Without knowing > your future plans, I think it could also benefit you later. > > >> 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. > > I am aware of design challenges with N9 architecture, but the split we are > proposing has three main differences compared to that one. > * Status bar (meegotouch-systemui) is not separate process as in N9 so there > is need to do constantly composition from multiple sources > * Wayland architecture as such also promotes independent rendering of > applications. This will remove bunch of problems that were present with the > X architecture > * We are still able to modify both compositor and home screen because the > architecture on both sides is clean and designed for modern devices with > legacy in mind > > I think the split we are proposing is a step back, but it covers the > features that were lacking in X-based architecture. > > This kind of change will limit the general purpose usability of the > architecture, but we are targeting embedded devices. The embedded devices, > as we know them now, are all following this same logic for the split. If we > want to support some totally new approach to UI or prototype things, we can > always take a step back and implement everything in one application. The > lipstick split that we are proposing is usable for both approaches. > > >> 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. > > I think this split would also add value. The compositor / home screen > combination will become more clean and all these important, but small > components would be put into one basket. > >> 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. > > I agree that it would be a good step into same direction.
Thanks to Robin it has now come to its first fruition: https://github.com/nemomobile/mascara Cheers, Simonas > > However, I think both home screen and 'mascara' are components that need to > be customized. Our thinking is that compositor is something that does not > need to be customized for every device, and hence platform should provide > support for separating it and solid baseline version of it. If the > compositor will be customized, then it will be some totally new device class > or new UI concept, that would then need to a new version of compositor for > that device class / UI concept. Also, current architecture would be possible > with this change. > > Regards, > -- Mikko Hurskainen > > > On 24.10.2013 21:37, Robin Burchell wrote: >> >> 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 >> <mikko.hurskai...@nomovok.com> 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 >>> >>> >>> >> >> > > >
