Plasma Meeting Thursday, 31-10-2013
Present: d_ed, mck182_, terietor, sebas, bshash, notmart, aseigo, teo, agateau, erin, ivan, unormal, bcooksley, vhanda, afiestas Agenda: * enumerating the functional blocks in Plasma Workspaces at a coarse level (e.g. “power management”, “desktop shell”, “window manager”..) matching up with maintainers * summary of functional and design goals from last Tokamak * rough outline of time based goals (technical preview, etc) * tabling a project management framework that ties the above three things together * possibilities for Tokamak.next() Introduction (aseigo) My hope is that after this meeting we will have the start to some more concrete project management for the Plasma2 effort. Talking with sebas on monday, we noted that the effort has turned a very important corner: we're no longer just porting libraries to a shaky Frameworks 5 foundation. Now a lot of the emphasis has turned to porting things in kde-workspace and restoring functionality to key components which is awesome; you all deserve a huge "you rock" for getting things to this point. :) What lies ahead, however, requires more than a TODO list that people pick away at; well, at least it does if we want to end up with something that is consistent and wonderful as a finished product. In the last ~18 months people like afiestas have talked more and more about wanting the various components to work well together and for there to be a higher level of "seamlessness", and i think that's a very useful goal. to get there we need to be organized and collaborative given some of the recent work done, such as mck182_'s good efforts to get splash screen stuff back to good, it's apparent at least to me that we aren't doing a great job of that. :) The Functional Blocks Of Plasma Workspaces Plumbing / underlying infrastructure * appmenu * kactivitymanager * kcheckpass * kcminit * kded * kglobalacceld 'Reference Lists' section. * knotify4 * ktimezoned * ktouchpadenabler * kuiserver * kwalletd * kwrited * metadata * online accounts * shell switching control * statusnotifierwatcher Session management * fast user switch * ksmserver * ksplash * lock screen * login / display manager * log out UI * startkde Hardware experience * bluetooth * disk management: automount and freespacenotifier * input devices (e.g. keyboard layouts) * kscreen * libsolid * network manager * powermanagement * soliduiserver Desktop UI * activity manager * add ons / application delivery * desktop containments * firstrun experience (set up accounts, choose shell style ..? oem like) * kdesu * khelpcenter * kinfocenter * klipper * knetattach * krunner * ksysguard and process list * libtaskmanager * notifications and status notifiers * panels * screen savers * share*like*connect * styles (oxygen, air for widgets and qml) * system settings * unified plasma shell * wallpapers * widget explorer * window manager (kwin) Summary from Tokamak 6 (at least the relevant bits) Notes: http://community.kde.org/Plasma/Tokamak6 Look 'n Feel system Info: http://community.kde.org/Plasma/lookAndFeelPackage 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. Desktop UX Elegance and Consistency 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) EPIC GOALS: * Look 'n Feel system * Desktop UX Elegance and Consistency * Improve the session management process 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: 1) the porting story -> what needs to be done to make it awesome on Qt5/FW5 2) 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 Next Tokamak * Preliminary plan: January, in Barcelona (before 15th) * sebas to start planning, email to list next week Finis. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel