From Grub to Shutdown project update

[Harald Sitter]

On Mon, Aug 1, 2016 at 8:35 AM, Martin Graesslin <mgraesslin at kde.org> wrote:
> On Monday, July 25, 2016 12:24:56 PM CEST Jens Reuterberg wrote:
>> KSPLASH
>> Ksplash is removed in favour for two clear effects, one is the "fade to
>> desktop" already present in Kwin, the other is an effect where SDDM fades in
>> a very specific way. (the SDDM interface fades leaving only the chosen
>> logged in users avatar fading slightly slower (can be seen in the thumbnail
>> gif named "SDDMfade")
>> Essentially SDDM fades, and then directly as part of it visually, a fade to
>> desktop.
>
> Removing KSplash directly breaks the login effect (I assume that's what is
> meant with "fade to desktop"). It gets activated by the ksplash window closing
> and then fades out the ksplash window.
>
> I don't see how this can be done in a Wayland world. (Neither do I see how
> this can be done in a X11 world). To explain: When switching from SDDM to
> KWin/Wayland, KWin takes over the display, SDDM is no longer able to render to
> it.

Deceit and trickery! ;)

I think the important bit is that visually it needs to look like SDDM
is doing the lifting, whether or not it actually does is
inconsequential to the visual result.

3 ways this can be done:

1) Fading to black: SDDM fades to black before starting the session.
The first thing the session does is paint black, launches something
that sits on top of everything else (a ksplash, if you will ;)), this
something continues to be black until it fades to desktop. This
obviously doesn't work on HDD so let's ignore this option because it
is stupid.

The other 2 options imply an interaction between the DM and something
in the session.

2) Now you see me... now you don't: The last thing SDDM does is take a
"screenshot" of itself. It puts that into some file with a very unique
and predictable path. A something in the session (again, a ksplash, if
you will) picks up the file and draws it on screen and then does some
animation (which will natrually be limited). Obvious concern here is
that this won't be able to properly reflect resolution switches since
all that can be done in the session is image manipulation at this
point. On the plus side it should be fairly cheap to implement and
might be a good first step.

3) Meta-meta-meta-programming: Our SDDM theme is QML, KSplash is QML.
Before session start the theme either serializes its dataset into some
file with a predictable path, a something in the session now loads the
dataset AND SDDM's actual QML files and entirely replicates the state
the UI was in on the SDDM. A variation of this, which might well be
harder to do, is fully fixing up the QML files. Namely the theme
itself dumps its own QML but instead of Label { text: variable } it
uses it's state i.e. Label { text: "Kitten" }. By rendering the theme
QML in the session we can accurately handle whatever happens during
session startup, it is for all intents and purposes like a shared code
base for SDMD and KSplash at that point. Whether or not this actually
has use over option 2 I can't say, it certainly sounds cooler in my
mind ;)

Seeing as I know nothing about wayland I am not sure if this can be
done better there.

(Also random note: SDDM's UI is run as an own process 'sddm-greeter',
I suppose one could actually have that "jump" outputs? I.e. one minute
it's on sddm's X, the next it is on the session X)

HS