From Grub to Shutdown project update

Mon Jul 25 10:33:02 UTC 2016

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 menu has to be minimalistic in format. The criticism towards the
> old grub menu was that the blue color was too sharp and sudden. It also
> caused issues with the "dark square" that turn up after grub menu and the
> issues with the sudden sharp break between the blue grub menu and scrolling
> text when Plymouth doesn't work (due to proprietary drivers).
> 
> In this redesign we have essentially taken the earlier proposed grub menu
> design but changed the background to black and having the highlight be the
> object in bold and white (#ffffff) instead of the standard, normal font
> weight and light grey (#eff0f1)
> 
> [future ideas is to add small icons for each part of the grub menu, debian
> given a monochrome debian logo, arch an arch logo etc]
> 
> 
> PLYMOUTH
> https://share.kde.org/index.php/s/FRWAcvz7sqZ6Mth
> 
> Like the grub theme the redesign is aimed towards minimizing bright colours.
> So the redesign is a black background. That means that we will go with
> simplistic styles and elegance more than anything in the design language.
> In this case clean light grey (#eff0f1) monochrome icons and a clear text
> also light grey is chosen with good spacing between the two.
> 
> Details Pending: a simple animation for the monochrome icons, with a
> placeholder "Plasma Icon" used as standard and made first. For this to
> happen the new Plasma icon must be chosen.
> 
> 
> SDDM
> https://share.kde.org/index.php/s/PqngLBLynkq7JWG
> Thumbnail Animation Mockup:
> https://share.kde.org/index.php/s/rQV5lS68blpAo1I
> 
> This is the tricky one, and the one that needs the most attention from all
> involved due to its complexity not just in design but in production.
> The main rule here has to be the smallest amount of design complexity at
> first and this has to be the focus. A minimum of animations are used at
> this first version and instead focusing on on proper placement on elements
> to convey the same information. This will give the whole SDDM a rather
> snappy and strict sensation as when selecting another user from the list
> this will automatically and without animation swap placement.
> Aside from that the design is almost identical from those already shown, but
> with some tweaks in regards to things like keyboard layouts.
> 
> The biggest shift is a gradient shift from "black" to SDDM. Essentially its
> a black overlay which goes from fully opaque to fully transparent when SDDM
> loads as a way to move from Plymouth, and the often occuring "second of
> sudden darkness", to SDDM and its blue stock wallpaper.
> 
> [future idea: here there will be animations changes and added effects which
> will make the snappy effects of the barebones model more smooth with said
> animations]
> 
> Details Pending: stock avatars will be finished as soon as possible based on
> photos mostly as that is way easier and the avatars was considered "creepy"
> we should have a well rounded amount of avatars.
> 
> Critical Notes #1: If the animation, the move from black to SDDM theme, is
> impossible to do quickly or if it stutters this part has to be rethought
> from scratch.
> Critical Notes #2: SDDM themes and wallpaper changes, as the standard blue
> will annoy some users the switch to a preferred lockscreen wallpaper have to
> work. If not we need to know.
> 
> (Same as below, in Ksplash)
> If a nice shift between desktop, where SDDM fades (see Ksplash below too)
> isn't possible, then we propose a temporary solution where SDDM fades
> quickly to black and have just a fade from black effect again in Ksplash
> (or handled entirely by Kwin as Ksplash seems not as relevant on many
> systems and just percieved as a delay). It really does depend on the
> technical feasiblity and the work it would require.
> 
> 
> 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.
> 
> [future ideas: this animation, the slowness of the fade of the SDDM
> interface, the avatars fade may be tweaked slightly in the future, a shift
> in how the other avatars disappear as well with some movement planned as
> can be seen in earlier mockups. The reason for this not being present now
> is that its very tricky to get 1-to-1 exactness with animations and the
> more details the less exactness]
> 
> 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".
> 
> (same as above, in SDDM)
> If a nice shift between desktop, where SDDM fades (see Ksplash below too)
> isn't possible, then we propose a temporary solution where SDDM fades
> quickly to black and have just a fade from black effect again in Ksplash
> (or handled entirely by Kwin as Ksplash seems not as relevant on many
> systems and just percieved as a delay). It really does depend on the
> technical feasiblity and the work it would require.
> 
> 
> 
> 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.
> 
> 
> SESSION SWITCHER
> v1 (if wallpaper can be transparent overlay)
> https://share.kde.org/index.php/ s/8oDkgG8Fg4JBobU
> v2 (if not) https://share.kde.org/index.php/s/a55FSa7JyGxc885
> 
> The session switcher is as far as we can tell a rather strangely set up
> thing, where all choices lead you directly to a lock screen to that active
> session, as such the only options it display are active sessions and the
> ability to start a new session, first leading to lockscreen for the
> sessions and the last leading to SDDM. Like Lockscreen it is either a
> temporary, direct snap to lockscreen/session switcher, or it has a smooth
> fade-to-black and a swift fade-FROM-black to session switch.
> 
> The main difference between Session Switcher and Lock Screen is that instead
> of having it cover the entire screen it is a black cover set at 70%
> opacity, meaning you can see the entire desktop below. This since the
> Session Switcher is not a security feature or privacy feature, it doesn't
> require the system to hide anything from the user.
> 
> Critical: according to Dev feedback the background on Session Switcher will
> use the lockscreen by default - so it will then use the opaque wallpaper set
> by Lockscreen.
> 
> 
> 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
> (#ffffff) and the not selected options are at 60% opacity and light grey
> (#eff0f1)
> 
> 
> Entire catalogue of design is here:
> https://share.kde.org/index.php/s/w1fWOb1QDbo98yZ
> 
> It will also be put up on Phabricator
> 
> 
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel