Tag Archives: plasma

QtQuickControls2 and Desktop apps

GraphicsSoftware

In the screenshot below, the desktop/Breeze-looking scrollbar it’s actually a control coming from QtQuickControls2.
spectacle-c13179

Since one of the goals of Kirigami is to support also desktop applications, while working on Kirigami 2 (that is mostly porting it to be based on top of QtQuickControls2) I had the need for it to continue to integrate with desktop applications as well.
Unfortunately, desktops are not the primary target for QtQuickcontrls2, and while in Qt 5.9 some much needed desktop-related features, such as mouseover effects are getting back in, being as unrecognizable as possible with QWidget-based applications is definitely not in the roadmap.

Luckily, theming QQC2 is easy, so I’ve started a QtQuickControls2 style that integrates with desktop QStyle-based widgets (actually, based upon the QtQuickControls1 QStyle painter machinery).

If we are serious in using QtQuickControls2 in applications shipped together Plasma, we also must make sure they integrate well with the Plasma desktop’s Breeze look and feel.

I started by theming the scrollbar because I felt it was one of the hardest controls to do.
in QtQuickControls2 the scrollbars are supposed to be an attached property of flickables..
This is pretty simple for the mobile use case, turns out it’s a nightmare to create scrollbars that behave like we are used to in the desktop (unless you’re on mac, which insists to look more and more like iOS), which need to be

  • always visible
  • have optional little arrow buttons for increment/decrenent
  • be besides the flickable, not overlapping the contents, because again, they’re always visible
  • use the global desktop theme

I’ve been able to do all of the following, tough it’s necessary to reintroduce the QtQuickcontrols1 component called ScrollView (which imo was a mistake to remove in QtQuickControls2) which can correctly lay out and size the Flickable relative to its ScrollBar.
Hopefully, you’ll be soon able to build an application with QtQuickcontrols2 and Kirigami2 that feels right at home in a Plasma desktop.
What about Plasma-themed QQC2 controls for plasmoids? that will come too, of course!

Icon colors

GraphicsSoftware

Breeze icons are very simple SVG files, especially the ones used for actions that are mostly monochromatic are very simple, and that’s part of their appeal.
Since some time, Plasma themes that are SVG files as well have the capability of being colored with system themes.
So, why not doing this for every icon as well?
One problem with monochromatic icons is that they can lose contrast in particular situation: when the application uses another color scheme or in places such as in menu items uder the mouse, that get a blue background, giving a not too visible dark gray on dark blue.
That’s one of those “last mile” polishing issues that may be small, but have quite a big impact on the perceived quality of the finished product.

Starting with Plasma 5.7 Icons will behave the same way as Plasma themes: they can have an internal stylesheet which colors will be replaced at runtime with the colors from the system theme.

Here, Dolphin with the colors theme “Wonton Soup” and all the breeze icons following the text color of the theme:
dadel1

Some applications, like Gwenview can use a completely custom color scheme, in the case of GwenView, it switches to a dark color scheme when fullscreen, regardless of the normal system color theme:
colors2

Icons that are in a “selected” state such as the menu item under the mouse or the current dolphin sidebar item change their color, just like the text does too:
colors1
Here with some custom colors for the highlight areas:
colors3

How to create a compatible icon?

First of all, Big kudos to Andreas for updating the whole breeze theme to the standard described below 😀
This is a quite minimal SVG file that supports colors from the system theme (Plasma Svg themes follow the same convention):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="22"
   height="22"
   id="svg3049"
   version="1.1"
   inkscape:version="0.91 r13725"
   sodipodi:docname="coloredsvgicon.svg">
  <defs
     id="defs3051">
    <style
       type="text/css"
       id="current-color-scheme">
      .ColorScheme-Text {
        color:#4d4d4d;
      }
      .ColorScheme-Background {
        color:#eff0f1;
      }
      .ColorScheme-Highlight {
        color:#3daee9;
      }
      .ColorScheme-HighlightedText {
        color:#eff0f1;
      }
      .ColorScheme-PositiveText {
        color:#27ae60;
      }
      .ColorScheme-NeutralText {
        color:#f67400;
      }
      .ColorScheme-NegativeText {
        color:#da4453;
      }
      </style>
  </defs>
  <metadata
     id="metadata3054">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title />
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Capa 1"
     inkscape:groupmode="layer"
     id="layer1"
     transform="translate(-421.71429,-525.79074)">
    <rect
       y="525.79071"
       x="421.71429"
       height="22"
       width="22"
       id="rect4102"
       style="fill:currentColor;fill-opacity:1;stroke:none"
       class="ColorScheme-Text" />
  </g>
</svg>

Here there are two important parts.
The first is the definition of the actual CSS stylesheet:

<style
       type="text/css"
       id="current-color-scheme">
      .ColorScheme-Text {
        color:#4d4d4d;
      }
      .ColorScheme-Background {
        color:#eff0f1;
      }
      .ColorScheme-Highlight {
        color:#3daee9;
      }
      .ColorScheme-HighlightedText {
        color:#eff0f1;
      }
      .ColorScheme-PositiveText {
        color:#27ae60;
      }
      .ColorScheme-NeutralText {
        color:#f67400;
      }
      .ColorScheme-NegativeText {
        color:#da4453;
      }
      </style>

