Postings by Friedrich W. H. Kossebau

PSA: Use newer add_test(NAME <n> COMMAND <c>), check CI, esp. with min ECM >=5.38


In your CMake code replace all remaining
add_test(<n> <c>)
add_test(NAME <n> COMMAND <c>)
to make sure test executables are still found once you bump the minimum ECM
version required >= 5.38.
And check your product on KDE CI, where not found test executables are now
properly reported as failure (everything got already up-to-date builds with
that change, if part of groups "Frameworks", "Applications" or "Extragear").
At least one project missed to see some unit-test regression on released
versions due to test executables not found and not run, without being

PSA: how to prepare apps for non-Plasma X-based shells and their app panels


quick heads-up for anyone maintaining applications which also target non-
Plasma shells (X-based, no issue with wayland-based systems):

TL;DR Make sure to have "StartupWMClass=myapp" in the (main) application
desktop file if both WM_CLASS properties of the application window do _not_
match in lowercased version the basename of the application desktop file.
This enables non-Plasma shells map the application windows to application
menu entries (e.g. on the panel)

Your (Qt/KF-based) application should also properly integrate with non-Plasma

PSA: KDE CI: How-To for stable branch switches being picked up

Hi KDE project maintainers,

tl;dr <a href="" title=""></a>
now tells how to make sure KDE CI picks up your new "stable" branch

Some days ago I found that a few products on KDE CI in the "Extragear" section
had not seen builds of their stable branches for some months (I remember at
least Krita & Kexi), despite being under good development.

