Please test improved Plasma Theme switching for Plasma 5.16

Help testing the Plasma Theme switching now

You like Plasma Themes? You design Plasma Themes even yourself? You want to see switching Plasma Themes working correctly, especially for Plasma panels?

Please get one of the Live images with latest code from the Plasma developers hands (or if you build manually yourself from master branches, last night’s code should be fine) and give the switching of Plasma Themes a good test, so we can be sure things will work as expected on arrival of Plasma 5.16:

If you find glitches, please report them here in the comments, or better on the #plasma IRC channel.

Plasma Themes, to make it more your Plasma

One of the things which makes Plasma so attractive is the officially supported option to customize also the style, and that beyond colors and wallpaper, to allow users to personalize the look to their likes. And designers have picked up on that and did a good set of custom designs (store.kde.org lists at the time of writing 470 themes).

And while in the last Plasma versions some regressions in the Theme support had sneaked in, because most people & developers are happily using the default Breeze theme, with Plasma 5.16 some theming fixes are to arrive.

Plasma Theme looking good on first contact with Plasma 5.16

The most annoying pain point has been that on selecting and applying a new Plasma Theme, the theme data was not correctly picked up especially by Plasma panels. Only after a restart of Plasma could the theme be fully experienced. Which made quick testing of themes e.g. from store.kde.org a sad story, given most themes looked a bit broken. And without knowing more one would think it is the theme’s fault.

But some evenings & nights have been spent to hunt down the reasons, and it seems they all have been found and corrected. So when one clicks the “Apply” button, the Plasma Theme instantly styles your Plasma desktop as it should, especially the panels.

And dressing up your desktop to match your day or week or mood or your shirt with one of those partially excellent themes is only a matter of some mouse clicks. No more restart needed 🙂

Coming to your system with Plasma 5.16 and KDE Frameworks 5.59 (both to be released in June).

Make your Plasma Theme take advantage of Plasma 5.16

Theme designers, please study the recently added page on techbase.kde.org about Porting Themes to latest Plasma 5. It lists the changes known so far and what to do for them. Please extend the list if something is yet missing.
And tell your theme designer friends about this page, so they can improve their themes as well.

Advertisements

Some theming fixes to arrive with Plasma 5.16

One of the things which makes Plasma so attractive is the officially supported option to customize also the style, and that beyond colors and wallpaper, to allow users to personalize the look to their likes. And designers have picked up on that and did a good set of custom designs (store.kde.org lists at the time of writing 454 themes).

Intended changes and unintended changes

In the 11 years since Plasma was released first (January 11, 2008) there has been some evolution of the theming options. Sadly also sometimes regressions in the support of older options were introduced, mainly in the early phase of Plasma 5 when code was ported to QtQuick 2 and the new default theme Breeze did not expose the regression or even triggered some changes for its special needs or for simplifications it allowed.

Given Breeze as default was pleasing to most, and possibly some alternative theme designers were lost during the longer phase from a pleasing KDE4 to an again pleasing Plasma 5, and new theme designers made their themes directly matching latest Plasma 5 Theme support, the piled-up regressions were not a real issue for those contributing.

Well, not a real issue unless on started to restore an old theme like “Fluffy Bunny”. And was wondering why it looks broken. And then wondering the same while playing with all the other old themes still available on store.kde.org.

So much partially good artwork being broken made my heart bleed, and in the absence of own designer abilities it was time to document the regressions as well as fix some code where possible to restore previous variability.

Teaching Porting to Plasma 5

So, theme designers, please find a new page on techbase.kde.org about Porting Themes to latest Plasma 5. It lists the changes known so far and what to do for them. Please extend the list if something is yet missing. One might test the fixes in the code against one’s themes with latest development versions of Plasma using Live images.

Fresh old Air & Oxygen

And even the Oxygen & Air themes, the default Plasma themes during KDE4 times, while being maintained as official themes part of current Plasma releases, had suffered some small regressions (e.g. analog clocks hands rotation point or progressbar height). No more, with Plasma 5.16 the visual experience of Oxygen & Air should be closer to the original.

Luxury on the borders results in bad looks