The colors defined in Text, Background, Highlight etc will be replaced with the corresponding colors from the system theme (look at the Systemsettings module to configure colors to see what colors they actually are)
This also defines a very minimal palette of “semantic” colors: you have the foreground and background colors for purely monochromatic shapes, and other colors for small accents that make the icon slightly more expressive than purely monochromatic such as Highlight, positive, negative (an “x” icon to close will be usually of “negative” color)

The other important part is the actual definition of the shape:

<rect
       y="525.79071"
       x="421.71429"
       height="22"
       width="22"
       id="rect4102"
       style="fill:currentColor;fill-opacity:1;stroke:none"
       class="ColorScheme-Text" />
  </g>

The rectangle has class=”ColorScheme-Text” that will make the stylesheet match to the class definition of ColorScheme-Text, that defines a color.
In order to actually apply that color, you can see the attribute style=”fill:currentColor”. It’s important no other colors are defined in the style attribute.

Little Plasma things at CERN

BlaBlaSoftware

Over the second week of March I’ve been at the sprint at CERN.
It has been an amazing experience seeing those very big toys, where the cutting edge research is done (noted with satisfaction the presence of Plasma desktops in the CMS control room)
On my side, some interesting little things happened:

All new systemtray finished and merged

During the sprint I’ve merged a thing i was working since a while: the system tray of Plasma was one of the most complicated plasmoids out there due to the very peculiar things it does.
Its code was really showing its age (it surviced at least 3 portings across different technologies) and even tough the old Xembed-based systray icon protocol was dropped, its architecture was still decidedly all
It has now been completely rewritten, its code is now way simpler, using less layers of proxymodels and went from ~2000 locs of C++ to ~300
While completely new, the users shouldn’t even notice any UI change, the only noticeable change should be less bugs and working better 😉

Kirigami

kirigami
During the sprint, a new repository was born.
What was Plasma Mobile components is now residing in a separate git repository:
https://quickgit.kde.org/?p=kirigami.git
Kirigami (The names comes from a Japanese paper folding craft similar to Origami, but unlike Origami cutting the paper is allowed) is a set of QtQuick components at the moment targeted for mobile use (in the future desktop as well) targeting both Plasma Mobile and Android. It’s not a whole set of components, all the “Primitive” ones like buttons and textboxes are a job for QtQuickControls (soon QtQuickContrls2) but it’s a set of high level components to make as easy as possible making applications that look gorgeous on mobile devices that follow the Visual Design Group UI guidelines.
The target of those components is anybody that wants to do an application using QtQuick as its main UI, especially if targeting a mobile platform, without adding many dependencies. They work both in Plasma Mobile and Android.
It will eventually become a Tier-1 KDE Framework.

Subsurface

