Many things are managed by different processes, or even completely different projects (like login manager). But the user doesn't care about that, so the idea is to give it a grand unified look, even if they keep being different things internally. So, the potential places identified, in order of startup are:
* Login screen
* Splash
* Some Kwin effect, such as Alt+Tab
* Lock screen
* Fast user switching
* Logout screen
==== Goal ====
These are all just defaults. We will need a user tweakage UI for Look 'n Feel component settings and such things.
We discussed ways to bring some visual and behavior consistency to these different things, e.g. all modal parts really ought to look and work exactly the same way so they feel continuous. So some things in the workspace ui are a modal, interrupting thing like the login screen, the splash, the lockscreen, the user switching the logout dialog. Other things are non-modal like activity switching; some are semi-modal like Alt+Tab (semi-modal -> strictly speaking they are modal, but they are features to aid the user through transitions and so it doesn't actually block workflow). This part of plasma2 is our opportunity to rethink how some of the core UX components are presented. We will consolidate different pieces of the user experience into [[Plasma/lookAndFeelPackage|Look & Feel Packages]] in order to share visual concepts.
==== Related Epics ====
Improved the session management process
* Look and Feel Package: ...
* Desktop elegance: ...
* Session management rocess: ...
==== Integration Story ====
During [[Plasma/Tokamak6|Tokamak6]] in March, we put the options for the startup procedure on the table, and realized that we have 4 unsatisfying solutions: startkde, startactive, systemk, and systemd scripts.
Goals for the Startup:
* fast startup (as few processes as possible, minimal set of actions, highest performance options)
* respect dependencies between components (component B requires A, so start component A before B)
* seamless (no resolution changes visible, no shifting wallpapers)
* declarative (easy to extend/improve, not tied to a single system)
==== Porting status ====
= Time Based Goals =
This part of our planning has been detailed in the [http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule release schedule].
==== Roadmap ====
= Project Management Framework =
==== Maintainer ====
* We identify the main component domains for plasma 2 (e.g. "hardware experience") and ensure there is at least one coordinator for each (e.g. afiestas for "hardware experience")
* We've actually already identified the main components when we did that big listing. the lists are the sub-components, the headings are the main components
* That coordinator (or 2) ensures that all of the sub-components in the domain they coordinate has an acknowledge maintainer for the plasma2 development effort
* If there is a maintainer missing, we need to mark that down as well
* For each domain component (e.g. "screen savers" in "desktop UI"), the maintainer needs to develop two stories:
** the porting story -> what needs to be done to make it awesome on Qt5/FW5
** the goals story -> how does work that is being done (or needs to be done) meet each of the 3 epic goals we have
This will let us all know where we are individually heading and provide input without having to have giant meetings like this one constantly
* The coordinator for each domain will work with the people working on that code to develop and document a time based plan that matches the milestone goals
This will let us know when we should be able to expect things, identify when things need more people working on them (because they aren't meeting their goals)
* Some time goals won't be known right away, and that's ok; those components can be marked with "time unknown" or "defered, waiting on <whatever is blocking>"
* 2 people will co-maintain a project management position that oversees the entire documentation process, prodding people where necessary, working with coordinators to complete their areas, and then making sure that there is a global consistency to the planning
* sebas and aseigo take on overall coordination
* research into tools to replace wiki-based lists
** PW2Todo becomes the todo list that feeds from the PM we document together
== kactivitymanager ==
=Splash Screen (Example) =
The following is an example element description for one of the functional elements.
==== Goal ====
== Goal ==
The splash should hide visual noise during loading of the workspace from the user and shorten the experienced time until the desktop is up. This process should be visually seamless without jumping background images, smoothly blending from the login manager disappearing until the workspace is loaded and usable.
== Epics ==
* Look and Feel Package: QML bits are shared here
* Desktop elegance: Splash is an important part of first impression
* Session management process: splash as part of the login process
=== Related Epics ===
== Integration Story ==
* Look and Feel Package: ...
The splash screen is brought up by the login manager. It loads QML files from the Look and Feel package to provide visual coherence. Once the desktop is loaded, the splashscreen disappears.
* Desktop elegance: ...
* Session management rocess: ...
==== Integration Story ====
== Porting status ==
A basic port to QML is on reviewboard, it needs to be integrated with the login manager, and its QML bits need moving into the L&F package.
== Roadmap ==
* Merge patch (ongoing right now)
* until 15 November:
** move QML bits into L&F package
** investigate and draft plan with SDDM developers
Many things are managed by different processes, or even completely different projects (like login manager). But the user doesn't care about that, so the idea is to give it a grand unified look, even if they keep being different things internally. So, the potential places identified, in order of startup are:
Login screen
Splash
Some Kwin effect, such as Alt+Tab
Lock screen
Fast user switching
Logout screen
These are all just defaults. We will need a user tweakage UI for Look 'n Feel component settings and such things.
We discussed ways to bring some visual and behavior consistency to these different things, e.g. all modal parts really ought to look and work exactly the same way so they feel continuous. So some things in the workspace ui are a modal, interrupting thing like the login screen, the splash, the lockscreen, the user switching the logout dialog. Other things are non-modal like activity switching; some are semi-modal like Alt+Tab (semi-modal -> strictly speaking they are modal, but they are features to aid the user through transitions and so it doesn't actually block workflow). This part of plasma2 is our opportunity to rethink how some of the core UX components are presented. We will consolidate different pieces of the user experience into Look & Feel Packages in order to share visual concepts.
Improved the session management process
During Tokamak6 in March, we put the options for the startup procedure on the table, and realized that we have 4 unsatisfying solutions: startkde, startactive, systemk, and systemd scripts.
Goals for the Startup:
fast startup (as few processes as possible, minimal set of actions, highest performance options)
respect dependencies between components (component B requires A, so start component A before B)
seamless (no resolution changes visible, no shifting wallpapers)
declarative (easy to extend/improve, not tied to a single system)
Time Based Goals
This part of our planning has been detailed in the release schedule.
Project Management Framework
We identify the main component domains for plasma 2 (e.g. "hardware experience") and ensure there is at least one coordinator for each (e.g. afiestas for "hardware experience")
We've actually already identified the main components when we did that big listing. the lists are the sub-components, the headings are the main components
That coordinator (or 2) ensures that all of the sub-components in the domain they coordinate has an acknowledge maintainer for the plasma2 development effort
If there is a maintainer missing, we need to mark that down as well
For each domain component (e.g. "screen savers" in "desktop UI"), the maintainer needs to develop two stories:
the porting story -> what needs to be done to make it awesome on Qt5/FW5
the goals story -> how does work that is being done (or needs to be done) meet each of the 3 epic goals we have
This will let us all know where we are individually heading and provide input without having to have giant meetings like this one constantly
The coordinator for each domain will work with the people working on that code to develop and document a time based plan that matches the milestone goals
This will let us know when we should be able to expect things, identify when things need more people working on them (because they aren't meeting their goals)
Some time goals won't be known right away, and that's ok; those components can be marked with "time unknown" or "defered, waiting on <whatever is blocking>"
2 people will co-maintain a project management position that oversees the entire documentation process, prodding people where necessary, working with coordinators to complete their areas, and then making sure that there is a global consistency to the planning
sebas and aseigo take on overall coordination
research into tools to replace wiki-based lists
PW2Todo becomes the todo list that feeds from the PM we document together
Splash Screen (Example)
The following is an example element description for one of the functional elements.
Goal
The splash should hide visual noise during loading of the workspace from the user and shorten the experienced time until the desktop is up. This process should be visually seamless without jumping background images, smoothly blending from the login manager disappearing until the workspace is loaded and usable.
Epics
Look and Feel Package: QML bits are shared here
Desktop elegance: Splash is an important part of first impression
Session management process: splash as part of the login process
Integration Story
The splash screen is brought up by the login manager. It loads QML files from the Look and Feel package to provide visual coherence. Once the desktop is loaded, the splashscreen disappears.
Porting status
A basic port to QML is on reviewboard, it needs to be integrated with the login manager, and its QML bits need moving into the L&F package.