Sadly there is one thing which is not so easy to fix: Plasma code now assumes for any frames (like with borders of panels & pop-up dialogs) that the actual border visuals are negligible and the margin from the outside to the content is the same, with border on the side enabled or not. With luxurious decorated borders (like Fluffy Bunny or Spoons Original) this sadly results in bad looking bigger margins on sides where the border is disabled (see details). Which is sad especially given that High DPI display actually would allow more fanciness, even more when in the future Flat design gets replaced by whatever new trend. My passive dreams & hopes are on for Plasma 6 😉

Separating Plasma 5 compatible themes on store.kde.org

And while there now is a list of things to do to make old themes work again, many themes on store.kde.org no longer are maintained. There is talk about separating those, e.g. at time of Plasma 5.16 release, so there would be a clean list of working and maintained themes for latest Plasma 5.

The Second Return of the Fluffy Bunny

The old among us might remember KDE4 and something one could call the “Pink Phase”, when people explored how “interesting” they could make their digital workplace by applying certain colors and themes… don’t most of us sometimes need a fluffy and color-intensive world to escape to… if only to learn to value reality again, when things get too fluffy 🙂

The most outstanding work useful for that had been done once by Florian Schepper who created the Plasma theme “Fluffy Bunny”, which won hearts over on first sight. Sadly though the theme bundle got lost, was recovered, only to then by the times getting lost again from the stores. Time to repeat that, at least the recovering 🙂

And so last week the internet and local backups had been scanned to restore the theme again, to quick first success:

Well, besides the regression Plasma5 has over the old Plasma 😉 With only thin & non-tiled border themes trendy and used the last years, sadly current Plasma has some issues, also does it assume that borders of panels are rectangular when creating the default BlurBehind mask. Some first patches (1, 2, 3) are already under review.

Get the initial restored version from your Plasma desktop via System settings/Workspace Theme/Plasma Theme/Get new Plasma Themes…/Search “Fluffy Bunny” or via the Web interface from store.kde.org and enjoy a bit of fluffy Plasma 😉

Next up: restoring the “Plasma Bunny” theme from the once drafted “Fluffy” linux distribution… less flurry, but more pink!
Update: First version of new named “Unicorn” is now up in the store for your entertainment.

All new Okteta features of version 0.26 in a picture

Okteta, a simple editor for the raw data of files, has been released in version 0.26.0. The 0.26 series mainly brings a clean-up of the public API of the provided shared libraries. The UI & features of the Okteta program have been kept stable, next to one added new feature: there is now a context menu in the byte array viewer/editor available.

Since the port to Qt5 & KF5 Okteta has not seen work on new features. Instead some rework of the internal architecture has been started, and is still on-going.

Though this release there is a small feature added again, and thus the chance to pick up on the good tradition of the series of all-new-features-in-a-picture, like done for 0.9, 0.7, 0.4, 0.3, and 0.2. See in one quick glance what is new since 0.9 (sic):

How to break your code porting from Q_PRIVATE_SLOT to context & function object based connection

TL;DR Beware of connections to function objects accessing class members which could be triggered during execution of subclass destructor methods.

Oh, those name-based signal/slot connections feel outdated!

So you are a happy embracer of Qt’s new QObject signal/slot connection way of coding based on function-pointer or functor objects, like myself. This compile-time check of signals and slots feels just so much better. And thus you also port any existing code to it. Including some which uses the pimpl approach for some public classes, borrowing Qt’s macros Q_PRIVATE_SLOT, Q_D & Co.:

class MyWidgetPrivate;

class MyWidget : public QWidget
{
    Q_OBJECT
public:
    explicit MyWidget(QWidget *parent);
    // [...]
    // setting a QWidget-subclass to be used as custom form in this widget
    void setForm(Form *form);
private:
    const QScopedPointer d_ptr;
    Q_PRIVATE_SLOT(d_func(), void handleFormDeleted())
};

// implementation side:

class MyWidgetPrivate
{
// [...]
public:
    void handleFormDeleted() { /*...*/ }
};

MyWidget::MyWidget(QWidget *parent)
    : QWidget(parent)
    , d_ptr(new MyWidgetPrivate)
{
    // [...]
}