Reason was that for those products a needed step had not been done after the
"stable" branches were switched to new ones:
manually triggering an initial build with the new branch
(needed with current CI

KMarkdownWebView (kpart) in KDE Review


KMarkdownWebView today entered KDE Review. This repo contains a kpart for
rendered display of Markdown files, using web technologies (webpage with
JavaScript library which creates HTML from the plaintext handed in).

I consider it rather a hack and would favour something done natively in Qt
(e.g. like the Markdown Okular generator in <a href="" title=""></a>
D7382). But for now it serves the use-case of providing a webpage-like
rendered display of markdown documents.

kapidox: supporting also QML (and cmake, Python,, ...)

Hi, Olivier and all,

picking up from the short chat on #plasma today:

so given kapidox is overcoming the old API dox generating scripts with more
proper semantic info...
where the old scripts allowed to use random Mainpage.dox at random places in
the directories to structure the created documentation (e.g.

Separating in-source translations from */messages into own */srcmessages (or similar)


PROBLEM: garbage po and mo files in packages

currently many of the scripts used for creating release tarballs of KDE
software accidentally also add those po files to the tarballs whose
translations are already fed back directly into the sources by scripty (with
data files like appdata, desktop, json, or mimetype.xml). So strings which
will never be loaded from an external mo or qm catalog.

Those po files then also end up in the binary packages as mo files given the
generic handling of po files during builds.

KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?


can anyone shed full light on KDE CI and the usage of ASan?

Currently e.g.

State of Proposal to improving KDE Software Repository Organization?


(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software
Repository Organization" on this mailinglist.
What happened to that plan?

RFC: names of icons related to tables, paths, animation, text & more


the Breeze iconset currently gets further icons, as needed by the different
Calligra apps and plugins.

Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?


what approach is best-practise currently for testing internal parts of libs?
E.g. by symbols (classes) are not exported by default?

In Calligra we have code that uses XYZ_TEST_EXPORT macros for those symbols
which should be only exported in test-enabled builds, e.g.

Qt5/KF5 and extending registration of plugins (formerly done with more desktop files)


in the old times, with metadata about plugins separated in .desktop files, one
could register the same plugin for multiple things without touching the plugin

plugins that were using plugin themselves, like the Okular kpart. When
installing another Okular plugin, e.g. for document type X, one would simply
install another desktop file, saying
--- 8< ---
[Desktop Entry]
--- 8< ---
et voilà, the plugin module would also be registered for X files.

KDiagram libs (KChart, KGantt) in KDE Review


Calligra, Massif-Visualizer, KMyMoney (and perhaps more) make use of KDAB's
nice offer of their KDChart in the GPLv2 licensing variant. But as there are
no real public releases of KDChart, all the projects have copied a dump of
KDChart into their code repositories, updating now and then to newer versions
of KDChart. Which is anything but perfect.

To improve things, after some talk with KDABians it was decided to create a
KDE repo with a KDE-fied fork of KDChart, based on their latest Qt5ied
version. So all FLOSS Qt5-based projects have a single place to-go-to for nice

Review Request 114889: Fix KIO::convertSize(...) returning string with "(I18N_ARGUMENT_MISSING)" inside

Review request for kdelibs.

Repository: kio

Seems the code behind i18n() in kf5 does not like %-placeholders without any arguments passed in the i18n call. And thus inserts the warning.
(Effect can be seen e.g.

Crashes with libQtUiTools.a if linked multiple times into the same process (with Bsymbolic-functions flag)


tl;dr how to avoid crashes if libQtUiTools.a is linked multiple times into a

You use at least one of kross, kjsembed, or plasma in your
application/lib/module and possibly also directly libQtUiTools yourself?

Then shows that chances are that you have seen crashes with this
in the backtrace:
#6 0xb5320313 in
QMetaObject const*, QFormInternal::DomProperty const*) () from XXX

where XXX could be libplasma, libkjsembed, krossmoduleforms or your own

For historic reason

Kdelibs Coding Style vs. preparations for Qt5


what about adapting the Kdelibs Coding Style to the upcoming preparations for
the porting to Qt5? A lot of (KDE) projects follow that kdelibs one, but there
is (at least?) one rule which seems to conflict with the recommendations for
the preparations:

--- 8< ---
Qt Includes

If you add #includes for Qt classes, use both the module and class name. This
allows library code to be used by applications without excessive compiler
include paths.

How to process/update "Mimetype=" entries in .desktop files on install?


(follow-ups please only to kde-devel)

I am looking for a way to deal with the issue that the list of supported
mimetypes for some programs depends on the installed i/o plugins. E,g, Marble
and most Calligra programs have this problem.

Simply hardcoding all possibly supported mimetypes only leaves bad
impressions if a program is started for a file after e.g. a click on the file
in the file manager, but then gives an error message after starting that it
cannot read the file.

It is not only about the i/o plugins created at build time.

Review Request: add note about Oxygen Icons to README.packagers

Review request for KDE Runtime and Release Team.

As discussed in the thread "The misterious case of oxygen-icons" there is an undocumented (de-facto) run-time depedency of kdelibs and kde-runtime on the Oxygen Icons (<a href="" title=""></a>).

Review Request: Remove image/x-wmf and image/x-xfig from image thumbnailer's supported mimetypes

Review request for KDE Runtime.

The declared-as-supported mimetypes of the image thumbnailer are quite broad, assuming a lot of QImageIOPlugin existing and installed. But at least for x-fig and wmf there are no such plugins known, by what I can tell.

Strange ambiguousity with ENABLE_FINAL and Qt::TextInteractionFlags


compiling Okteta with KDE4_ENABLE_FINAL I have hit a strange error which
left me clueless so far.

Deleting "kdepalettes" from kdesdk


Mosfet once put palettes "for both the Gimp and Xpaint that match the KDE
standard color palette" into kdesdk/kdepalettes *. But that was at KDE3
times, so these palettes are outdated, not Oxygen-like.

Moving "scheck" from kdesdk to tags/unmaintained/4/scheck ?


in preparation of the migration of kdesk to git I found that scheck in
kdesdk is currently excluded from the build, because it has been never
completely ported to Qt4/KDE4. And it seems noone has missed it for 4 years,
perhaps accel conflicts & Co.

RFC: Herding your program’s icons, how?


(cc: to kde-bindings for heads-up, follow-ups please only on kde-core-devel)

How to get all icon-ids in your codebase?

Just blogged* about this, but then more something for this ml.

* <a href="" title=""></a>

When seeing for the icon-ids used in Calligra, I have used a simple approach
to get at least most of them, doing a grep for lines with “KIcon(“.

FindKActivities.cmake missing from kdelibs KDE/4.7 ?


kde-workspace trunk is supposed to be compiled against kdelibs KDE/4.7, right?

For me it seems that FindKActivities.cmake is missing then in kdelibs KDE/4.7
or kde-workspace trunk. Because kde-workspace/CMakeLists.txt has the line
find_package(KActivities REQUIRED)

But there is nowhere a FindKActivities.cmake for me:

koder@kleks: ~/Kode/kdegit/KDE$ find kdelibs -name FindKActivities.cmake
koder@kleks: ~/Kode/kdegit/KDE$ find kde-workspace -name FindKActivities.cmake
koder@kleks: ~/Kode/kdegit/KDE$

Is something wrong with my setup?

Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)

Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit:
We can't assume for all, but in many installations the user does.