Tag Archives: desktop

Whops I didn’t mean to delete that

This is a little sneak peek of a new feature that will arrive in Plasma 5.2 (OK, to be pedantic since frameworks has a separate schedule, you will be able to get it already next frameworks release a bit before Plasma’s)
Ever ended up deleting a desktop widget, panel widget or even an entire panel just to wish you hadn’t?
One solution may be littering everything with confirmation dialogs, but this quickly becomes annoying, besides the user becoming quickly trained to click “yes” without ever thinking about (I fallen too many times at this kind of dialogs).
So, what can be a better solution? Undo!

When the user deletes something, a notification pops up, notifying that an important thing has been deleted: it offers an action to undo the deletion.
If you click “undo” the widget or panel will instantly come back, if you manually close the notification, it will be irrevocably deleted.

On Plasma5: present and future

This is the second part of my ramblings about the Plasma 5 release, just after it come out.

This is a very important moment, after a massive amount of work.

What are the most important things that can make a free software project successful or not?
To me are principally two: user experience and developer experience.

User experience

The first release of Plasma 5 will start to make use of the work of a newly formed group in the KDE community: the Visual Design Group.
I’m very impressed how they managed to get a firm grip of many issues that are always been a problem in KDE software.
They are not only doing nice pictures, but rather starting to give real guidance to the design direction of the future Plasma and applications by KDE.
On the 5.0 release, the most visible thing will be the Breeze theme, that while still far to the final vision, it starts to show the clean and functional style (funny trivia: I remember discussing on the VDG forum about pure flat design versus using 3D effects for “interactive” controls, to give depth and intuitiveness for interactive areas… months before Material was presented. Those guys are definitely onto something.)

But it of course doesn’t stop to a theme and some icons:
what is more deep and a long term plan is to review the look, refinement and usability of pretty much.. everything.
Good design means also every single application has a clean and functional layout, and its “interaction flow” is logic, intuitive and derived from user needs rather than the technical details of the application.
An example of those things still to come is the new layout of System Settings that will come in little piece by piece, one by one in the future releases (The 5.0 release already has a new categorization, each release will move it a step more towards the final design).

Freedom, in all aspects

A big challenge in the design of Plasma 5 is that while providing a very simple and appealing experience out of the box, our central value is to put our priority in serving the different exigences of different kinds of users, because, as for devices, one size does not fit all.

The Plasma workspace is now even more flexible, on different devices it will sport completely different default user interfaces, because different use cases and different input methods require a different way to interact and a different way to present information (as lately even Microsoft discovered, in the very hard way).

And not only that, on your desktop or laptop, you can “build” a workspace experience as you please, optimized to your preferences.
We will never force you to a panel in a particular side of the screen, or to one task manager mode (taskbar vs dock) or to a particular desktop layout.
We well know that this makes the design process more difficult, but often the “easy” solutions are not necessarily the “correct” ones.
We give you a desktop that can adapt to you, rather than giving you a desktop you have to adapt to.

Developer experience

In later years, with the bigger emphasis on the user experience, the experience for developers started to take the back seat.
But we are a free software project, and its success is measured not only in users, but also in how many people would want to engage in an active way, and how comfortable are developers to work on the projects.
Being built on a foundation as strong as Qt, the software by KDE can also offer amazing tools for developers.
The recently released KDE Frameworks 5 is an important step in this direction: the KDE libraries are not anymore a big monolith but a set of very small, useful and independent libraries.

The base of the Plasma Shell is a framework as well: the Plasma framework, composed principally by two things:

The Plasma library: is the good old libplasma.. but it’s way slimmer and more focused than the KDE4 version: It doesn’t offer graphical widgets anymore, and doesn’t make any assumption on what graphic engine will be used (One could even build a shell completely based upon QWidgets with it, just because :p).
It continue to provide easy access to packages, dataengines, asynchronous services and the save and restore functionalities of the layout, known as the Corona.
The library solves problems that are out of scope for QML: from a surface with interactive graphical elements in it, it brings it to a “full featured desktop shell”.
The second part is instead a set of runtime components, of QML bindings that offer QML access to the Plasma facilities such as dataengines and svg themes and a set of graphical components to use in QML plasmoids and applications, such as buttons and text fields, that are converging, and will converge more and more with the upstream QtControls project.
In future releases there will be a comeback of the kpart to easily include qml-based informational dashboards into applications, and a runtime to launch plasmoids as simple independent mini applications.

