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.
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
