Looking around and thinking ahead

[Sebastian Kügler]

Hi all,

I thought I'd share a braindump with you how I can imagine the coming year in 
Plasma. I'll outline the current state "a bit more detailed", and will offer 
ideas how we're scheduling the coming months up to a stable, brand-spanking 
new Plasma, as well as outlining work we have ahead of us.

Today, I'm running Plasma 2 almost exclusively on my laptop. The most 
important features are there, and it's definitely dogfoodable for me without 
huge impact on my productivity, and it's getting noticeably better by the day. 
That's quite a milestone, and I'd like to thank everybody for getting it this 
far. With Qt arriving at a stable 5.2, and us having ironed out quite some 
stability problems in the past weeks (hello switching QML engine and scene 
graph renderer in QtQuick/QtQml!), it now runs stable, I haven't seen a 
crasher during normal usage in a few days (but I know how to trigger one :P). 

Most of the infrastructure has been ported and made to work, but we're not 
quite there, yet. The move to sddm hasn't materialized yet (upstream presence 
has been a bit spotty, so we might need to take a more active role in making 
this happen). Other options are also still on the table, so this needs nailing 
down a strategy. The display manger topic bleeds into the startup procedure, 
and especially the splash handling, and of course the Wayland topic. 

The above is one example of architectural things we need to sort out. We have 
others, such as the startup (startkde) where we have a working port now, but I 
think we can do much better there. Options on the table are using systemd for 
it, start-active which could be up to the task, or possibly a hybrid solution. 
Also, can we make login really fast? :D

We have some fallout in systemsettings, especially the Locale module needs 
more porting (porting away from KDE4Support & KLocale, using the new Qt APIs 
we've merged), and making all those little setting buttons everywhere work 
correctly.

In plasma-shell, we have some construction sites as well. Kickoff still feels 
quite unfinished (some would say broken ;)), configuration of Plasmoids isn't 
complete in many cases, and it's not yet visually pleasant. There's good 
progress there, and I think Plasma 2 can look visually more stunning than 
Plasma 1 (I'm especially excited about Marco's translucency/contrast 
improvements, and the stronger accentuation of typography and cleaner and 
better aligned default look we're moving towards, getting styling of QtQuick 
Controls fully fixed will contribute to this as well). 

We're also missing a few things, such as KRunner, which isn't finished yet, 
and along with it a slew of runners (which should be relatively easy to port 
in the end, and we do pretty well in parallelized, small tasks, so that I 
guess won't be too much of a headache).

plasma-framework needs some work on APIs, too. With large version number 
change, we can reduce the delta between libplasma and our declarative imports. 
There are some candidates which currently use quite some glue code for our 
declarative bindings. Can cook this down and maybe move some implementations 
into libplasma, or adding necessary Q_PROPERTYs to our API? The scriptengine 
has quite a large bunch of code as well. Does it make sense to move the 
plasmoid. object (offered to our Plasma/Applets) into libplasma, it's pretty 
much core of our current API, but otoh is currently fixed to QML.

Wayland. Martin has focused on the Qt5 and XCB port, which is also preparatory 
for running kwin on Wayland. This is likely the major part of the graphics 
stack we need to care about, but there is a number of X11 calls in our further 
basic workspace stack that we need to sort out in order to provide a full-
fledged user experience in a post-X11 scenario. There's a slew of IPC things 
that might need API work on both sides, especially between plasma-shell and 
kwin. There's some serious work ahead, but I think the base is really good. 
I'm running kwin\5 extensively, and it works and performs well.

We have a large amount of regressions, still. This can be larger things, like 
the above, but also all kinds of smaller regressions, which often stem from 
API changes in our scriptengine, that we need to catch and fix.

In that regard, we've started shifting bugs into bugzilla, so we don't lose 
track of the whole slew of issues we see. In many cases, it's easy fixes, but 
probably about a thousand of them, so this needs tools and workflows. Is 
bugzilla good enough for us, do we want to invest time, switching costs and 
possible disappointment with other tools? How agile do we want to be? How 
formal should our processes be?

Then, apart from the technical bits, there is the user point of view, which 
should become our guiding light. We've concentrated a lot on the technical 
bits, but haven't looked further into our vision towards the user, workflows 
we want to make as smooth as possible, UI concepts, integration of new things 
like KPeople, KDE Connect, and so on. That's quite natural, as revamping our 
architecture to work on top of the new, fully accelerated graphics stack was 
the base work we had to lay. The UI side is where we can really make a 
difference, we've built quite an awesome base, but we need to turn this into 
real, added value for our users.

We're not very well equipped in the artwork department. Perhaps we can try to 
find artists more actively. I think we have some very exciting work to be 
done, with a large audience. There *must* be good designers around who want to 
help us making Plasma beautiful.

So, our coming milestone is to prepare a tech preview for our users. This 
could be in the form of a set of tarballs. We also have the Neon5 image, which 
should be in pretty good shape. I'm personally also cool with not rolling 
tarballs, but offering git tags. Our packager audience, to my knowledge is 
quite fine with using git as source, and it should be cryptographically sound 
to offer them a git tag to pull from. (Packagers: please correct me if I'm 
wrong.) Bottom line: there's a mild amount of release management to do. Also 
some PR work is needed, a video, screenshots, a text explaining the status, 
direction, progress and plans. Something exciting for our users while they 
chew on the proven and stable long term maintenance release. :)

Part of this communication is that we should settle the name question. We had 
a good discussion about that some time ago, but it died out before reaching a 
conclusion. Let's put the options back on the table, and come to a decision 
there. (Relevant thread is "naming the next major release" on 19th August on 
plasma-devel.)

Following that, I think the following roadmap makes sense. (This is rough, and 
up for discussion, but I think a solid base to know what's coming.)

Next week: tech preview of our current state, ready to try

Early January: Tokamak 7, focusing on high-level view and how to realize that

Q1/2013 Focus on Wayland, completing the workspace infrastructure, completing 
API reviews and changes, and looking into kdelibs improvements we want to get 
in before KF 5.0. (Hello, KNotifications, KService, etc.!)

End of Q1: Solid beta, again something that shows visible progress and promise

Q2: Polish, take a step back and fix bugs, make it work as smooth as possible, 
extra-mile and papercuts work, but still concentrate on the desktop basics and 
especially avoid regressions in primary workflow and functionality. This leads 
to a stable release of at least the desktop shell towards the end of Q2.

Q3 and 4, I imagine, could shift the focus from the bare basics to a more 
complete product. Multi-device usecases realized by different shells, meaning 
porting and integrating the Plasma Active UI, Plasma Mediacenter, and making 
the whole device morphing scenario useful. Integration of PIM data via 
kpeople, telepathy, inter-device communication (KDE connect could play a major 
role here). There has been some very exciting stuff in the making, which is 
coming to fruition and ready to shine.

Many of us will meet in January for Tokamak, that's a wonderful opportunity to 
nail down many of the higher and lower level issues. And Tokamaks are fun.

To conclude this epic email, and perhaps provide a bit of balance: I am 
utterly impressed of where we stand right now. Just a few weeks ago, a 
smoothly running desktop seemed far, far away. Today, I'm running Plasma 2 on 
my laptop comfortably, with smoothly wobbling windows, but without being too 
afraid to lose this long email thanks to some major nasty crash. 
Chapeau to everyone who has contributed to us getting there! Let's turn this 
base into the most awesome workspace we can imagine!

So, there's my braindump, thanks for bearing with me so far. What are your 
ideas? :)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9