Looking at the future

So, what are we planning for the future?

The stable, default core Desktop project will become more and more stable and polished, but the development focus will touch other use cases as well.
The Plasma Active port to Frameworks 5 is ongoing, as well the Plasma Mediacenter port, so the “different shell for different devices” story will be complete.
Of course our focus is not only about KDE on different devices, but also making KDE work tightly integrated with other kind of devices, thanks to projects such as KDE Connect. Interestingly, The Plasma Workspace 4.x series is today the environment with the tighter integration with smartphones (only with the next releases of their operating systems Apple is catching up, with a quite similar feature set).
You can expect this integration work being even more complete in future releases of Plasma 5.

Finally, the artwork presented in 5.0 is only a preview of what is still to come from the Visual Design Group: more icons, more complete widget set, more and more applications will receive a makeover look-wise and most importantly usability-wise.

On Plasma 5

We are very, very near the release of the new Plasma release by KDE (more on the nomenclature later).
This is the first entry of a short series of blogs that take a look about the past and the future of Plasma, what we learned from the 4.x series, what changed, what we can take away and to expect for the future.

First, we were (and we still are) very happy about the status of the Plasma desktop as seen in KDE 4.x, but this doesn’t stop to wonder what can be improved.
The Plasma Desktop started to migrate towards QML since quite some time, but it was clear that the real focus in Qt 5.x would have been QML2.
That’s awesome, because QML2 solves many limitation in performance that QML1 and the QGraphicsView framework had in Qt 4.x.
But that was also a problem, since Plasma1 was tightly coupled with QGraphicsView, this meant: a lot of work ahead.
What we wanted, was the plasma platform itself completely independent from any graphical system itself.
From a big monolith-that-provides-everything, libplasma would have become a way smaller library (roughly 1/3 of the code of the plasma library in 4,x), providing a *model* for the layout, and utils as painting utils and the usual data access, but the representation of this model, would have been completely up to the shell (more on that next entry).

I remember starting a branch of libplasma back in summer 2011 at the Berlin desktop summit (that was also when the Frameworks development seriously started to seriously gain steam). The thing lived as mostly a proof of concept for a while.
Fast forward at the end of 2012 and we had a minimal shell that started correctly and could correctly restore a layout of applets, in a minimal desktop (no panel yet!).
The work proceeded and the features got back one by one.
In the meantime many new people joined the effort (Some thanks to Blue Systems, some volunteer) significantly speeding up the process.
Fast forward to the beginning of 2014 and it was possible again to use it as a basic main desktop (eat your own dogfood).
Just to give a little idea of the amount of work, there are around ~5100 Plasma5-related commits only on the plasma-frameworks repository, if we count all the workspace parts, it would be a way bigger figure.
It has been a long road, with some (quite) rough moments in the middle for sure, but looking back I’m pretty proud of what we achieved, of what i did, and what every single member of the team did to get here.
But this, this is

Just the beginning

This is the first release of a new chapter of Plasma, in which a new release method will be used to celebrate the diverity of the KDE community.
We used to have a 6 months “big release” of all things KDE, called in the beginning just “KDE”, then “KDE SC”, but this release is not that anymore, because KDE grown a lot in the past years, is not just that anymore, and “a single release of everything” scales only so much.

So, let’s take a step back and see what is KDE: it is a community that can offer you a range of very different things:

Want a primary user interface for your Desktop, Laptop, Tablet, Media Center? There is Plasma, tailored explicitly for the particular device is running on. Desktop and laptops have an interface optimized for mouse,keyboard and trackpad input, Plasma Active and Plasma Mediacenter are instead tailored on the constraints those different kind of device pose instead.
Do you need a particular application for a particular task? The KDE community offers a wide range of applications, from media players, communication tools, games, to a kickass office suite, to one of the best painting applications on the market (not best on Linux, not best among Open Source ones, the best, period) and countless others.
They are free software, they are multi platform and supported by a vibrant community of developers.
Are you a Qt developer that is working on a new application, and need more functionality? KDE Frameworks offers a wide variety of libraries and frameworks to chose from that can dramatically decrease the amount of work needed to do a big, polished application.
And in the latter case, if you want, of course your project is more then welcome to join in the KDE family, as other formerly external projects already did, like KDEnlive or GCompris

This release of The Plasma Desktop Workspace can be used for day to day use already, even tough it’s based on very new technology, so some youth problems are expected as well. Also, while the integration between KDE4 and Plasma5 applications is good, you may want to wait more applications ported to Frameworks 5 before jumply completely full on a pure Plasma 5 environment.

The cycle

So, when a new version will arrive? how do you check if new applications come?
The development cycle will be much faster now: you can expect a new release of the KDE frameworks (so the libraries, *not* the applications) every month, while Plasma5 will be each 3 months instead for now.
Anyways, new goodies should hit your distro of choice way faster than it used to be in the past.

Next time, I’ll write about what to expect in this release and the next ones about the user experience, the developer experience, and random musings on the future.

Plasma++ at Randa

Pretty busy days here at Randa. On the Plasma front some important decisions have been taken and a lot of work is now being done in this direction.

There is now a big traction in rewriting our current plasmoids in QML, such as the notifications I talked about some days ago, and many more that are coming.

The plan for the future is to have 100% QML-based workspaces, with as little changes as possible feature-wise compared to the current one, just with a smoother feeling 😉

This is only the first part of the road, and this is arriving already today, with each release of the Desktop workspace more complete, while Active is already 100% QML from day one.

What will happen next? Together with Qt5, there will also be the release of the next major revision of QML, that expands the language and changes the technology behind. Among the other things, everything will be on an opengl scene and the JavaScript bits will be managed by V8.

This comes at a price: only pieces of the user interface that are written in QML can be loaded in an environment based off QML2. hat means the old code based on QGraphicsView (and part of the old C++ API) has to go.

This wasn’t an easy decision, but it will make things dramatically easier in the future.

On QML2, we’ll have a lot more performance, guaranteeing a way smoother experience (with QML2 you can get 60fps in 1080p on an humble raspberry pi after all)
More stable, because most user facing code (especially most 3rd party) becomes scripted
Easier to write plasmoids: lowers the barrier for contributions and lowers the barrier in experimenting new innovative approaches for the UX
Also the internal library will be way easier to approach for new developers, because it will be way smaller and simpler
It will also be simpler to take and use the Plasma library for new things, like in application’s dashboards, or just using its QML components.

This is a long term plan: The work on the new Plasma library version started now, and we expect a working shell based on the new framewok and Qt5 in about 18 months or so.

I’ve just got a first preliminary version of libplasma building without QGraphicsView dependencies, and the binary is about two thirds of the size it had before, so this is an encouraging start 😉

It’s again an exciting time when we can design a new architecture, have crazy ideas, trying them out, and any input or help is very appreciated.

You can see the progress of the tasks that are added as the work proceeds here, and talk or claim some tasks for yourself at the usual channels of communication, plasma-devel@kde.org or the #plasma freenode IRC channel.

Notifications, let the redesign begin

So, it seems it’s that time of the year again… the plasmoid used in KDE Plasma Desktop to display notifications and the progress of transfer jobs started to really show its age, due to some bad limitations in the old QGraphicsview code to handle complex layouts, so it appeared quite buggy and not so smooth to use. Yes, I’m aware that sometimes it started to dance resizing itself several times in a row, and there wasn’t much to be done on that regard… Until now 😀

The fact that there is some research/development being made to build a new backend for notifications that will support many new features, more “modern” to be actually useful with the applications that are so heavily “communication” oriented(both desktop clients and web stuff), that became essential part of out workflow.

The story begins more than a year ago: we needed a way to display notifications on Plasma Active, and obviously the desktop applet used back then wasn’t enough.

