Re: From Grub to Shutdown project update
same as before logo+text. colors are less advised since we now use a generic black for practical reasons On Thu, Aug 4, 2016 at 1:34 PM, Jonathan Riddell wrote: > > Any branding that shippers like KDE neon should customise? > > Jonathan > > > On Thu, Aug 04, 2016 at 01:30:44PM +0200, Harald Sitter wrote: >> grub and plymouth now in master > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
Any branding that shippers like KDE neon should customise? Jonathan On Thu, Aug 04, 2016 at 01:30:44PM +0200, Harald Sitter wrote: > grub and plymouth now in master ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
grub and plymouth now in master On Tue, Jul 26, 2016 at 11:58 AM, Harald Sitter wrote: > On Mon, Jul 25, 2016 at 12:24 PM, Jens Reuterberg > wrote: >> GRUB MENU > > done in 'redesign' branch on git. > - spacing needs recalculating as the theme now won't fit on < 700px height > - also switched from noto to unifont as discussed previously as the > lack of AA is making most fonts look incredibly bad > - we haven't managed to figure out how to do translations for this yet :/ > >> PLYMOUTH > > done in 'redesign' branch on git. > - do we animate anything on shutdown? > - busy indication is probably needed for long boots. for now, I > removed the spinner we had previously > - text theme still needs updating, but that's only default colors > since we haven't done any theming there anyway > > video that doesn't reflect the changes very well. it looks incredibly > gorgeous on highres, try it! > https://share.kde.org/index.php/s/4YVmkd9iRfnVWK2 > > HS ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
On 25.07.2016 12:59, Marco Martin wrote: now, one thing i would like to happen is people taking up a piece of it, of the thing they are more versed into (being sddm, the lockscreen, whatever) signal here they are going to work on it, and have the pieces of the puzzle then merged in master asap so they can run some months on devel machines to be ironed out before release. As requested, I have now created one sub-task per theme for the task https://phabricator.kde.org/T2062, they're waiting to be grabbed :) For questions as long as Jens is on vacation, please contact Andreas Kainz (CC'ed). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
On Monday, August 1, 2016 10:49:16 AM CEST Harald Sitter wrote:
> On Mon, Aug 1, 2016 at 8:35 AM, Martin Graesslin 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 ;)
On X11 the option 2 could be simplified: sddm renders it's last screenshot into
the root window, when ksplash starts it grabs the content from the root window
and uses that as the background. But the same problem as you already wrote:
it's problematic with multi-screen and resolution changes. Also this approach
only works if there is no compositor running (which is true at the early
startup phase).
>
> Seeing as I know nothing about wayland I am not sure if this can be
> done better there.
It's pretty much the same on Wayland. The startup in KWin is to render a black
screen to perform the initial mode setting. That could also be a different
image.
From that time on the compositor is running which always renders a black
background and the windows on top of it.
>
> (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)
That can only work if it's still the same X. If a new X is started for the
user session it won't work, neither for switching to Wayland.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
On Mon, Aug 1, 2016 at 8:35 AM, Martin Graesslin 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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
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. May suggestion thus is to keep KSplash and just change the design. > Critical Notes #1: if this handoff between SDDM and Ksplash is impossible > for technical reason or will stutter another plan must be drawn up. The > goal here is speed - if speed can be improved by having the animation > SOLELY in SDDM and ignoring Ksplash then that is better. > For this reason we need technical input and help testing. > Critical Notes #2: The SDDM theme can switch wallpaper, the wallpaper being > the LAST thing seen in combination with the logged in users avatar - its > relevant that the this work if the user switch wallpaper so that the > wallpaper is the last seen instead of "stock blue". See above: I don't think it's technically possible. Starting KSplash does not create a delay, it's a fast application. > LOCK SCREEN > https://share.kde.org/index.php/s/0WRG8Us8qElwgDP > Thumbnail Animation: https://share.kde.org/index.php/s/DR1HV3d9HRHRigJ > > The locks screen has to share the basic concept of the SDDM screen as it is > in practice, from the users perspective, almost the same thing. > Thats why it inherits the stock-blue background (editable from the > lockscreen settings). > When the lockscreen is actvated it displays a swift fade-to-black from > desktop and an even quicker fade-FROM-black to lockscreen. The goal is to > make a swift switch and make it feel more like a secure door slamming than > a slow fade. If that feels too complex this late in the release cycle a > temporary solution is just a direct switch, ignoring all animations. I can take care of adjusting the default background to the blue. Note that for technical reasons it might cause a black frame to be rendered first. > SHUTDOWN/LOCK/ETC > https://share.kde.org/index.php/s/YojnHEhf6qUmHLu > > When a user press shutdown, lock and logout the desktop fades, darkens, and > an overlay black at 70% opacity pops up the logout options are displayed > with the one the user selected preselected and in the center, from there > the user can use mouse or arrows to move to another option, like go from > the shutdown to reboot. The selected option is fully opaque and white > (#ff) and the not selected options are at 60% opacity and light grey > (#eff0f1) Do I understand correctly that you do no longer want the fade to the center? And that you don't want to blur the background at all? I think that needs real-world testing before removing the blur. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
On Mon, Jul 25, 2016 at 12:24 PM, Jens Reuterberg wrote: > GRUB MENU done in 'redesign' branch on git. - spacing needs recalculating as the theme now won't fit on < 700px height - also switched from noto to unifont as discussed previously as the lack of AA is making most fonts look incredibly bad - we haven't managed to figure out how to do translations for this yet :/ > PLYMOUTH done in 'redesign' branch on git. - do we animate anything on shutdown? - busy indication is probably needed for long boots. for now, I removed the spinner we had previously - text theme still needs updating, but that's only default colors since we haven't done any theming there anyway video that doesn't reflect the changes very well. it looks incredibly gorgeous on highres, try it! https://share.kde.org/index.php/s/4YVmkd9iRfnVWK2 HS ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
> As you walked me trough the design a bit before, I think the design is quite > reasonable and feasible (i have doubts only on the semitransparent session > switcher, it may have to be baked in the lockscreen for now instead, but > those are just small details right now) > Yes added an alternative version of a session switcher using the lockscreen wallpaper (in the mockup "stock blue") - as that is not in anyway a show stopper and any thing that can help this get sorted by 5.8 is good. The main thing is that you guys can expect us in the VDG to be VERY VERY flexible with reworking mockups if that is needed for something to get it to work. > now, one thing i would like to happen is people taking up a piece of it, of > the thing they are more versed into (being sddm, the lockscreen, whatever) > signal here they are going to work on it, and have the pieces of the puzzle > then merged in master asap so they can run some months on devel machines to > be ironed out before release. That would be awesome. My goal is to have this implemented for 5.8 come what may and will be happy to focus hard on whatever is needed for the design personally ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
On Monday 25 July 2016, Jens Reuterberg wrote: > > Entire catalogue of design is here: > https://share.kde.org/index.php/s/w1fWOb1QDbo98yZ > > It will also be put up on Phabricator As you walked me trough the design a bit before, I think the design is quite reasonable and feasible (i have doubts only on the semitransparent session switcher, it may have to be baked in the lockscreen for now instead, but those are just small details right now) now, one thing i would like to happen is people taking up a piece of it, of the thing they are more versed into (being sddm, the lockscreen, whatever) signal here they are going to work on it, and have the pieces of the puzzle then merged in master asap so they can run some months on devel machines to be ironed out before release. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: From Grub to Shutdown project update
Please note that the green buttons in SDDM and Lockscreen will change to proper Plasma buttons instead of wide green ones. Here is the Pholio page which might be valuable to keep an eye on https://phabricator.kde.org/M58 On Monday, 25 July 2016 12:24:56 CEST Jens Reuterberg wrote: > From Grub-to-shutdown, a unified experience > > GOAL OF PROJECT: > To create one sensation from grub to shutdown, where the user whenever she > is outside of the desktop environment and interacting with the parts needed > to make the desktop environment make sense feel like she is part of one > unified whole instead of several small bits and pieces all working on their > own. > > PROJECT HISTORY AND ISSUES: > All you all probably recall the initial release of it was met with very > negative opinions, mostly based on details (like the grub menu being bright > blue) and that parts where implemented but not the whole making if feel less > as a whole than some new details. Now these criticisms will come again > during this release but it will at least be the criticism towards something > new, than something that simply does not work to accomplish the intended > effect. > > Due to the projects size it has put a massive strain on the way we, > developers and designers work. As the design in itself is in practice > several small parts all being redesined individually it seems fairly > straight forward, but without them all based on each other as one > overarching whole, they simply don't make sense. Since it is almost > impossible to test for designers before release and small glitches or > misunderstandings when finally discovered are incredibly huge issues for > the design - it becomes frustrating to designers. Since these fixes comes > in AFTER the work is done and released and what seems as frivolous changes > that are technically huge are pushed hard by designers, its incredibly > frustrating for developers. > > Added to that the several different channels of communications means > individual devs for each individual part talk to individual designers. > Confusion ensues when the way designers and devs work, individual designers > have fun ideas and suggestions that get easily translated into "hmmm the > VDG wants this". Then the VDG as a whole notice parts have been implemented > assuming that "hmmm the devs wants this" and the whole cycle continues. > > PROJECT FIX: > This is a rather new development for us - and it requires some kind of > extraordinary fix. > > We have settled for two: the first is to set the entire project on lockdown. > That means that ALL information not being followed by a "This is the > opinion of the VDG that we want to implement" and combined with mockups or > wikiedits is NOT ment as anything more as discussion topics or looking for > theoretical input from the developers. We will as a group ensure that we > minimize all this as much as possible, be clear with our intentions in > discussions and that we as a group sign off properly on work. > > Second fix is the barebone-design of the project. What this is is that we > create the BARE MINIMUM of what is needed for the design to work. A minimum > of animations, effects etc. The entire design we are sending you now is > what is the minimum for the entire project to make sense. The reason for > that is so that instead of regressions, we have addons. Perhaps a new > animation in the future, perhaps some tweaked placement or color changes at > some point. What will NOT happen is that you (developers) will have people > from us (VDG) turning up a month or two away demanding that everything in a > certain area will be scrapped. > What we need, the VDG, is that when something is not clear, when something > isn't obvious to you in the mockups - no matter how silly it may seem - you > have to ask. And you have to accept that there may not be a direct answer. > The person you ask may not be able to answer and it is up to us in the VDG > to ensure that we all feel capable of saying "I don't know" (which has been > an issue before). Our point is to ensure that the answer you get is > correct. > > __ > > > The Design: > This is a text run through of the proposed design for From Grub to Shutdown. > Future ideas are placed within [brackets] and mean plans for future tweaks, > things that do are not intended for this release or critical for the design > to work as a whole. > > Certain parts will have "Critical Notes" these are notes about technical > things, usually concerning speed or feasibility that needs answering and > testing first before too much work goes in as they otherwise need a > redesign. > > Other parts have details pending. This will be marked clearly in this > document. That means that the needed detail isn't exactly defined yet but > will be done within days and will be communicated as clearly as possible. > > > GRUB MENU > https://share.kde.org/index.php/s/CUJB96B7daE0buh > > The grub m