void MyWidget::setForm(Form *form)
{
    Q_D(MyWidget);
    // [...]
    connect(form, SIGNAL(destroyed()), this, SLOT(handleFormDeleted()));
}

Got some time, let’s modernize the code

The old code calls to be changed into using a connection from the destroyed signal to a lambda expression calling handleFormDeleted() directly on the private object, with MyWidget instance as context object, thus removing the need for that Q_PRIVATE_SLOT:

class MyWidgetPrivate;

class MyWidget : public QWidget
{
    Q_OBJECT
public:
    explicit MyWidget(QWidget *parent);
    // [...]
    // setting a QWidget-subclass to be used as custom form in this widget
    void setForm(Form *form);
private:
    const QScopedPointer d_ptr;
};


// implementation side:

class MyWidgetPrivate
{
// [...]
public:
    void handleFormDeleted() { /*...*/ }
};

MyWidget::MyWidget(QWidget *parent)
    : QWidget(parent)
    , d_ptr(new MyWidgetPrivate)
{
    // [...]
}

void MyWidget::setForm(Form *form)
{
    Q_D(MyWidget);
    // [...]
    connect(form, &QObject::destroyed,
            this, [this] { Q_D(MyWidget); d->handleFormDeleted(); });
}

Looks fine & compiles. Code feels more future-proof with the compiler now warning if some signal or slots got changed/removed.

Ooops, crashing now?

Just… nooos, it sometimes crashes now, in the destructor of MyWidget. How that on this innocent looking change?

Reading once more closely the documentation of QMetaObject::Connection QObject::connect(const QObject *sender, PointerToMemberFunction signal, const QObject *context, Functor functor, Qt::ConnectionType type = Qt::AutoConnection) we notice the remark:

The connection will automatically disconnect if the sender or the context is destroyed. However, you should take care that any objects used within the function object are still alive when the signal is emitted.

Which subtly hints to the problem we now have: if the form instance is set as child widget of the MyWidget instance, it will be deleted when ~QWidget() is run as part of the MyWidget destructor. And then emit the destroyed signal. At that point in time this as seen by the function object no longer is a proper MyWidget instance. And things go *boom*.

The old string-based connection as well as the member-function-pointer-based one handle that case for us, by some QObject magic using virtual methods which catch that the receiver no longer is a MyWidget and somehow then just drop the slot call (got lost in the code details, but it is something like this).
While with the new function-object-based connection that one will only become automatically inactive by being destroyed if the ~QObject destructor of either sender or receiver is reached. So having a longer lifetime, which can come a bit unexpected to some.

Fixing the modern times, unsure how

Lesson learned: do not blindly port code to the context & function object based connection. Instead beware of the additional traps which there are given that the function object is an independent complex object and not just a member function pointer. I will have to revisit quite some code where I might have missed this trap with the subclass destructor methods :/
As I seemed not the only one hit by this, I filed QTBUG-71432: “API dox of context & function object using QObject::connect should hint about destructor issues” so other people like me might be saved from this from the start.

Curious to learn about best practices for private slots and non-string-based connections. Thus happy to hear about proposals/hints in the comments.

(Update: text now using C++ standard lingo term “function object” instead of “functor”)

Happy 20th anniversary, KDevelop

It’s exactly 20 years ago to the day, that on an equinox as well the first announcement of a KDevelop snapshot, the 0.1 Alpha, was made:

List: kde-announce
Subject: ANNOUNCE: kdevelop-0.1.tar.gz
From: konold () alpha ! tat ! physik ! uni-tuebingen ! de
Date: 1998-09-22 15:50:19

Dear KDE Enthusiast,

the KDE Team is pleased to announce the availability of:

kdevelop-0.1.tar.gz

It can be found at
ftp://ftp.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz

and at our U.S mirror site
ftp://ftp.us.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

it will probably appear firstly at
ftp://ftp.de.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

Here follows the LSM:

Begin3
Title: KDevelop
Version: 0.1 Alpha
Entered-date: 22 Sep 1998
Description: an IDE for X/Qt/KDE
Keywords: IDE, KDE, X11, Qt, development
Author: Sandy Meier, Stefan Heidrich, Stefan Bartel
Maintained-by: Sandy Meier
Primary-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Home-page: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/index.html
Original-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Platform: Linux, needs Qt 1.4 and the kde libs
Copying-policy: GNU Public License
End

20 years of getting feature by feature, sometimes first of its kind, being partially rewritten, getting ported from Qt1 to Qt2 to Qt3 to Qt4 to now Qt5, being made run on non-Linux platforms, seeing hand-overs of maintainers.
At its 20th anniversary KDevelop, now to be called an extensible cross-platform IDE for C, C++, Python, PHP and other languages, continues to provide developers a very reliable and powerful environment to get their code work done. While being inviting to enhance their tool, KDevelop, itself, being a FLOSS software and with no company agenda attached.

I have been a happy user of KDevelop all the years, and currently am giving back to it by doing some development and feature additions.
Be a happy user as well, and then one giving back.
Looking forward to more 20 years, and then some.

KDevelop, ensuring development equity, by day and night. 🙂

From code to related bug report or review in just a hover & click

When working on existing code bases, now and then one reads code that raises some questions and the desire for more context, to understand the purpose or the intention of that code. Context like the commit message, the author, the commit date, or some review discussion of the commit or some bug report or feature request the commit was done for.

In the Beginning There Were Raw Commit Ids…

KDevelop, the extensible cross-platform IDE for C, C++, Python, PHP and other languages, has supported showing line-by-line commit data annotations since many years, starting by showing the commit id and in the tooltip info like author, date and message.
See here a screenshot from the KDevelop 4.1 Dot article (2010):

Annotations border in KDevelop 4.1

Then There Were Year and Author…

Not everyone was capable to deal with raw commit ids, also is it just a reference to the actual metadata, so since some versions of KDevelop the annotation border was changed to show the author name and the commit year instead.
See here a screenshot how it looks by the example of upcoming KDevelop 5.3:

Annotations border in KDevelop 5.3

Soon We Might Get the Message and More

While year and author are already interesting info about a commit, if one is looking at a bunch of lines coming from different commits, it can be unpleasant having always to do some explicit action to get further data, like the commit message, by moving the mouse to trigger the tooltip. And with the recent trend in screen sizes, there often is some vertical space left asking to get its Return-On-Investment 😉 .
More, if in the raw commit message displayed in the tooltip some review discussion or bug report is mentioned, one has to remember the review id or bug id and manually navigate to e.g. the respective web page. Again unpleasant if having to do this multiple times.

End of last year two patches have been started with the goal to improve those things:

The first patch would extend KTextEditor by a new class AbstractAnnotationItemDelegate (modelled after QAbstractItemDelegate), which then gives KDevelop and other potential API users full independent flexibility to decide on which data about annotations to render and how, as developers and users prefer by the time.
The second patch would change KDevelop to make use of that delegate option and change what is rendered for a start: for groups of consecutive lines from the same commit the first would show the commit message summary line, with the age of the commit, a second line would show the author. And it would make use of the KDevelop::ActiveToolTip class (as also used e.g. for code type information tooltips), which allows the user to interact with the content of the tooltip, like copying text or clicking links in the commit message, which would be shown enriched with links where feasible.
The latter though currently misses some support from the KDevelop git plugin, which only delivers the message summary line in the data model (due to making use of git blame --porcelain, possibly needs rewrite using libgit2 instead of parsing git output). So tooltips for now still only show the summary line as before at least with git (did not test the other VCS plugins yet).
See here a screenshot how it looks with the patches applied to master branches of KTextEditor & KDevelop (and some example complete commit message text for demoing what is possible):

Annotations border in a future KDevelop?

Please Help to See If It Is Good

Work on those patches has been picked up again the last week, and they have now reached Merge Candidate state and are ready for final review, targeting KTextEditor of KF 5.52 (to be merged right after tagging 5.51) and KDevelop 5.4.

If you are interested in this feature, please consider to help now by testing those patches and/or reviewing their code (see links to patches above), so the feature will be good once it arrives at users like yourself 🙂