Since we would have to rewrite it in QML anyways, we started it, at the beginning as a thing used only in Plasma Active.

Here below is the status that will be shipped together Plasma Active 3, in about 2 weeks (more on that later 😉

WebM version

Then, as it became more and more feature complete, it was obvious that it could have replaced the one used in the desktop quite easily.

But wait, we have different input methods so we need two completely different things otherwise one won’t be usable on the other platform, right?

Wrong 😉 what we need is a different UI, and not even dramatically different: we need it adapted for a different input method and yet still familiar, the actual code difference needs to be very little.

In QML plasmoids, we can specify some files that will be used only in some platforms, so the system will automatically pick the most suited one. Also the basic component used (buttons, scrollbars etc) while having exactly the same API on all platforms, they can have a radically different behavior (or even, a completely different implementation).

Here is the plasmoid that is going to be merged and shipped with our next iteration of the desktop:

OGG version

While it looks very similar, there are some important differences:

Different theme/look (that was easy;)
The desktop version has scrollbars, the touch version works by flicking and has scroll indicators that automatically appear/disappear
The touch version has way bigger hit targets
The desktop version has mouse over effects, the touch version doesn’t
The text in the notifications can be selected with the mouse in the desktop version, and there is a right mouse button menu that allows to select/copy to clipboard
Instead, with an horizontal drag on a notification on the touch version, it will be moved, and if “thrown” outside the window, it will be deleted.

Difference in code? a couple 100-something lines QML files that are chosen either one or the other, that’s it.

The desktop version has more or less the same functionality as the old version shipped with 4.9, the changes are mostly about making the ui a bit simpler.

Also, this new notifications plasmoid is all about the user interface. It has been designed to be as easy as possible to change (or add a new one) the underlying notification system, so it will fit pretty well in the new system that is being researched right now.

Plasma QML documentation

Just a brief heads up. As you know, from now on the recomended way to write plasmoids will be using QML only, and using the new components api for common widgets such as buttons, sliders etc.

What’s cool about this API is that is as compatible as possible with Symbian and Harmattan(N9/N950), so porting to and from those platforms just became a tad easier (That’s especially important in the perspective of Plasma Active).

The documentation of those components just landed on api.kde.org, and can be seen here.

Other useful resources for QML plasmoids:

Qt QML documentation
Getting started
Plasma specific QML api introduction
Javascript API describes the global plasmoid object that gives access to plasma specific features

A big thanks to everybody that helped writing the documentation, to Antonis that helped with the script for the generator and Allen that helped with the setup of the infrastructure to api.kde.org 🙂

Brand new Widgets explorer

The rewamp of the KDE Plasma Desktop is continuing: in the 4.8 release it got a completely new QML based device notifier (already quite improved for 4.9), now a new redesign has landed in master, scheduled for the 4.9 release of KDE Plasma Desktop.

The Plasma widget explorer and activity manager have been rewritten from scratch in QML, giving it s much smoother look and feel, new animations for free and what I love most, a way simpler code base.

By replacing the activity manager and widget explorer with the new implementation, over 4000 lines of C++ were removed (traded with around 1000 of much more readable and maintainable QML): this makes it easier to maintain, easier to spot possible problems, easier to modify and experiment new ideas.

With the rewrite of the various components of Plasma Desktop in QML I expect to slash away most of its C++ code base, making the entry level for contributors significantly lower (and being able to finally close long standing bugs 😉

How does it look now?

And the Activity manager: designed to look as coherent as possible with the widgets explorer:

Here showing the inline ui to configure and delete an activity

The overall design is almost the same, but the layout has been redesigned to overcome a problem of the old implementation: it looked quite crowded and dirty, because elements were too cramped together, not very well aligned and sizes were quite eterogeneous. Now we paid a lot of attention about the sizes and positioning of the elements, as shown below, everything is positioned along a quite precise grid, that makes the view look less crowded that it actually is.

QML widgets explorer alignment

I a good trend can be established here, for each release of the KDE Plasma Desktop having some element not only rewritten, but its UI becoming significantly more elegant with few but important improvements in the look or in the behaviour.

Little big cleaning details

Disclaimer: this entry won’t talk about a certain thing happened those days, and I won’t in future entries as well, until there is actually something to talk about.

There is a thing that came to my mind some days ago, when i finally decide to fix a little visual inconsistency that was bugging me since some time.

In the KDE Plasma Workspace 4.7, the clock and keyboard layout indicator will look like this (landed in git earlier this week):

perfect clock text

The style of the systemtray is now much more coherent, all thanks to a quite slight change of look in those two little elements, in the specific, text svg-themed themed like the systray icons (that is by the way usable by everybody since it has been placed in the public plasma api)

A thing that will come for 4.7, is a series of many small improvements of many little pain points, may be either a small missing feature, a fix of a little inconsistency, or, in any case something small, easy to contribute that everyone that is eyeingto start to do some patches can find as an easy entry point.

There are already some heroes that have joined and started to review all shipped plasmoids for some points of behavioural consistence. First step, now, thanks to them in 4.7 all plasmoids will have a working “apply” button in their settings dialog.

You can make the diffrence too 😀

Separed at birth

Here are two screenshots of Microblog plasmoids. There are two nice novelties that can be noted here (due respectively to KDE Plasma Workpace 4.6 and 4.7) are the support of “reply to message id” in the twitter API, so in Identica conversations will appear correctly threaded (sadly there is still no way to retrieve that threading information from the API) and the support for marking messages as favorites, that will appear in 4.7

On the right is the usual good old stock Microblog plasmoid, on the left it’s the plasmoid rewritten in QML+JavaScript. It is on early development but is probably going to replace the fomer (there are still some layout differences and details, all of this is going to get polished).

What’s nice is that in two days of development that plasmoid reached about 90% of the features the C++ counterpart gained in well, ages 😉 so I’m quite confident the development speed in Plasma will get a dramatic boost.

All of that code in in KDE svn playground repository, I will give more info when all will move to git together with the rest of KDE software.

Good old habits: notifications again

Activities

We didn’t put or effort only in the mobile environment or the new declarative “way of doing plasmoids”, but the general polish of the traditional desktop shell, the “most immediate need” for users is quite high on our priority list too.

Chani recently blogged about the last progress of the activities management: in the Plasma Desktop workspace 4.6 finally the advantages are starting to be exposed to the user. In brief: can virtual desktops stop and start applications on demand when they switch? can an application be on 2 out of 5 vd? can a vd be stopped and when recreated be restored exactly as it was? (wallpaper, desktop widgets, running applications etc) can the user remove a non empty, non last virtual desktop? Can an application behave in a way that is specific for a certain desktop, like showing only work related contacts?

Answer to all of those question is a discomforting, deep, structural no. If we ask those questions for the activities, the answer become yes, and the difference of purpose of those two things becomes evident. virtual desktop -> spatial arrangement of windows. Activities -> what I’m doing. There really is little overlap between the two things. Spatial arrangement is often used as activity separation, but is condemned to remain an half backed solution.

Notifications

Yes, notifications again! There won’t be any very big turning upside down of the notification an job area for 4.6 The form it’s “stabilizing”, with minor tweaks that can enhance quite a lot the look and usability of it, let’s see in brief what 4.6 will bring to the notifications and jobs area:

Slightly revised look: better spacing, less visual noise, more pixel perfection
More compact layout of the jobs widgets
A speed plotter for job in the expanded view to be able to see what’s going on in the transfer of a single file
Global jobs progress bar is hidden when only one job is running
Notifications can be dragged in the desktop again
Only one scrollbar, and only when is necessary: everything scrolls and it’s preferred to keep visible active jobs rather than the notification history
Notifications history tabbar is hidden when only one type is present
Big icons in notifications to help to identificate what it’s talking about at a glance
Action buttons moved beside the test to have a smaller notification widget
It is possible to drag anywhere the notifications popup, so regardless of where the notifications Plasma widget is, they will appear in the place it works better with your workflow.

Since a picture is worth 3000 bullet points here are some screenshots 🙂

Mart

Tale of a little pixel