While I was refining the components, it turns out a piece of desktop software just has its first release of its Android port, it is already using a tech preview of the Kirigami components: it’s Subsurface a dive log software started some years ago by Linus Torvalds (in GTK+) and recently ported over Qt (here a talk by one of its main developers Dirk Hohndel about the porting process https://www.youtube.com/watch?v=ON0A1dsQOV0)
It’s awesome having already an early adopter (which has been a pleasure to work with) for the components and also means we are getting a ton of feedback on it.

Tooltip handling

GraphicsSoftware

An informational tooltip in Plasma is an item that shows extra informations for items such as task items, and is a single entity, moving along what you want to know more of, rather than magically appear out of nowhere (that’s the kind of “magic” the human brain doesn’t like).
A problem with Plasma tooltips was that they tried to animate themselves, that is usually not a good idea on X11, due to its old async architecture.
But KWin to the rescue! if we want a smooth animation of both the position and the size of the tooltip, the compositor is the place where to do it.
With its scripting user interface, it was even possible to implement it completely in JavaScript.
You can see it in this video taskbar tooltips animating and resizing/morphing in a similar way Windows 7 does.

Btw, the animations in he video looks way less smooth than are in reality, due how terrible screencasting is under X11, but for that:

Wayland will fix it!

Wayland will fix it!

Plasma in all colors you like

GraphicsSoftware

The Plasma theme system had a feature (since many years, actually) in which SVG elements done in a certain way can be recolored with colors coming from a theme file.
The Breeze Plasma theme (and now all the monochrome Breeze icons too) was all done in this way, in part to prepare what I’m, presenting today:

If the colors in the SVG can follow a color scheme defined in the theme, they can follow also a system wide color theme no?
For Plasma 5.6, (as a feature that was requested really a lot) the default Breeze theme, while by looking familiar, it will change color following the applications scheme.

However, if you prefer to maintain a clear distinction between the workspace and the applications (And I’m definitely among them), there are still available the themes “Breeze Light” and “Breeze Dark”, just as before (Oxygen and Air also received some nice visual updates).

Let’s look at some screenshot:

So far so normal, typical Breeze theme we had so far.
dynamictheme1

Let’s try with a different color set:
dynamictheme2

Or another one, this time darker.
dynamictheme3

There is a Blur in my Wayland

Software

Over the last few days I decided to help Martin a bit with the ongoing effort on Wayland, since there are still many parts of work missing in order to have a full Plasma Wayland session to just work, but it’s impressive how fast it’s getting there.
It was just a tiny part but is worth sharing it as it brings pretty pictures! (and shows how easy is to contribute).
The popups of the plasma shell need custom positioning code as normal applications can’t position themselves anymore for security reasons, plus KWin uses its effects framework to do a couple of things on plasma panels and popups:

  • Shadows: the shadows are rendered by KWin, they aren’t really a part of the window, as the shadow must not count anything in the position and resizing phase, but just a visual effect on it, it’s also more semantically correct.
  • Background effects: both the panel and the popups have a blurred background plus a contrast/saturation effect, to make it more readable and prettier.

After hooking a protocol to control such effects into wayland, here’s the result, almost undistinguishable (there is still a pretty visible graphical issue, points for finding it) from your current X11 Plasma 5.4 session:

snapshot5

So, what needed to be done?

  • KWayland protocols: each KWin effect that can now be controlled with X properties need its own wayland protocol extension in order to achieve the same thing, I wrote one for blur behind and background contrast (shadow was already there). The good news here is that Martin is working on a tool to auto generate the binding code from the XML specification of the protocol.
  • KWayland-integration repo: The effects that had KWndowSystem API to control them, need a Wayland implementation as well, this goes in the KWindowSystem wayland plugin contained in the kwayland-integration.git repo.
  • Modify the KWin effect: then the kwin effect needs to read the data that the client wrote on the surface with the new kwayland protocol and control the effect, in a way that is behaviorally identical to the X11 way, that came from reading X properties from the window

As an “user” of the infrastructure, I’m very impressed about the work that went in the Wayland port of KWin and from the KWayland framework: it really makes using a very challenging and “peculiar” plain C API very easy and elegant in a way familiar with our cozy C++/Qt world.
I can say that is a learning curve soft enough for everyone to jump in and help the big scary transition if they feel to.

Plasma Theme Explorer

Software

In a while, together Plasma 5.3 will be released (independently) a new package: plasma-sdk, containing some very useful tools for development around plasma, some old KDE4 era ones will return, some are new.

  • plasmate: lightweight IDE for plasmoids (experimental port to KF5, work in progress)
  • plasmoidviewer: useful to test a single plasmoid, in different formfactors (like desktop, panel, and so on)
  • plasmaengineexplorer: test and debug tool for dataengines.
  • cuttlefish: tool for exploring icon themes
  • plasmathemeexplorer: tool used to explore Plasma themes, let’s talk about this one.

plasmathemeexplorer
Plasma theme explorer is a new tool that is targeted at designers of Plasma themes.
It can open any installed theme and preview it as a grid of thumbnails of the actual elements rendered.
The thumbnails all have a green or a red dot in it. The ones with a green dot mean that the theme directly provides that element, red means the theme doesn’t have it, so it will fallback to the default theme (currently Breeze). So it makes it very easy and fast to assess the completeness of a theme and to decide what elements to do in order to make the theme more complete.

plasmathemeexplorer1
A sidebar on the right will show a bigger preview of the theme element, together a short description of what the element is for, and an edit button (enabled only for themes installed locally in the user home).

Clicking the edit button, will open the SVG of the theme in inkscape, and will run a little sanitizing script on the file after inkscape is closed.
If the theme doesn’t provide the particular element (and we have a red dot in the thumbnail) the corresponding file from Breeze will be copied in your theme folder, and that one will then be opened in inkscape, making the job of completing a theme easier and faster.

Whops I didn’t mean to delete that

Software

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.

Choose your Look and Feel experience

GraphicsSoftware

Plasma 5.1 will make way easier to fine-tune their workspace to their needs.While already very powerful, it was not always trivial, so now on one hand it will be possible choose between plasmoids that offer the same feature with a very simple UI.
On the other hand, ever wanted to set themes, look and feel of your desktop, but was discouraged by how many places you had to change themes to make the experience as you wanted? being icon theme, widget style, plasma theme, cursors etc…
Plasma 5.1 will support the concept of Look and Feel packages (or “mega themes” if you like) Basically an one stop place to set the look and feel of the whole desktop.
lookandfeel
To start, there will be a “Breeze” and an “Oxygen” experience, and in the future, let’s hope yours too 😉

In the first release it will be very basic, but in the future it will grow more complete, allowing to more fine-tune individual components, downloading new “look and feels” from the internet etc.

Technically, Look And Feel themes are plasma packages, that contain two things: configuration files for defaults such as icons, colors, cursors etc
and QML files for certain parts of the workspace ui, such as the splashscreen, the lockscreen etc, allowing from very simple things (like a theme that just sets icon theme, widget style etc) to very comprehensive ones, that change completely the logout dialog, lockscreen etc.

On Plasma5: present and future

BlaBlaSoftware

This is the second part of my ramblings about the Plasma 5 release, just after it come out.
plasma-5-banner
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.