Plasma/Next

Epics with all the Details

• Plasma/Next/Plumbing Plumbing and Underlying Infrastructure
• Plasma/Next/SessionManagement
• Plasma/Next/HardwareExperience
• Plasma/Next/DesktopUI

Desktop UX Elegance and Consistency

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

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

~Quarterly milestone releases with public communication (blogs and announcements) and tarballs

• Mid-December 2013
  • "Proof of Life" technology demonstration release
  • Dogfoodable
  • Basic functionality in place, then we can tackle UI and new concepts from there
  • Hardware experience

• EOM March 2014
  • Technology demonstration release 2
  • Wayland session
  • Look 'n Feel package support implemented in all affected components
  • Session management and startup++, kded4 / ksmserver / etc

• EOM June 2014:
  • The UX as we imagine it (yes, vague, we have a lot of definitional work to do there)

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