DWDs are not CSDs, and all theming and drawing is handled by the window manager and decoration. In addition, applications only export the structure of their widgets, they do not pre-draw or draw the widgets themselves. Applications would have little or no say in how their decorations look, just like traditional SSDs.
That being said, we don’t want DWDs to be absolutly rigid, we are looking at ‘safe’ ways applications can do basic branding on themselves in a reasonable manner, which decorations could potentially integrate without excessive effort. The main thing we are looking at is allowing applications to offer a colour pallet which decorations could use to tweak their appearance, but DWD ultimately would put the power in your hands and options would also be provided to disable unwanted hints and effects for more consistency. A primary sentiment with DWDs is that the user would be completely in control of all aspects DWDs would provide.
14 years ago, I started creating an image viewer. Back then it felt like a good project to get started with graphical application development for my newly installed Linux system. Little did I know... In 14 years Gwenview went through one toolkit change (GTK+1.2 to Qt2/KDE2), got ported to Qt3/KDE3, moved from SourceForge CVS to KDE Extragear, got ported to Qt4/KDE4, became the default image viewer of KDE4 and finally got ported to Qt5/KF5.
You may be aware I spend most of my free time these days on some other project. I am not completely out of Qt and KDE development however: I have a number of small side projects, many of them Qt-based, to which I want to give a bit more visibility. Stay tuned for more announcements.
Since jumping to an testing install of Plasma 5 in my upgraded Kubuntu, I've been filing bugs as I find things not working. It took me a few days to notice that redshift no longer worked, because I didn't always use it. But when I had my eyes dilated for my annual eye exam, I needed it! And it crashed.
I love filing bugs using ubuntu-bug from the commandline. I would love to see KDE build this capability as well, because the little application gathers useful information automatically, and uploads it to the bug tracker. Man ubuntu-bug says it reports problems to your distribution's bug tracking system, using Apport to collect a lot of local information about your system to help the developers to fix the problem and avoid unnecessary question/answer turnarounds. Dr. Konqui does this sometimes, but a little cli app would be nice as well.
Today we did an important change in how KWin will distribute its assets in the upcoming 5.2 release. When we started our thoughts about the Look’n’Feel Package and how we want to have meta themes for the complete Plasma workspace we also wanted to have this for the Window and Desktop switcher provided by KWin. So the structure of the Look’n’Feel Package already has all the pieces for including the Window and Desktop Switcher, but it was not used. Now we finally addressed this for the 5.2 release and moved the default switcher into the Look’n’Feel Package and KWin can locate the switchers from the Look’n’Feel Package.
For some time I've been considering what to do about Jovie which was previously known as ktts (KDE Text To Speech). Since before the first KDE Frameworks release actually, since kdelibs used to host a dbus interface definition for the KSpeech dbus interface that ktts and then Jovie implemented. I have a qt5 frameworks branch of Jovie, but it didn't make much sense to port it, since a lot of it is or could become part of the upcoming QtSpeech module. So Jovie has no official qt5 port and wont be getting one either.
Most of the window decorations available for KWin are not native decorations but themes for a native theme engine, such as deKorator, Smaragd, QtCurve or my own Aurorae. Themes are much easier to design and to distribute than a native decoration which has to be implemented in C++ and be distributed by the Linux distribution. Thus themes are an important part of the decoration system.
But we did a very bad job of integrating the themes into our configuration system. The configuration system only knows about native decorations and doesn’t know that the native decoration is in fact a theme engine. This makes selecting a theme difficult, because a user has to first select the theme engine and then configure this to select the theme. Downloading new themes through GHNS is also difficult as again it requires to go through the configuration of the theme engine. We can do better.
I started working on that port back in the last KDE Telepathy sprint in Barcelona last April. Back then, I started to work on it because I have been doing heavy usage of the KTp plasmoids back when using the KDE 4 Plasma series and I didn’t want to live without them. Back then, I only ported the minimum parts of ktp-common-internals so it would work with KF5, as well as the plasmoids. It was quite some work, but definitely worth it since I’ve been using them ever since, and it’s worked wonderfully.