Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Friedrich W. H. Kossebau]

Am Samstag, 27. Januar 2024, 18:22:35 CET schrieb Friedrich W. H. Kossebau:
> moving slowly, but moving :)
> 
> Would there be any objections to declare the kde(re)review phase to be
> successfully completed now? See below for comments on the checklist.

So 10 days passed and no actual objection, so moving it out of kdereview now. 
Thanks again all for your participation.

Next steps planned:
* make it qt6.only (local patch ready)
* release qt6-only version right after KF 6.0/Gear 24.02.0 
* propose for KDE Gear 24.05 inclusion, to rejoin its old game buddies

Not ignoring Jonathan's comment on the lack of KDE-side app bundles. I think 
this needs more discussion, currently searching for any background how this 
item entered the checklist and by which arguments. Looking at other recent 
kdereviews, accessibility-inspector passed kdereview without that item 
fulfilled, got a flatpak recipe later then by a interested contributor. So 
don't think I am rude here by leaving that open :) I would like to understand 
this item for now as "Can and has been packaged by some major distris", which 
can be checked off. 

Cheers
Friedrich

Re: Proposal for using gitlab for kdereview process

[Friedrich W. H. Kossebau]

Long time ago, but perhaps there are still memories...

Am Dienstag, 4. Juli 2023, 14:32:59 CET schrieb Jonathan Riddell:
> I've gone ahead an updated the Sanity checklist 

Having come across the checklist items

* Passing KDE neon build
* App packages in Flatpak, Snap, AppImages and Windows etc as appropriate

I tried to understand the background & motivation, but only found this "I've 
gone ahead an updated" here and the diff from your edit on 4 July 2023:
https://community.kde.org/index.php?
title=ReleasingSoftware=next=97120

I assume this was the result of some community discussion. If so I failed to 
witness and now fail to find it. Could you help me to get more insight into 
the previous discussion here?

Cheers
Friedrich

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Friedrich W. H. Kossebau]

Am Sonntag, 4. Februar 2024, 19:22:28 CET schrieb Ben Cooksley:
> On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau 
> 
> wrote:
> > Hi,
> > 
> > ((cc:kde-frameworks-devel for heads-up, replies please only to
> > kde-core-deve))
> > 
> > I hit the problem that when working on a repo which would like to use
> > latest
> > KF development state to integrate some new KF API just added in
> > cooperation
> > with that very repo wanting to use it, I cannot do so when someone had
> > added a
> > flatpak job on CI to that repo.
> > 
> > Because with such flatpak jobs it seems they are limiting the available KF
> > version not to the current latest one, as expected for continuous
> > integration,
> > 
> > but some older (anywhere documented?) snapshot:
> > "runtime-version": "6.6-kf6preview",
> 
> Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6
> for what is in the KF6 preview.

Thanks. So documented by implementation :)

> > What can be done here to reestablish the old immediate continuous
> > integration
> > workflow? Where new APIs (also from KF) are instantly available?
> 
> With Flatpak new APIs were never instantly available - there has always
> been a delay as the Flatpak Runtime uses the most recent released version
> of our software.

I guess this was shadowed by feature development of KF having stalled during 
the Qt5/KF5->Qt6/KG6 porting phase as well as Qt6-based flatpaks jobs only 
activated recently.

> > Right now this is a new extra burden which makes working on new features
> > with
> > KF and apps more complicated. Thus less interesting, and one/I would
> > rather
> > duplicate code in apps to get things done.
> > 
> > Blocking latest KF API from usage also means less testing of that before
> > the
> > initial release.
> > 
> > 
> > Besides all the resource costs to create flatpaks on master builds by
> > default
> > every time, when those are usually not used by anyone anyway.
> 
> Those applications that have a hard dependency on features being added to
> Frameworks are not good candidates for making use of our Continuous
> Delivery systems i'm afraid.
> Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and
> macOS) CD jobs are best optimised for those applications that rely on the
> stable Frameworks releases.
> 
> There are ways (in .craft.ini) to make newer Frameworks available, but that
> requires that the system recompiles that Framework each time you trigger a
> build and is therefore not recommended.
> 
> Allowing those systems to use the "latest" artifacts of Frameworks would be
> a non-trivial exercise.

So effectively this means:
* KF - no CI on new API with non-KF repos, only KF-internal CI
* KF - no CD, only released versions

Which makes KF a second class product, with lesser testing :(
And less interesting to contribute to, given it gets worse CI/CD care.

One challenge I face myself here are community maintained products, like KDE 
games. I have had some pleasure in spending some time recently (well, a lot 
actually) on them to make sure they all properly move to Q6/KF6 for Gear 
24.02. And would assess myself success here.

Now others have on their own enabled flatpak builds for all the repos on the 
master branch. Because they "could" and it worked at that moment in time with 
the dependencies.

I have some experimental work for the games collected during the Qt6/KF6 port 
work which still needs some brush up & further tuning. It would require 
changes to KF, libkdegames & then all the games.

The current setup which seems to defaults to "binary builds everywhere" makes 
completing that work now something which seems to go against current standards 
and makes me feel uncomfortable, as if I do something wrong/against the plans, 
as I would have to disable all the flatpak builds. (Besides having to do all 
the care/extra work here for an ecosystem I have no business with).

For me this is an extra hurdle to work in KDE. And things are made worse for 
me given I am not convinced by those platforms (besides AppImage perhaps) 
which now are ruling contribution/development here. 

I understand people fancy easy deployment on their favourite platforms, so do 
I. There was a time when also Debian package info was in some KDE projects 
IIRC.
But please think about those who are not into your respective platform, do 
not force them into (supporting) yours.

> > So, how to solve those problems? Did I miss something?
> > Could flatpak builds on master branches be made on-demand rather?

Cheers
Friedrich

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Friedrich W. H. Kossebau]

Am Montag, 5. Februar 2024, 00:15:00 CET schrieb Julius Künzel:
> > Besides all the resource costs to create flatpaks on master builds by
> > default
> every time, when those are usually not used by anyone anyway.
> 
> It is important to mention that the pipelines on master usually publish to
> the nightly repos on cdn.kde.org/flatpak I guess you were not aware of that
> otherwise I wonder what makes you so confident to know nobody uses it?

That was said with the context of at least some people (including me) doing 
development bursts when there is a time window, pushing multiple times in a 
row on the same evening (to have each set of change CI-tested on its own, like 
for platforms one does not have access to). 
So all the flatpaks in those intermediate builds serve no usage purpose, for 
developers not into the flatpak ecosystem. Only the last might, if any people 
actually have a reson to use nightly builds.

And was said thinking of applications were there might be no-one interested/
motivated to actually run nightly-builds version for the normal life needs, 
where you want to rely on stable things to do your actual things in life those 
are just tools for.
And nightly flatpaks might be rather interesting for people test-driving bug 
fixes occasionally. Or testing translations, though scripty does not trigger 
flatpak builds, does it?
For that some on-demand might be more resource-friendly, instead of defaulting 
to "always build and force all contributors into supporting it", as I 
experience that here.

Cheers
Friedrich

Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Friedrich W. H. Kossebau]

Am Montag, 5. Februar 2024, 10:58:07 CET schrieb Ben Cooksley:
> On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau 
> 
> wrote:
> > So, how to solve those problems? Did I miss something?
> > Could flatpak builds on master branches be made on-demand rather?
> 
> For the record, my rebuild of the 6.6-kf6preview Flatpak Runtime/SDK was
> successful, and the failure that kicked this off in KUserFeedback has now
> been fixed.
> https://invent.kde.org/frameworks/kuserfeedback/-/jobs/1561435

Though what kicked off this very thread was making libkdegames & Co. use 
current KF development version. And seeing that what used to work without 
issues in the last years now fail and being impeded, due to the new flatpak 
support :( Not a flatpak user, so even more sad being side-effected here.

Cheers
Friedrich

Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Friedrich W. H. Kossebau]

Am Montag, 29. Januar 2024, 17:11:57 CET schrieb Volker Krause:
> On Samstag, 27. Januar 2024 18:22:35 CET Friedrich W. H. Kossebau wrote:
> > There are only 2 open checkboxes:
> > 
> > [ ] Passing CI job for Reuse linting
> > 
> > The challenge is that there are a number of old files where the
> > contributors might be hard to contact for an explicit license statement
> > (CMakeLists.txt, AUTHOR, Messages.sh, ...)
> > 
> > Given the same is true for most other KDE games and then some KDE
> > software,
> > and Skladnik is actually some (very) old KDE software, just other than its
> > KDE games siblings for some time had been excluded from release coverage,
> > I
> > would ask us to make a pragmatic exception on the requirement here.
> 
> Yes, and doing that is actually existing practice. This point applies
> primarily to new code, we obviously can't expect this to get magically fixed
> in preexisting code that just moved around or got renamed.

Okay, so stroke out that item from the checklist here.

Cheers
Friedrich

Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

[Friedrich W. H. Kossebau]

Hi,

((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve))

I hit the problem that when working on a repo which would like to use latest 
KF development state to integrate some new KF API just added in cooperation 
with that very repo wanting to use it, I cannot do so when someone had added a 
flatpak job on CI to that repo.

Because with such flatpak jobs it seems they are limiting the available KF 
version not to the current latest one, as expected for continuous integration, 
but some older (anywhere documented?) snapshot:

"runtime-version": "6.6-kf6preview",

What can be done here to reestablish the old immediate continuous integration 
workflow? Where new APIs (also from KF) are instantly available?

Right now this is a new extra burden which makes working on new features with 
KF and apps more complicated. Thus less interesting, and one/I would rather 
duplicate code in apps to get things done.

Blocking latest KF API from usage also means less testing of that before the 
initial release.

Besides all the resource costs to create flatpaks on master builds by default 
every time, when those are usually not used by anyone anyway.

So, how to solve those problems? Did I miss something?
Could flatpak builds on master branches be made on-demand rather?

Cheers
Friedrich

Re: What can we expect from our developers

[Friedrich W. H. Kossebau]

Am Montag, 29. Januar 2024, 10:38:11 CET schrieb Sune Vuorela:
> On 2024-01-29, Jonathan Riddell  wrote:
> > This sort of comment  makes me really sad. The All About the Apps goal,
> > which in principle is still ongoing, was an attempt to get KDE developers
> > to realise it was important not just to write apps but to actually make
> > them available to users, I find it astonishing how we still don't have a
> > culture where making our apps available to users is part of our
> > responsibility.  There's teams in KDE to help with all these formats.
> > Sorry to complain here as the issue is larger than just this one app but
> > it's so sad that nobody within KDE wants to help get users using our
> > software directly.
> 
> I think this is taking it too far. I think the goal is more about not
> getting in the way of people who wants to do this.

What Sune says.

I am sorry to be among those saddening you by not living up to your hopes.

To share you my perspective, for me almost all of these platforms are the same 
challenge as I face with localizations: I do not speak the "language" or live 
the "culture", thus cannot do anything effectively there to properly integrate 
the artifact generated from the sources written.
I have only x leisure time to spend, so I spend it on the things I feel I 
understand & can responsibly create proper results at. And leave it to the 
domain experts to do what is needed or useful in their field. Like 
translators, to localize things for a given locale. Or packagers, to generate 
the binary blobs which work on a given platform. Or sysadmin, to maintain and 
run the environment which only enables us to work on software here in this 
place.

Next, making apps available to users on their platforms also means supporting 
them there. Which again needs proper clue (and access to those platforms) to 
be effective with the given resources one can take from ones capabilities.

I am sharing the result of my developing efforts here as sources, by a very 
grateful license which also emphasizes the sources, not some platform specific 
binary blob. To allow those interested to make use of the product with their 
platforms of choices/realities, adapting and enhancing it where they want to 
their desires. 
Similar to making the software localizable, so those interested can make it 
fit their local culture. Likewise visual styles or other configuration 
options.

Additionally:
I think I understand where you are coming from, that all the work on software 
done here makes the more sense the more users there are. IMHO though reaching 
more users of Free Software should be done in ways and for platforms which are 
not giving more power to monopolists or those which seem set to become some. 
Flatpak, Snap, Windows, macOS... they are all about binaries. There is no 
simple way, part of the concept, to get the sources, patch something to one's 
likes and then regenerate the very same package, just as custom one. Or is 
there?
Which makes the apps basically "free beer apps" for those users. Not the 
business I am here for. But again, packaging is not my domain anyway.

Cheers
Friedrich

Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Friedrich W. H. Kossebau]

Hi,

moving slowly, but moving :)

Would there be any objections to declare the kde(re)review phase to be 
successfully completed now? See below for comments on the checklist.

Am Sonntag, 12. November 2023, 22:57:55 CET schrieb Friedrich W. H. Kossebau:
> Hi,
> 
> REVIEW PHASE START
> 
> please note the start of a kdereview phase for Skladnik. The checklist issue
> has been created here: https://invent.kde.org/games/skladnik/-/issues/2

Thanks to Carl (and perhaps others) who had a look that time and tested and 
gave feedback.

There are only 2 open checkboxes:

[ ] Passing CI job for Reuse linting

The challenge is that there are a number of old files where the contributors 
might be hard to contact for an explicit license statement (CMakeLists.txt, 
AUTHOR, Messages.sh, ...)

Given the same is true for most other KDE games and then some KDE software, 
and Skladnik is actually some (very) old KDE software, just other than its KDE 
games siblings for some time had been excluded from release coverage, I would 
ask us to make a pragmatic exception on the requirement here.
(I have e.g. contributed 29 MRs to licensedigger, that should show I am very 
supportive for REUSE support in general, not trying to get cheap out here :) )

Even more as the CI reuse linting job currently hacks around the fact that 
most po files are not REUSE compliant, by "rm -rf po/ poqm/" before running 
"reuse lint".

As side effect of looking at things this triggered:
* Raising attention with translators on the work waiting in this domain:
  https://mail.kde.org/pipermail/kde-i18n-doc/2024-January/002051.html
* Proposing approaches for KDE CI running REUSE lint with a blacklist:
  https://invent.kde.org/teams/automation/issues/-/issues/5#note_856623

[ ] App packages in Flatpak, Snap, AppImages and Windows etc as appropriate

Not involved with any of those packages/platforms, but I assume that checkbox 
is rather some kind of "nice to have", not blocking the process actually?

Externally already packaged by Arch, Alpine Linux, Gentoo, Manjaro, Parabola, 
by list on https://repology.org/project/skladnik/versions

> RELEASE PLANNED FOR NOV 20th
> 
> While the phase is running, in parallel I plan to do a first (well, after 15
> years of none, see below) release Monday, November 20th
> (string freeze in master since today).

Release since happened, as 0.5.0, and this year some translations update 
0,5,1.

> ABOUT
> 
> First commit in Aug. 30th 1998, first released by the name KSokoban with KDE
> 1.1, to be part of KDE for 10 years up to the last KDE 3 release. Then
> stalled over Qt4/KDELibs4 porting, though the last 15 years bit by bit
> ported by different people to since last year even build and run against
> future Qt6/ KF6...
> time to get it finally back to releases rolling and rejoin the other
> historic KDE games, as it still can entertain.
> 
> Skladnik is an implementation of the Japanese warehouse keeper game
> “sokoban”, and the new name to replace (trademark-challenging) KSokoban. It
> is a small logic game to play by a single person (+ over-the-shoulder
> watchers) in breaks for a few (or more) minutes per level.
> 
> Learn details at
> * https://apps.kde.org/skladnik
> * https://docs.kde.org/trunk5/en/skladnik/skladnik/introduction.html
> * https://en.wikipedia.org/wiki/Sokoban
> 
> For a related impressive website, including steo-by-step solutions, see
> https://ksokoban.online/

Cheers
Friedrich

KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino

[Friedrich W. H. Kossebau]

Hi,

REVIEW PHASE START

please note the start of a kdereview phase for Skladnik. The checklist issue 
has been created here: https://invent.kde.org/games/skladnik/-/issues/2


RELEASE PLANNED FOR NOV 20th

While the phase is running, in parallel I plan to do a first (well, after 15 
years of none, see below) release Monday, November 20th
(string freeze in master since today).


OPEN QUESTIONS

When it comes to reuse compat, there are graphic resources added decades ago, 
with no direct license statement in the files, only copyright notes (in the 
Povray (sic) files :) ).
Would the file COPYING (GPLv2) in the toplevel dir then default the license 
for these files?
See https://phabricator.kde.org/source/svn/browse/trunk/kdegames/;10132
In short, what to do here for reuse checks? Ignore, because old repo and thus 
legacy rights? Can files be skipped in the check?


ABOUT

First commit in Aug. 30th 1998, first released by the name KSokoban with KDE 
1.1, to be part of KDE for 10 years up to the last KDE 3 release. Then stalled 
over Qt4/KDELibs4 porting, though the last 15 years bit by bit ported by 
different people to since last year even build and run against future Qt6/
KF6...
time to get it finally back to releases rolling and rejoin the other historic 
KDE games, as it still can entertain.

Skladnik is an implementation of the Japanese warehouse keeper game “sokoban”, 
and the new name to replace (trademark-challenging) KSokoban. It is a small 
logic game to play by a single person (+ over-the-shoulder watchers) in breaks 
for a few (or more) minutes per level.

Learn details at
* https://apps.kde.org/skladnik
* https://docs.kde.org/trunk5/en/skladnik/skladnik/introduction.html
* https://en.wikipedia.org/wiki/Sokoban

For a related impressive website, including steo-by-step solutions, see 
https://ksokoban.online/

Cheers
Friedrich

PSA: Qt6-based KDE software builds: drop EXCLUDE_DEPRECATED_BEFORE_AND_AT override now

[Friedrich W. H. Kossebau]

Hi,

a quick heads-up:

if you already package or otherwise do any Qt6-based KDE software builds and 
have in the set of manual flags passed to cmake any
"-DEXCLUDE_DEPRECATED_BEFORE_AND_AT=x.y.z"
override, please remove that override completely now.

All KDE sources should now set the proper default value themselves (which also 
was "5.99.0" only for Frameworks modules, other libraries would have needed 
other values matching their respective versioning scheme, things worked only 
by chance).

EXCLUDE_DEPRECATED_BEFORE_AND_AT is a flag which controls what API 
implementation parts of a library should be excluded when building it.
So indeed is not about excluding usage of deprecated API from other libraries.
BUILD_DEPRECATED_AFTER_AND_AT might have been a better name, perhaps something 
to switch to :)

See also
https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/248
https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/250
https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/106

If you know any place which still holds that flag e.g. in instructions, please 
also update or report.

Cheers
Friedrich

Re: KSvg in kdereview

[Friedrich W. H. Kossebau]

Am Mittwoch, 21. Juni 2023, 12:23:55 CEST schrieb Ben Cooksley:
> On Wed, Jun 21, 2023 at 10:12 PM Harald Sitter  wrote:
> > LGTM now +2
> > 
> > On Wed, Jun 21, 2023 at 10:04 AM Marco Martin  wrote:
> > > I fixed CI, passes now
> 
> Thanks for correcting that.
> 
> As Friedrich raised the initial concerns it would be nice to have him
> confirm that the code quality issues he found have all been corrected.

Fear I had just superficially looked at things, given I am currently not a 
stakeholder in this library, no API consumer or contributor. The cmake issues 
I saw at the time I had fixed directly, anything C++ etc. I had not really 
looked at, just saw the TODOs and skipped ;) So cannot compare and would have 
no time reserved here to take a closer look now, others have I assume :)
The other thing that stood out was the outdated docs, but that seems to have 
been fixed/improved on a quick glance +1

The other comment was about the name, but naming, the joy :) ... and people 
using it/working on it seem fine with the current one, so...

Cheers
Friedrich

Re: KSvg in kdereview

[Friedrich W. H. Kossebau]

Hi,

Am Donnerstag, 20. April 2023, 10:25:34 CEST schrieb Marco Martin:
> Hi all,
> A part of plasma-framewrok, which is the one to do SVG-based themes,
> has now been splitted in a standalone library which is intended to be
> a new framework in KF6 (all usages of the plasma-framework version
> will be ported once this officially lands, and then those classes will
> be removed)
> The repo for now lives in
> https://invent.kde.org/libraries/plasmasvg
> 
> In the end it will be renamed in ksvg
> 
> Comments? reviews?

Came across the library yesterday by chance.

Did some small fixes (library e.g. was installed with literal ".SOVERSION" as 
suffix...), but the more I did and more I saw... IMHO this should not have yet 
been passed to kdereview, being in alpha state for my taste. 
E.g. "TODO KF6" ideally would not be handled during the review phase, but 
before.
And the README and other docs not (yet) mentioning what the scope & purpose of 
the library, but being dead copies from Plasma Framwworks also makes things 
harder to assess.

Builds on CI all failing ever since and before also looks a bit unattractive. 
Currently still with FreeBSD.

For the name, "KSvg" sounds very unspecifc to me, ideally the name would 
reflect the purpose & scope of the library some more (but then that is not 
defined somewhere also, so... ;) ). Something with SVG, but what exactly? 
Perhaps "KSvgTheme" (proposed by Sune on irc) or similar might make it more 
clear?
Also using "KSvg" as namespace results in class names like KSvg::;Svg,  
KSvg::SvgItem, etc. which looks a bit strange to my eyes on consumer side due 
to the duplication. In my perfect world the naming would see some overhaul 
given this is a new library. Yes, some one-time porting pain, but sanity 
afterwards, for a certain type of sustainability ;)

My 2 cents as someone who just came by, but with no current own needs in that 
library.

Cheers
Friedrich

Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

[Friedrich W. H. Kossebau]

Am Freitag, 10. März 2023, 05:24:40 CET schrieb Kevin Kofler:
> Heiko Becker wrote:
> > while looking at a MR for libkcddb (part of Gear) I wondered if the
> > transition from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6
> > prefix in target names and CMake config files for libraries that aren't
> > acutally part of Frameworks.
> 
> Huh? This kind of transition is exactly where the prefix is most valuable,
> because it ensures that you get a compatible version of the library, i.e.,
> that you do not accidentally get, e.g., a version of KF5Cddb when you are
> looking for KF6Cddb.

That logic though applied consequently, we should have named all libraries 
Qt5Foo and now Qt6Foo, so one really can be sure that the libs are compatible 
with the respective Qt version. But we did not do that for a reason.

Because the prefix most importantly hints to a product group. And that one 
comes with certain properties, e.g. versioning or maintainers. 
--- 8< ---
find_package(KF5 REQUIRED COMPONENTS
I18n
Cddb
AkonadiContact
KMahjongglib
)
--- 8< ---
works (and I have seen variants of that in real life), but it is just wrong, 
even more when using version numbers.

A number in a library name usually is used to denote the major version of the 
library itself. In case of libraries extending/using the Qt toolkit, like our 
KDE products, many products share the API cycle of Qt, and thus also see to 
align the version numbers, at least the major one.

But that is just by chance. A number of libraries for reasons have shorter API 
cycles. So cannot keep their major version number in sync with the supported 
Qt version. So the library number as clue for the used Qt version is not 
possible, instead other means might be needed. Especially in case the same 
library version can be built with multiple major Qt versions and co-installed. 
In that case postfixes with "qtX" usually have been used (not sure I fancy 
that postfix, just describing a fact).

So, "KFx" as generic prefix to express the aspect "library from KDE using Qt 
x" will not work across the board sadly. Rather risks people to have wrong 
expectations about full versions and other product properties for a given 
library.

Instead "KFx" should stay a product identifier for KF modules, and any 
accidental misuses healed when possible. Other product libraries names would 
still try to match the Qt version of course where feasible, but by other 
patterns.

Cheers
Friedrich

Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

[Friedrich W. H. Kossebau]

Am Donnerstag, 9. März 2023, 18:03:17 CET schrieb Ingo Klöcker:
> On Donnerstag, 9. März 2023 16:58:40 CET Heiko Becker wrote:
> > while looking at a MR for libkcddb (part of Gear) I wondered if the
> > transition
> > from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in
> > target
> > names and CMake config files for libraries that aren't acutally part of
> > Frameworks.
> 
> +1

+1 

> > Changing that obviously involves some (temporary) compatibility concerns,
> > but that doesn't play any role with the move to Qt6/KF6. So I suggest to
> > use the chance and get rid of said prefix with the upcoming porting.
> > 
> > One example where this was done already some time ago is libkgapi:
> > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e248
> > 88 b7f924a49
> 
> This is a particular bad example because it changes the name of the Qt5
> version breaking all existing Qt5-based users instead of just fixing the
> name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it
> doesn't hurt external users. But it has cost me many hours compiling
> libraries from source where I previously could always use the distribution
> packages). Please don't follow this annoying example.

+1 (as in, we should stick to what is proposed, use the 5->6 breakage to also 
funnel other nice-to-finally-do breakages into it)

Did some related MRs now for libkmahjongg, for some other example:
https://invent.kde.org/games/libkmahjongg/-/merge_requests/9
Adaption consumer side:
https://invent.kde.org/games/kmahjongg/-/merge_requests/21

Cheers
Friedrich

Re: RFC: KF (& other lib) consumers: want KFOO_VERSION macro definitions automagically available?

[Friedrich W. H. Kossebau]

(cc:kde-core-devel only for heads-up, any reply please only to kde-devel)

Am Dienstag, 28. Februar 2023, 15:20:11 CET schrieb Friedrich W. H. Kossebau:
> TL;DR  Would you fancy not having to always explicitly include a version
> header of a KFoo module to have the KFOO_VERSION variable available in your
> code? So is it worth it to add support for that on the KF side?
> (KF6-only, to keep your KF5 experience consistent)
> 
> See for some discussion the description of
> https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/310
> 
> Please voice your opinion on the use-case (not the implementation) either in
> that MR as comment or as reply in the ML.
> 
> To adapt to the new use-case, two new feature variants of related ECM macros
> are currently up for consideration:
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/337
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/341
> 
> Again curious which variant people might prefer in case they also work on
> public libraries, e.g. if there are other use-cases for the generic approach
> in 337 with the INCLUDE_FILES argument. Personally tend for 341 right now.

Thank you who took the time to give feedback so far :)

Seems having the *_VERSION macros implicitly available would be favoured by at 
least some others than me, so I have continued work on the matter and locally 
test-applied this to all KF6 modules and some other libraries.

Which as side-effect resulted already in some additions of missing version 
header installations as well as include dir layout clean-ups with KF6 :)

Now some bits for those interested on the implementation side:

The current state of the proposed solution, using ECM MR 341 
("ECMGenerateExportHeader: add USE_VERSION_HEADER arg (& related tune args)"), 
requires for each library in ideal situations only this additional flag (by 
example of KCoreAddons):

--- 8< ---
 ecm_generate_export_header(KF6CoreAddons
+USE_VERSION_HEADER
 )
--- 8< ---

And as result includes like "#include " will make all version 
macros like "KCOREADDONS_VERSION" from kcoreaddons_version.h available without 
further work.

For multi-library KF modules, where the module version header will then differ 
in the base name from (most) library base names, an additional argument is 
needed (by example of KIO's KIOCore):
--- 8< ---
 ecm_generate_export_header(KF6KIOCore
+USE_VERSION_HEADER
+VERSION_BASE_NAME KIO
 )
--- 8< ---

Additionally sometimes some adaption is needed in the internal buildsystem for 
the version header to be seen during the internal build.

All in all this seems acceptable to me as overhead.
(though someone someday should deduplicate all the cmake code in all the KF 
modules, so many patterns that shout "make me a central macro/function"...)

For non-KF libraries, which IMHO ideally also should support this developer 
experience in the Qt6/KF6-based world, and which currently see to support both 
Qt5 & Qt6 builds from the same branch and also cannot yet rely on latest ECM, 
possible code is like this (by example of KDEGames):
--- 8< ---
+if (QT_MAJOR_VERSION STREQUAL "5")
+set(_generate_export_header_version_args)
+else()
+# For Qt6/KF6 world transitively include the version header 
+if(ECM_VERSION VERSION_LESS "5.105")
+set(include_version_header_code "#include \n")
+set(_generate_export_header_version_args CUSTOM_CONTENT_FROM_VARIABLE 
include_version_header_code)
+else()
+set(_generate_export_header_version_args USE_VERSION_HEADER)
+endif()
+endif()
 ecm_generate_export_header(KF5KDEGames
+${_generate_export_header_version_args}
 )
--- 8< ---

This is the path I will continue in related MR in the next days/weeks,

So if you want to participate please comment on ECM MR 341 & KCoreAddons MR 
310.

(note to self: next time again use a phabricator task as central place for 
tracking feature development discussion)

Cheers
Friedrich

PS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde- 
devel or, better, on the MRs :)

Re: RFC: an improved ki18n_install

[Friedrich W. H. Kossebau]

Am Dienstag, 7. März 2023, 02:51:06 CET schrieb Aleix Pol:
> Having ninja/make do this dependency generation can end up being more
> work than worth it because then we need to have a static list

Such static list could be generated by scripty when it updates the po/ folder 
and stored there, no? Which then could be sourced by the ki18n_install cmake 
code in some way.

I'd urge to use the existing tools like make/ninja as much as possible instead 
of reimplementing their logic partially and maintaining a non-integrated sub 
buildsystem, with all the shortcomings and fails.

Thanks for working on this in any case, the current state is far from ideal.

Cheers
Friedrich

RFC: KF (& other lib) consumers: want KFOO_VERSION macro definitions automagically available?

[Friedrich W. H. Kossebau]

Hi,

(cc:kde-core-devel only for heads-up, any reply please only to kde-devel)

TL;DR  Would you fancy not having to always explicitly include a version 
header of a KFoo module to have the KFOO_VERSION variable available in your 
code? So is it worth it to add support for that on the KF side?
(KF6-only, to keep your KF5 experience consistent)

See for some discussion the description of
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/310

Please voice your opinion on the use-case (not the implementation) either in 
that MR as comment or as reply in the ML.

To adapt to the new use-case, two new feature variants of related ECM macros 
are currently up for consideration:
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/337
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/341

Again curious which variant people might prefer in case they also work on 
public libraries, e.g. if there are other use-cases for the generic approach 
in 337 with the INCLUDE_FILES argument. Personally tend for 341 right now.


Personal motivation:

One of the things that annoyed me a bit with using KDE Frameworks over the 
last years was this:
if one wanted to query what API is available (by using the *_VERSION value as 
reference), one always had to explicitly include the respective version 
header. And then also remember to again remove the include once no longer 
needed.
For one this cluttered the list of includes a bit and was extra work. But more 
annoying has been to me that one often forgot the version header include, even 
more when copy & pasting some version-based code around, and only finding out 
the hard way when compiling or digesting any editor parsing error 
highlighting.
This developer experience differs from most of the other libraries one uses 
(most prominently Qt), so the need for the explicit include first has to be 
remembered, and in comparison also comes across with bigger developer work 
costs.

Grepping through the list of headers of non-KF libraries on my system, it 
seems:
* half of them do not even have separate version headers but instead have the
  version (also visibility/export) macros defined in generic global headers
  which are either the central header to include by consumers or indirectly
  included by all other headers
* the other have separate version headers, but roughly half of those again
  include the version header in some generic global headers, which again
  either directly or indirectly included by consumers

So in KF modules without changing the current structure of separate headers, 
but still having the version macros available implicitly when including a 
public class header, a solution, as proposed in the MRs, is to modify the 
export headers to transitively include the related version header. It seems 
like a least invasive change to achieve the desired.

And given KF API is used together with lots of Qt API, having a more similar 
developer experience here makes having that also more appealing.

Still, it needs a tad of adaption on the KF side and adds a tad of complexity, 
so it would be good to know if a good portion of consumers think the new 
behaviour is welcome, thus worth it.

As a reference point, right now on master branches of KDE projects there are 
up to 699 includes that would no longer be needed (should be only a few wrong 
hits):
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C_version%5C.h%5C%3E&_casesensitive=1

And there are many includes which have come and gone before.

What do you think?

Cheers
Friedrich

PS: Yes, in some case one will still have to include the version header as 
before, like when deciding which single class header to include and no other 
header was yet included that provided the macro. But that is the case with any 
variant.

PPS: Again, cc:kde-core-devel only for heads-up, any reply please only to kde-
devel :)

Re: Cleaning up cdash.org integration, what to do, or any hidden usage still?

[Friedrich W. H. Kossebau]

Hi Alex,

thanks for the quick reply. :)

Am Sonntag, 4. September 2022, 23:42:36 CEST schrieb Alexander Neundorf:
> On Freitag, 2. September 2022 12:20:50 CEST Friedrich W. H. Kossebau wrote:
> > we stumbled over some CTestConfig.cmake files in some of the KDE git
> > repositories. Which seem to originate from a time where people worked on
> > integration with cdash.org, that is a decade ago :)
> > 
> > It seems though this integration no longer is maintained:
> > 
> > * no KDE projects seem listed on cdash.org anymore:
> >   https://my.cdash.org/viewProjects.php?allprojects=1
> > 
> > * the KDEUtilsNightly.cmake seems to have found no counterpart in the ECM
> > 
> >   world. The only reference seen is the check for the presence of a
> >   CTestConfig.cmake file and the inclusion of the CTest module in that
> >   case.
> > 
> > With KDE's deployment of first Jenkins and now Gitlab CI around the
> > purpose
> > of the integration with cdash.org also seems no longer needed, by what I
> > understand?
> > 
> > So can we state that this cdash integration is officially no longer done,
> > and thus we can clean up any traces of it, for clean and non-confusing
> > data
> > & code?
> 
> I think so.

Okay. So with the former lead on these efforts having confirmed I consider 
this then officially a thing of the history, within KDE :)

> > Are there any other things left to do to clean up this, besides the
> > following?
> > 
> > T1) Remove any remaining CTestConfig.cmake files from KDE repos.

All such files should have been removed now or at least be target of a MR, by 
a research via lxr.kde.org and invent.kde.org.

> > T2) Remove support in KDECMakeSettings for deal with CTestConfig.cmake
> > files:
> > https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/295

Discussion on-going, but should be resolved soon.

> > T3) Add a note on the respective Wiki page about being outdated:
> > https://techbase.kde.org/Development/CMake/DashboardBuilds

Anyone can tell what the official way to tag a page as outdated/historic is on 
techbase?

> sounds good, but I didn't check.

So if anyone else knows about some related left-over, please point to it (or 
action up-on :) ).

Cheers
Friedrich

Cleaning up cdash.org integration, what to do, or any hidden usage still?

[Friedrich W. H. Kossebau]

Hi,

(cc: kde-devel for heads-up, please reply only to kde-core-devel).

we stumbled over some CTestConfig.cmake files in some of the KDE git 
repositories. Which seem to originate from a time where people worked on 
integration with cdash.org, that is a decade ago :)

It seems though this integration no longer is maintained:
* no KDE projects seem listed on cdash.org anymore:
  https://my.cdash.org/viewProjects.php?allprojects=1
* the KDEUtilsNightly.cmake seems to have found no counterpart in the ECM
  world. The only reference seen is the check for the presence of a
  CTestConfig.cmake file and the inclusion of the CTest module in that case.

With KDE's deployment of first Jenkins and now Gitlab CI around the purpose of 
the integration with cdash.org also seems no longer needed, by what I 
understand?

So can we state that this cdash integration is officially no longer done, and 
thus we can clean up any traces of it, for clean and non-confusing data & 
code?


Are there any other things left to do to clean up this, besides the following?

T1) Remove any remaining CTestConfig.cmake files from KDE repos.

T2) Remove support in KDECMakeSettings for deal with CTestConfig.cmake files:
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/295

T3) Add a note on the respective Wiki page about being outdated:
https://techbase.kde.org/Development/CMake/DashboardBuilds

Cheers
Friedrich

Reminder: When requiring ECM 5.85 or newer, be aware of KDE_COMPILERSETTINGS_LEVEL concept

[Friedrich W. H. Kossebau]

Hi,

((kde-core-devel as CC:, please reply only to kde-devel)

Time for a quick reminder after half a year, given this is not daily business 
but people might more & more require newer ECM and run into this.
Quoting the important bit below, for the full initial email, please see
https://marc.info/?l=kde-devel=162893561025502=2


TL;DR
Starting with ECM 5.85 KDECompilerSettings will provide some stricter 
settings, which you can control on the toplevel by KDE_COMPILERSETTINGS_LEVEL 
and then again per settings category, for a stable set of settings matching 
your project requirements across ECM versions, not affected by the minimal 
required ECM version.
Make sure to include KDECompilerSettings right after find_package(ECM), before 
any other find_package() calls (best done in any case due to a current flaw).
While your minimum required ECM version is < 5.85, no other change is needed.
If you start to require newer minimum ECM >= 5.85, and do not want any newer 
stricter settings take effect for now, call
set(KDE_COMPILERSETTINGS_LEVEL 5.84.0)
include(KDECompilerSettings NO_POLICY_SCOPE)
Port any usage of KDEFrameworkCompilerSettings outside of KDE Frameworks 
modules to that once you can afford to require ECM >= 5.85.
For more, see docs on
https://api.kde.org/ecm/kde-module/KDECompilerSettings.html

Cheers
Friedrich

Making Grantlee a KF5 Framework, take 2

[Friedrich W. H. Kossebau]

Hi (especially those who would be in contact with Stephen, see end).

OLD PLANS REVISITED

The old plan was to turn the two libraries part of Grantlee (main one being 
for text templating, second one for markup generation, see grantlee.org) into 
KF modules in time for KF6.

With KF6 still some decent time away, and Grantlee upstream with stalled 
development (even seeing forks already), it might be better to execute the 
KFying plans already now. And by that also shift some workload from the Qt5/
Qt6 port time away to now.


WORKING KF5 VARIANT ALREADY PREPARED, INCLUDING CONSUMER PATCHES

While so far we have yet to manage to reach Stephen to see him agree on and 
bless the new plan, work has been done to prepare a KF5 variant of Grantlee 
meanwhile, tracked in this task:
https://phabricator.kde.org/T14887

The current result is:
* a working KF5 module variant of Grantlee (mainly missing code reformat and 
SPDX headers, but already prepared separately)
* working patches for all known users of Grantlee in KDE (as well as Kraft as 
another known user in the outer spheres).
See the linked task above for the KFGrantlee repo and the patches to the 
consumers.

So basically prepared, just missing out on complete licenses and name 
transfer. Modulo further review by KF developers of course :)


KF 5.88 WOULD BE A WELCOME TARGET

In a perfect world we could add the text templating library of Grantlee as a 
KF module for KF 5.88 begin of November (the markup generation would be solved 
differently, as fork for now in the only left consumer kjots, see task for 
details).
This would allow to switch the majority of Grantlee consumers, 10, which are 
part of KDE Gear, without #if#else to KF Grantlee for KDE Gear 21.12. While 
seeing to have the other 3 either have a patch release before with build 
support added or provide distributions with patches for that. So the 
distributions can switch all the packages to use KFGrantlee at the same time, 
no need to juggle two variants of the same library at the same time.

Now KF 5.88 tagging is just less than 5 weeks away, so this might appear a bit 
rushed. But it is also a small window of opportunity, with developers around 
with attention to the matter, and where things could be aligned. And after all 
the codebase is pretty mature after all the years, and the recent 
modernization patches should not have had much of a negative impact. So giving 
it a try.

Otherwise I would propose KF 5.89 in December as a target and ask for allowing 
KDE Gear 21.12 to dependent on that, even if released just a few days later by 
current schedules.


CONTACT TO STEPHEN  NEEDED, IDEALLY NOW

As Stephen already pointed out as reason in the original proposal, other 
interesting things in life have taken over his resources and focus. Yet we 
need his input for two things, so for that we need someone who could interest 
him to spend some 10 more minutes on his former, so important to us, work :) :

a) Review and merge this prepared commit in his authorship which adds missing 
license headers to some files:
https://github.com/steveire/grantlee/pull/75
b) State by an email to kde-core-devel@kde.org or kde-frameworks-de...@kde.org 
he is fine with us taking over the name Grantlee for the new KF variant of the 
library, as official successor of his work.

In case please consider to share personal details by PM with me, let's keep 
private things private :) Otherwise any help very welcome to resolve these two 
blockers.

Cheers
Friedrich

ECM 5.85: introducing KDE_COMPILERSETTINGS_LEVEL concept

[Friedrich W. H. Kossebau]

Hi,

((kde-core-devel as CC:, please reply only to kde-devel)

TL;DR
Starting with ECM 5.85 KDECompilerSettings will provide some stricter 
settings, which you can control on the toplevel by KDE_COMPILERSETTINGS_LEVEL 
and then again per settings category, for a stable set of settings matching 
your project requirements across ECM versions, not affected by the minimal 
required ECM version.
Make sure to include KDECompilerSettings right after find_package(ECM), before 
any other find_package() calls (best done in any case due to a current flaw).
While your minimum required ECM version is < 5.85, no other change is needed.
Port any usage of KDEFrameworkCompilerSettings outside of KDE Frameworks 
modules to that once you can afford to require ECM >= 5.85.
For more, see docs on
https://api.kde.org/ecm/kde-module/KDECompilerSettings.html


This is a heads-up for a new mechanism introduced with ECM 5.85 to control the 
set of compiler settings for your project when using ECM's KDECompilerSettings 
(and your way out of repurposing KDEFrameworkCompilerSettings to easily gain a 
more strict set of settings).

It enables KDECompilerSettings to offer new variants of settings (which 
usually mean more strictness and enforcing usage of more modern standards), 
while allowing consumers to pin-point a certain settings variant as well as 
overwriting individual settings, without being coupled to the minimum required 
ECM version.


Basic usage:

Set KDE_COMPILERSETTINGS_LEVEL to the version whose set of settings you desire 
right before including KDECompilerSettings, 

find_package(ECM 5.85.0 NO_MODULE)
set(CMAKE_MODULE_PATH /* other paths as needed */ ${ECM_MODULE_PATH})
set(KDE_COMPILERSETTINGS_LEVEL 5.85.0)  # <- new, to set before including
include(KDECompilerSettings NO_POLICY_SCOPE)

WARNING:
Also make sure to call include(KDECompilerSettings) right after 
find_package(ECM), before any other find_package() calls. There is currently a 
design flaw in ECM code which relies on the minimum required version as passed 
to the find_package(ECM) call, and any further calls of find_package(ECM) like 
e.g. can happen in the chain behind find_package(KF5) can overwrite this with 
the version used in those calls (someone needed to fix this, you, dear 
reader?).
As work-around for now everyone has to include the ECM modules right before 
invoking anything else.


KDE_COMPILERSETTINGS_LEVEL cannot be higher than min required ECM:

As at the time of writing older ECM versions it cannot be foreseen what future 
ECM versions might have as new settings for their respective 
KDE_COMPILERSETTINGS_LEVEL version, the max version that can be used for 
KDE_COMPILERSETTINGS_LEVEL is the one of the minimum required ECM version. 
That ensures that for a given KDE_COMPILERSETTINGS_LEVEL version it is a known 
set of settings you can expect to be set.


Setting KDE_COMPILERSETTINGS_LEVEL to not get new settings right now:

KDE_COMPILERSETTINGS_LEVEL <= 5.84.0 will give you the settings as used to 
before so far.
KDE_COMPILERSETTINGS_LEVEL == 5.85.0 will bring lots of new strict settings, 
matching those of previous KDEFrameworkCompilerSettings and then some.
Future KDE_COMPILERSETTINGS_LEVEL can then contain any more settings which 
seem sensible as default, whatever ECM community decides here.


KDE_COMPILERSETTINGS_LEVEL defaulting to minimum required ECM version:

For convenience for those who are fine to also update their code to match 
latest settings when bumping the minimum required ECM version to gain access 
to newer ECM features, KDE_COMPILERSETTINGS_LEVEL defaults to the minimum 
required ECM version. So those can spare that extra line. But be prepared for 
potential code update work when bumping the required version any time :)
So recommended is to explicitly set KDE_COMPILERSETTINGS_LEVEL once requiring 
at least ECM >= 5.85.0, to save one from potential build breakages due to more 
strict settings when just wanting some other new ECM feature and bumping the 
required version without further thought.


Overwriting the settings set from KDE_COMPILERSETTINGS_LEVEL:

As there is no one-set-of-settings-fits-all, each settings category also has 
additional controls to overwrite the default defined by the level. Those 
controls are usually further variables which have to be set before including 
KDECompilerSettings, here a few examples:
* KDE_SKIP_PEDANTIC_WARNINGS_SETTINGS
* KDE_SKIP_MISSING_INCLUDE_DIRS_WARNINGS_SETTINGS
* KDE_QT_MODERNCODE_DEFINITIONS_LEVEL

For a detailed listing and further info please consult the documentation at
https://api.kde.org/ecm/kde-module/KDECompilerSettings.html


If you have further questions, please do not hesitate to ask here on the kde-
devel ML (please reply only there, not kde-core-devel).

Cheers
Friedrich

PS: Please someone volunteer to fix the ECM_GLOBAL_FIND_VERSION design flaw. 
Might be easy to fix, not yet thought more about myself, simply done too much 
ECM/CMake 

Re: KHealthCertificate in kdereview

[Friedrich W. H. Kossebau]

Am Sonntag, 11. Juli 2021, 17:53:31 CEST schrieb Volker Krause:
> done, with the exception of switching away from
> KDEFrameworksCompilerSettings, that can only be done for 5.85, for earlier
> versions that would require copying a bunch of settings it seems.

Well, you still have some settings duplicated as of now, so does that really 
make a difference? ;)

It is given a bad example, and cmake code tends to be copied around as magic 
lines, so please consider giving a good example when you can. 

Cheers
Friedrich

Re: KHealthCertificate in kdereview

[Friedrich W. H. Kossebau]

Am Sonntag, 11. Juli 2021, 16:07:37 CEST schrieb Friedrich W. H. Kossebau:
> * no need to set CMAKE_AUTOMOC & CMAKE_AUTORCC, done by KDECompilerSettings
> for required ECM

KDECMakeSettings rather :)

Cheers
Friedrich

Re: KHealthCertificate in kdereview

[Friedrich W. H. Kossebau]

Quick feedback after looking at the cmake code:

* do not explicitly list ECM_KDE_MODULE_DIR, it is part of ECM_MODULE_PATH
* do not use KDEFrameworkCompilerSettings for non-KF projects, only 
KDECompilerSettings
* no need to set CMAKE_AUTOMOC & CMAKE_AUTORCC, done by KDECompilerSettings 
for required ECM
* set(CMAKE_CXX_STANDARD 17) before including KDECompilerSettings
* call feature_summary as last thing, for consistency and some logic in 
execution
* avoid REQUIRED in find_package() calls, only use in set_package_properties,
  so cmake will not cancel in middle of run, but get to listing found/notfound 
summary (Qt, ECM, KF are harder to do here due to macros expected later, and 
usually present, so fine there)
* include the 3 KDE cmake setting modules as first and in this order:
  include(KDEInstallDirs)
  include(KDECMakeSettings)
  include(KDECompilerSettings NO_POLICY_SCOPE)
* I recommend using set_target_properties() right next to add_${target},
  easier to find on need and product definition in one place makes more sense

Otherwise looks clean and modern to me :)

Cheers
Friedrich

Re: PSA: Please do not use KDEFrameworkCompilerSettings for non-KF projects

[Friedrich W. H. Kossebau]

Am Mittwoch, 20. Januar 2021, 17:10:03 CET schrieb Friedrich W. H. Kossebau:
> Am Mittwoch, 20. Januar 2021, 16:51:54 CET schrieb Volker Krause:
> > How about we try to come up with an alternative solution for what looks
> > like a wide-spread demand for centrally maintained high-quality compiler
> > settings instead then? That might also make any kind of enforcement to
> > not use this outside of Frameworks unnecessary :)
> 
> I have some idea how to extend the normal KDECompilerSettings to provide the
> option for this, by checking ECM_GLOBAL_FIND_VERSION to activate the
> addition of stricter settings, while having some cmake vars which set
> before including KDECompilerSettings allow to overrule that (compare also
> how KDECMakeSettings has variable flags to control what scope of settings
> is activated, like KDE_SKIP_RPATH_SETTINGS).
> 
> So people not bumping min ECM required in their projects see old behaviour
> (like released tarballs), anyone bumping to a certain higher version
> (usually where things got added) opts in, those variables set before allow
> to opt out still for certain things if not wanted.
> 
> Planning to turn a first draft into a MR tonight, for further discussion.

Update: hit some mental walls how to do this nicely without putting new stones 
into the way to KF6. Still on my list, but need to find time to sort my 
thoughts to properly present them for a sane discussion start, so might only 
happen in the coming weeks. Anyone else of course invited to share their ideas 
meanwhile.

Cheers
Friedrich

Re: PSA: Please do not use KDEFrameworkCompilerSettings for non-KF projects

[Friedrich W. H. Kossebau]

Am Mittwoch, 20. Januar 2021, 16:51:54 CET schrieb Volker Krause:
> How about we try to come up with an alternative solution for what looks like
> a wide-spread demand for centrally maintained high-quality compiler
> settings instead then? That might also make any kind of enforcement to not
> use this outside of Frameworks unnecessary :)

I have some idea how to extend the normal KDECompilerSettings to provide the 
option for this, by checking ECM_GLOBAL_FIND_VERSION to activate the addition 
of stricter settings, while having some cmake vars which set before including 
KDECompilerSettings allow to overrule that (compare also how KDECMakeSettings 
has variable flags to control what scope of settings is activated, like 
KDE_SKIP_RPATH_SETTINGS).

So people not bumping min ECM required in their projects see old behaviour 
(like released tarballs), anyone bumping to a certain higher version (usually 
where things got added) opts in, those variables set before allow to opt out 
still for certain things if not wanted.

Planning to turn a first draft into a MR tonight, for further discussion.

Cheers
Friedrich

PSA: Please do not use KDEFrameworkCompilerSettings for non-KF projects

[Friedrich W. H. Kossebau]

Hi,

the docs of the module tell us:
"KDEFrameworkCompilerSettings - Set stricter compile and link flags for KDE 
Frameworks modules."
https://api.kde.org/ecm/kde-module/KDEFrameworkCompilerSettings.html

And it has been meant that way. E.g. because extending those settings with 
more strict settings or new features would be done with other KF-specific 
requirements or policies in mind, always matching those of the current version 
(given KF & ECM are released in-sync).
Having to take care of backward-compatibility with non-KF usage and to do 
proper documentation adds additional burden not wanted here.

As convenient it is to not have to write out e.g. all the 
add_definitions(
-DQT_NO_CAST_TO_ASCII
-DQT_NO_CAST_FROM_ASCII
-DQT_NO_URL_CAST_FROM_STRING
-DQT_NO_CAST_FROM_BYTEARRAY
-DQT_NO_SIGNALS_SLOTS_KEYWORDS
-DQT_USE_QSTRINGBUILDER
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
)
that needs some other solution.

For ECM/KF5 times the train has left, we need to handle those existing abuses. 
But please fix your projects now already by changing back to 
KDECompilerSettings and the manual boilerplate, so in ECM/KF6 times that 
burden is gone.

Cheers
Friedrich

RFC: suffix ".in" instead of ".cmake" for template files to substitution processing

[Friedrich W. H. Kossebau]

Hi,

[replies only to kde-de...@kde.org, please]

tl;dr  This is a proposal to standardize on the suffix ".in" for input/
template files passed to cmake's configure_file() in KDE projects. 


When it comes to naming the files used as templates for build-time generation 
of source/data files by substitution processing, by calling cmake's 
configure_file() or configure_package_config_file(), there are currently two 
traditions/cultures alive in KDE:
* using the suffix ".in"
* using the suffix ".cmake"
Why is it like that I have some theories, but just stating the current reality 
here.

While having not too strict policies about how active developers manage their 
sources is usually a better thing IMHO, I personally favour per-product 
consistency only, in the case of input/template files though it can affect 
things outside of a single project/repository, like with files which are 
processed by the global KDE translation system:

As we discovered the last days, "scripty" (the nightly KDE translation system 
bot that synchronizes between source repositories and the database repo of the 
translators) was only instructed to handle ".desktop.cmake" files, and thus 
ignored the ".desktop.in" ones.
While scripty last night now has been instructed to also start to care for the 
".in" variant, having two different options adds some complexity and allows 
some confusion for people looking at such files ("why once .cmake and once 
.in? Is there a difference?"). And besides personal preference so far no real 
argument for being able to choose a suffix was told.

So given that and first comments on the matter mostly in similar directions, I 
propose to have some global KDE standard on the suffix of such input/template 
files, and once decided, also convert existing files to that suffix, so people 
do not revive the deprecated suffix culture due to innocent copy & paste :)

And the proposal is to use ".in".

Pros:
* ".in" can be seen used as suffix with examples in documentation of at least 
autotools, cmake, qmake & scons for input files to substitution processing, 
and as result can be also found in many projects using those buildsystems. So 
people switching between projects or new to KDE do not have to relearn or 
switch their mindset
* ".in" is shorter :)
* ".cmake" is the suffix to denote CMake code files usually, including the 
CMake config files (which are partially also generated from template files, so 
such would be named FooConfig.cmake.cmake, which at least looks strange), 
overloading the meaning of the suffix makes things a bit less clear
* [please fill in]

Cons:
* some substitution markup is cmake-specific, like #cmakedefine, so projects 
trying to support multiple build systems would like to specify the cmake-
variant filetype some more (not aware of that need in KDE projects currently)
* [please fill in]


Your comments, please.


If there seems consensus and no objections have come up until Monday, Feb. 
1st, I would then start to get us moved in that direction, unless we move 
already ourselves then :)

Cheers
Friedrich

Re: KDE review for KWeatherCore

[Friedrich W. H. Kossebau]

Am Montag, 21. Dezember 2020, 15:45:22 CET schrieb Nicolas Fella:
> On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:
> > My idea/proposal there is that the library internally makes use of that
> > demon. So code which uses KWeatherCore does not need to know that
> > implementation-wise there is a demon (which might also need to be a
> > build-time option, think app bundles who do not like separate demon
> > processes).
> > So the demon would not use KWeatherCore, but be a(n optional) backend part
> > of it.
> 
> Please keep in mind that having such a daemon would be challenging to
> impossible to implement on Android and possibly other platforms as well.

That's what I tried to hint at with "(which might also need to be a build-time 
option, think app bundles who do not like separate demon processes)."

> Let's not overengineer the wheel without having to and focus on use
> cases relevant for our current apps and less on hypothetical use cases.

A demon is not overengineered for this purpose IMHO, and I had thought quite a 
bit how to overhaul the Plasma weather dataengine to make it sanely reusable 
as system-wide service, just never got to the editor to implement things.
But those who do the code decide and can apply their favourite architectures 
and whatever makes reaching a working product for them faster :)

Cheers
Friedrich

Re: KDE review for KWeatherCore

[Friedrich W. H. Kossebau]

Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting weather data fetching code from KWeather. I think having a
> dedicated weather library can serve the following propose: - simplify the
> KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE
> 
> Many of you may have already seen my previous email to kde-devel mailing
> list.
> Thank you for your constructive suggestions. Here are something I want to 
clarify:
> > I would also propose to consider doing a demon instead, so different
> > programs/processes all interested in weather forecast data could share the
> > data
> 
>   The end goal is a daemon indeed, but we want to build the daemon upon the
> library. This would give us flexibility in the future if we don't want a
> daemon. At least KWeather and other projects can still benefit from the
> code.

My idea/proposal there is that the library internally makes use of that demon. 
So code which uses KWeatherCore does not need to know that implementation-wise 
there is a demon (which might also need to be a build-time option, think app 
bundles who do not like separate demon processes).
So the demon would not use KWeatherCore, but be a(n optional) backend part of 
it.

To give you more ideas: I would also envision there could be proxy servers one 
day. Think of big organizations with lots of devices at same location due to 
lots of people in same buildings, so interested in the same local weather 
data, like schools, office-heavy companies, they could have a single proxy 
server and all clients would just use that proxy, saving the weather/
environment service provider some bandwidth, also adding some privacy layer 
onto the provider. If KWeatherCore would be prepared to handle that scenario 
in one way or the other, even better.

> > but we want to make sure we don't end up with two things.
>   I admit there are some overlapped functionalities. But KWeatherCore isn't
> designed as a weather data provider as Weather DataEngine. Instead, it's
> trying to be the building block of weather related applications.

Consider a DataEngine to be some kind of Plasma-specific type of library, as 
in, as shared logic module, just with a normalized API. This technology though 
failed to stay in developers' hearts, and these days is deprecated and instead 
all DataEngines are turned into plain C++ libraries with specific API.
The Plasma weather dataengine from plasma-workspace/dataengines/weather might 
have already been turned into a library similar to kweathercore, just that the 
last maintainer (me) was attracted by other even more interesting stuff and 
no-one had picked up so far. See also https://phabricator.kde.org/T13349

Looking at the current API of KWeatherCore, e.g. 
KWeatherCore::WeatherForecastSource, I think the Plasma Weather DataEngine and 
KWeatherCore are very much overlapping, other than the one being a Plasma 
"library" and the other a normal C++ library.
With KWeatherCore now thankfully being created by yours, the weather data 
related features of the weather dataengine would be ideally merged into 
KWeatherCore, so that the weather dataengine itself can then be deprecated and 
all existing weather DataEngine consumers (like kdeplasma-addons/applets/
weather or some on https://store.kde.org/browse/cat/424) could be ported to 
something based on KWeatherCore (I guess there would be some kind of KWeather 
qml plugin then for these, next to the KWeatherCore library itself).

You will find the normalized data model used by the DataEngine here in the 
class documentation, which then would ideally be merged into the normalized 
data model of KWeatherCore, so the existing applets would not need that much 
porting but get data close to what they are using now:
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/
weather/ions/ion.h
(that normalized data model BTW lacks support for sub-day-granularity for 
forecasts (like day & night as available with the Canadian service, resulting 
in bad hack and resulting display in the Plasma applets when using that 
service), so with room for improvements itself)

The weather dataengine also has a plugin mechanism (using DataEngines again 
for some perhaps random reason, just ignore that) to allow adding support for 
further weather data provider services by 3rd-party. Such an extension feature 
would be also nice to have with KWeatherCore. Some more info also here:
https://frinring.wordpress.com/2016/04/02/plasma-weather-widget-code-template-available-to-add-your-favorite-weather-data-provider/

Then as Volker already pointed out in good detail, using non-KDE service 
providers on the internet comes with lots of traps, related to privacy and 
terms of usage 

[DONE] Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Hi,

Am Samstag, 15. August 2020, 19:20:53 CEST schrieb Friedrich W. H. Kossebau:
> what is markdownpart you ask? A KParts plugin allowing to view markdown
> documents rendered e.g. in Kate's preview plugin, Ark, Krusader or
> Konqueror, being mainly a wrapper around QTextDocument::setMarkdown &
> QTextBrowser. See here it being used with Kate's preview plugin:
> https://cdn.kde.org/screenshots/markdownpart/markdownpart.png
> Note (edit: updated): Qt 5.14 minimum needed
> 
> I would like to propose markdownpart for a move into community maintenance
> mode and becoming part of release service managed projects starting with RS
> 20.12. It would match graphics/svgpart in the mode (whose code mode BTW is
> aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView).

Am Montag, 24. August 2020, 00:30:13 CEST schrieb Friedrich W. H. Kossebau:
> Small plan change here:
> given 20.12 is quite some weeks away still, markdownpart should move post-
> kdereview first into extragear, for one or two releases with the initial
> feedback added and especially translations, and only then enter release
> service latest in November before the repo freeze.

Thanks everyone for their review & comments.

Without any open objections or todos, I am now executing the sketchecd plan:
* move markdownpart into extragear/utils today
* do official string freeze on trunk today
* do a 0.1.1 release on Monday, September 21st from trunk
  (so translators have 3 weeks occasion to add support for their locale)
* move into release service set before November
  (waiting a bit after 0.1.1 in chance bugs are reported which should be fixed
  in a release before 20.12)

Cheers
Friedrich

Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Am Samstag, 15. August 2020, 19:20:53 CEST schrieb Friedrich W. H. Kossebau:
> Note: for now Qt 5.15-only, 5.14 possible but untested.

BTW, thanks to feedback the min dependencies are now lowered to Qt 5.14 & KF 
5.66.

> I would like to propose markdownpart for a move into community maintenance
> mode and becoming part of release service managed projects starting with RS
> 20.12. It would match graphics/svgpart in the mode (whose code mode BTW is
> aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView).

Small plan change here:
given 20.12 is quite some weeks away still, markdownpart should move post-
kdereview first into extragear, for one or two releases with the initial 
feedback added and especially translations, and only then enter release 
service latest in November before the repo freeze.

Makes sense?

Otherwise thanks for review & feedback so far. Seems there have no obstacles 
come up so far, so upcoming Saturday markdownpart can then leave the current 
stage, and would go to extragear/utils, right into preparation of first full 
release.

Cheers
Friedrich

Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Am Freitag, 21. August 2020, 23:34:03 CEST schrieb Albert Astals Cid:
> El dilluns, 17 d’agost de 2020, a les 23:04:44 CEST, Friedrich W. H. 
Kossebau va escriure:
> > But not my call, after all I offer this to KDE community for adoption, sou
> > your choice.
> 
> I'm a bit concerned about this being "abandonware" from birth, but seems
> there's relative interest from the community to collectively maintain it so
> not going to complain if this ends up in release service.

Thanks for statement, Albert.

Cheers
Friedrich

Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Hi Elvis,

Am Montag, 17. August 2020, 22:43:37 CEST schrieb Elvis Angelaccio:
> On 15/08/20 19:20, Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > what is markdownpart you ask? A KParts plugin allowing to view markdown
> > documents rendered e.g. in Kate's preview plugin, Ark, Krusader or
> > Konqueror, being mainly a wrapper around QTextDocument::setMarkdown &
> > QTextBrowser. See here it being used with Kate's preview plugin:
> > https://cdn.kde.org/screenshots/markdownpart/markdownpart.png
> > Note: for now Qt 5.15-only, 5.14 possible but untested.
> > 
> > I would like to propose markdownpart for a move into community maintenance
> > mode and becoming part of release service
> 
> Hi Friedrich,
> 
> why not merge this plugin into kate instead?

Let me answer with another question:
why with Kate and not with Ark or with Krusader or with Konqueror or any other 
potential KParts plugin user where Markdown viewing often is useful?

Bundling with Kate would be a rather random choice IMHO. And
a) make it challenging for packagers to split out an independent packager for 
the markdown kpart with all the files belonging to it
b) make it harder for anyone interested in hacking on it, as they would have 
to also care about the whole Kate repo and its complete build system, when 
they just want to improve the markdown viewer e.g. for Ark.

But not my call, after all I offer this to KDE community for adoption, sou 
your choice.

Cheers
Friedrich

Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Hi Ivan,

Am Sonntag, 16. August 2020, 17:00:23 CEST schrieb Ivan Čukić:
> Hi Friedrich,
> 
> Very nice, thanks for doing this!

Glad to see people liking it, so my time was more worth it :) 
And thank you for review.

> These are the few nit-picks (feel free to ignore them) I have:

Nitpicks are welcome with me :) Actually taking culprit in not having run any 
code checker before uploading, bad me. And trying to excuse that with "Was 
just a quick proof of feasibility for others to use" sounds awful typing it, 
darn, no way out, lesson learned.
Hm, I could blame the wiki page
https://community.kde.org/ReleasingSoftware#Sanity_Checklist
not yet having mentioned running sanity tools :)
Added that there for everyone's next time now.

> markdownview.cpp:55
> 
> The `hasSelection` variable makes the code look much more complex than it
> is. It can be removed and the last argument of the `Q_EMIT
> contextMenuRequested` call set to:
> !linkUrl.isValid() && hasSelection()

Yes, does look strange without context, will clean up. Though still as 
separate variable, so the parameter as passed in the emit call gets some 
semantic by the variable name.
Motivation was to keep the code similar to patterns used in KWebKitPart & 
WebEnginePart, to allow some more detailed context menu once possible. Current 
QTextDocument/QTextBrowser API though does not provide same level of detail, 
so resulting in that empty logic, which I can see how it confuses.

Adding a comment instead, so the next person extending things knows what to 
look at to keep things consistent.

> markdownpartfactory.cpp:45
> 
> Personal preference - use `auto` when you have `= new Something(:::)` on the
> right - no need for `Something` to be written twice:
> Something* p = new Something(...)
> 
> The variable part can even go away - just return new MarkdownPart.
> 
> Similar lines exist in markdownpart.cpp, though there you use auto almost in
> all these cases.

Not repeating type name is also my preference (though with pointer indicator * 
-> "auto*" here to make code more obvious). Excuse: this was the old code just 
copied from kmarkdownwebview I did not have to touch, so stayed away from 
messing with. Now you made me (will backport also to keep diff small).

Also removed temporary variable as proposed, development left-over.

> markdownbrowserextension.cpp:51
> 
> There is no point in having the `const bool forcesNewWindow = false`
> declared at the beginning of the function when it is used only in a single
> line at the end of the function:
> bargs.setForcesNewWindow(forcesNewWindow);
> 
> Replacing this with false is IMO more readable as you don't need to scroll
> up to check what the value of forcesNewWindow is:
> bargs.setForcesNewWindow(false);

Same reasoning as with hasSelection of the context menu. And will do same 
resolution, making code simple, but pointing to similar code for consistency 
in handling on potential future changes.

Should be all dealt with now in latest master :)

Cheers
Friedrich

Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Am Sonntag, 16. August 2020, 00:03:53 CEST schrieb David Faure:
> The code looks fine to me.

Thanks for review.
 
> The only thing I saw was case-insensitive comparison of the result of
> QUrl::scheme() which is unnecessary, it always returns lowercase.

Ah, was not aware (and missed the inconsistency with other checks of the 
scheme). 
Going to fix the same also in KWebKitPart, WebEnginePart, and 
KMarkdownWebView, which is the copy trace of that code snippet from what 
I can tell :)
And actually discovered my code had some inverted logic flaw as well, also 
fixed.

> Glad to see KParts still lives :-)

Living code fossils, still not ready for static display in museum :) 

Cheers
Friedrich

KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed

[Friedrich W. H. Kossebau]

Hi,

what is markdownpart you ask? A KParts plugin allowing to view markdown 
documents rendered e.g. in Kate's preview plugin, Ark, Krusader or Konqueror, 
being mainly a wrapper around QTextDocument::setMarkdown & QTextBrowser.
See here it being used with Kate's preview plugin:
https://cdn.kde.org/screenshots/markdownpart/markdownpart.png
Note: for now Qt 5.15-only, 5.14 possible but untested.

I would like to propose markdownpart for a move into community maintenance 
mode and becoming part of release service managed projects starting with RS 
20.12. It would match graphics/svgpart in the mode (whose code mode BTW is 
aöso similar, mainly a wrapper around QSvgRenderer & QGraphicsView).

The code lives at https://invent.kde.org/utilities/markdownpart since 
yesterday.
I consider the project stable & done already though, given there are no more 
features I want myself and given it is based on existing code: mainly a copy 
of KMarkdownWebView, which itself was inspired/driven by e.g. KWebKit/
KWebEngine KParts code.
Some small glitches are with the search tool and incremental search sometimes, 
but that might be a bug in QTextDocument/QTextBrowser.

I have written this plugin mainly because "I could :P" and some people might 
like it, less because I want to use this myself everyday (personally dislike 
Markdown). So I would be interested to pass maintenance over into community 
domain, or interested individuals if there are. Otherwise it would be a 
candidate for the attic.

Today I released a first 0.1.0 version to make it spread and find users who 
fancy it:
https://mail.kde.org/pipermail/kde-announce-apps/2020-August/005597.html

Try yourself by building and installing with "kdesrc-build markdownpart" and 
picking "Markdown View (markdownpart)" as preferred embedding plugin for 
"text/markdown" in System Settings' File Associations submodule (part of 
"Applications").


So I hereby move markdownpart into kdereview mode.

Please give the code some eyeball times and comment for good and bad or 
missing stuff and whether you agree if this should become part of KDE 
community-managed set of software. Also hoping to see someone offering 
themselves to adopt this project as caring maintainer.


BACKGROUND

You might know the KParts plugin from KMarkdownWebView for the same purpose 
(https://invent.kde.org/utilities/kmarkdownwebview).

It had been written 3 years ago as quick solution, with an important 
statement in the README:
"The software should serve as intermediate solution until some native Qt-based 
implementation is done."

While there has been some native variant present meanwhile via the Okular 
Markdown support for some time, and available via the Okular KParts plugin, 
the paged display of Okular might not meet the desire of some to see the 
Markdown document rendered as single adaptive page.

With QTextDocument having gotten some native markdown-parsing support in Qt 
5.14, some recent discussion about whether to include KMarkdownWebView (and 
the QWeb* dependencies it brings) into Kate app bundles for the preview 
feature triggered me to give it a try to write a QTextDocument-based variant. 
Which turned out to be simple to do in an evening, and so here we are.

Cheers
Friedrich

PSA: Qt logging category names of all KF modules have changed for KF >= 5.73 (current master)

[Friedrich W. H. Kossebau]

Hi,

as of this morning, latest master branch of all KDE Frameworks modules has 
seen a change of all the Qt logging category names they define, to now follow 
standardized patterns. Those are described over at
   https://community.kde.org/Frameworks/Frameworks_Logging_Policy

So everyone running KF daily master or later picking up the KF 5.73 release  
will notice the new category names in the log (and the need to update any 
local rules).

Please also make sure that any currently prepared patches for KF modules are 
adapted to the new patterns where needed and new ones using them from the 
start.

Motivation:
So far category names in KF modules were not following a consistent pattern, 
instead it was names like
* org.kde.attica
* org.kde.pim.kcalcore
* kf5.kconfig.core
* kf5.kconfigwidgets
* sonnet.core
* sonnet.plugins.aspell
* kf5.kemoticons.plugin_adium

As a result one could not "calculate" the name which would be used for a given 
library (or feature), but had to first look that up (or rely on 
kdebugsettings & maintained .categories file). Also was it not possible to 
rule all of KF in one go. And the log output with all the different prefixes/
namespaces made it harder to scan.

The polilcy now asks to use these patterns for the category names:

"kf".[.][.]
"kf"...[.]
"kf"..[.]
"kf"..[.]

So the examples from above become:
* kf.attica
* kf.calendarcore
* kf.config.core
* kf.configwidgets
* kf.sonnet.core
* kf.sonnet.clients.aspell
* kf.emoticons.adium

See for a more detailed description and reasoning the task
https://phabricator.kde.org/T12716

Sorry for any inconvenience this change might bring for you right now by 
having to tune your local logging settings to the new names, but in the long 
run you hopefully also gain from the consistent patterns.

Cheers
Friedrich

PS: I am still not satisfied with the current state, would also like that 
there is a central place in each repo to find any category names in use as 
well have them listed in the generated API documentation to ease 3rd-party 
use. I had some draft work, but not happy yet with my approaches, so put aside 
for a bit, will myself only look at later this year again. See for problem 
discussion https://phabricator.kde.org/T12741 (ignore solution part).

Moving ring-kde to unmaintained (was: Re: Shift for parts of the CI system to Qt 5.15)

[Friedrich W. H. Kossebau]

Am Samstag, 20. Juni 2020, 12:25:42 CEST schrieb Ben Cooksley:
> On Sat, Jun 20, 2020 at 8:13 PM Volker Krause  wrote:
> > On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > > - ring-kde
> > 
> > build errors seem to be in stuff downloaded by cmake!?
> 
> Indeed, this seems to be a bit concerning.
> 
> I'm wondering if we should discontinue the CI support for this project?

Seems ring-kde is unmaintained, it has not seen any development since March 
2019, also missed to follow the renaming of GNU Ring to Jami on 18 December 
2018 (by what wikipedia tells).

So +1 for tagging the repo as unmaintained, and thus also removing from CI.

Cheers
Friedrich

Re: Submitting Grantlee as a KF5 Framework

[Friedrich W. H. Kossebau]

Hi Daniel,

Am Donnerstag, 20. Februar 2020, 22:14:29 CET schrieb Daniel Nicoletti:
> Yes, an user just raised an issue which I fixed in one PR,
> however the PR is 5yo, should I redo it in gitlab?
> Shouldn't the GitHub repo be removed or marked as moved to KDE?

Seems you missed that Grantlee for now returned to be github-only-based 
independent project, only planning to join KDE & KDE Frameworks for KF6.

See https://marc.info/?l=kde-frameworks-devel=157757468828735=2 for the 
announcement of plan changes.

So any patches for Grantlee need to be done and provided via Github again.

Cheers
Friedrich

Re: Fixing QNetworkAccessManager use

[Friedrich W. H. Kossebau]

Am Mittwoch, 19. Februar 2020, 21:01:20 CET schrieb Johan Ouwerkerk:
> On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau
> 
>  wrote:
> > Personally I am still unsure what the actual issue is. Why are redirects
> > needed at all. Why all the address changes all the time?
> 
> It is part of the HTTP spec for servers to be able to inform clients
> that resource /foo/bar has moved to /bar/baz, either temporarily or
> permanently.

:) Thanks for that explanation, but that was not my question here (that part I 
am well aware of, done my share of web stuff).

It was rather: why are subdomain names and/or access paths not once properly 
designed, but instead changed so often that redirection seems so important to 
be a default feature? Just because one can?
When we write code, we try to keep API stable as much as possible, and only 
change API when really useful, and that means for the consumer. When doing 
references in text we try to have eternally stable pointers (thanks ISBN & 
Co.),

But this request for stable URLs on the internet might be an idealistic fight 
against windmills of a web 1.0 person...

Cheers
Friedrich

Re: Fixing QNetworkAccessManager use

[Friedrich W. H. Kossebau]

Am Mittwoch, 19. Februar 2020, 08:05:01 CET schrieb Ben Cooksley:
> On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > It would also help to know where specifically we have that problem, so we
> > can actually solve it, and so we can figure out why we failed to fix this
> > there earlier.
> 
> Just bringing this up again - it seems we've not had much movement on
> this aside from the Wiki page.

The wiki page currently still just recommends to set
"networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, 
true);"

Which seems simple, but possible not what is enough in all cases.

So my open questions here to be able to act on code I contribute to are:

a) What about the mentioned QNetworkRequest::NoLessSafeRedirectPolicy, in 
which cases should that be used and when not?

b) What about the HSTS stuff, when is that recommended?

c) What is a sane number for QNetworkRequest::maximumRedirectsAllowed?

Both in general and when it comes to KDE servers.

Personally I am still unsure what the actual issue is. Why are redirects 
needed at all. Why all the address changes all the time? The "U" in 
"URL"/"URI" is for "uniform", not "unstable", isn't it ;)

Can you give some examples for URLs of resources our code uses on KDE servers, 
and why they needed to change?

And if those redirects are permanent, should the client side not also 
permanently update to the new location then, instead of continuing to poke the 
old address every time again and again, until one day it will poke into a void 
because the backward compat redirect support has been dropped?

Cheers
Friedrich

Fixing QNetworkAccessManager use for KDE services

[Friedrich W. H. Kossebau]

Hi Ben,

sorry to hear about this pain you have in all the good work you do that allows 
us to enjoy the high reliability of the KDE services. I would like to help to 
reduce that pain.

Am Samstag, 1. Februar 2020, 23:24:14 CET schrieb Ben Cooksley:
> Hi all,
> 
> For an extremely long time now, it has been a known issue with the
> QNetworkAccessManager that by default it does not follow redirects as
> issued by the server it is accessing. This is something the Qt Project
> has refused to address using the justification of 'behavioural
> compatibility'

This justification makes sense to me. People who have had in their code manual 
redirect handling would not be happy if Qt suddenly starts to do things 
internally in potentially other ways.

Also are they announcing in the API dox to consider changing the default:
"For backwards compatibility the default value is 
QNetworkRequest::ManualRedirectPolicy. This may change in the future and some 
type of auto-redirect policy will become the default; clients relying on 
manual redirect handling are encouraged to set this policy explicitly in their 
code."
https://doc.qt.io/qt-5/qnetworkaccessmanager.html#setRedirectPolicy

> This behaviour is contrary to that of just about every other HTTP
> stack (with the exception of libcurl from my understanding) and is
> behaviour that nobody expects.

In my case it would be: nobody thought about.
When talking to a given hardcoded address, e.g. to query a data blob, and it 
no longer resolves I would rather expect by default that the service is no 
longer existing. Mentally driven by C++ ABI concepts that method names & 
signatures have to be stable ;)
Possibly admins/web service developers might think different, as they might 
like to be flexible under which urls to respond to requests, given redirects 
exists in the protocol and thus invite to be used.
Might be a clash of cultures to some degree.

> As a consequence of this (broken) behaviour, Sysadmin has been
> effectively forced to implement workarounds and other compatibility
> measures in place to keep applications functional.

It is also the consequence of no developers having picked up the new built-in 
redirect accepting options having appeared in Qt 5.6 or 5.9 (more control).
And they have not done so because they (at least me) have not been aware that 
KDE sysadmins would like to be flexible when it comes to data/web services on 
KDE servers and the addresses under which they are available. See below for 
proposal how to fix that.

[...]

> Therefore, given the Qt Project is unlikely to change their position
> on this, I would like to propose the following:
> 1) That effective immediately, QNetworkAccessManager and it's children
> classes be banned and prohibited within KDE software, to be enforced
> by server side hooks.
> 2) That we fork QNetworkAccessManager and the associated classes
> within the appropriate Framework (to be determined), where the
> defective behaviour can then be corrected.

I cannot see how both help with released code out there already in the wild. 
To prepare future released code to be supportive to your redirecting desires 
when it comes to KDE services, I would rather propose this:

A) Document the need to enable redirects in requests when using KDE server 
services in the coding policies as well in the documentation of the respective 
KDE services, including code examples how to write those.
B) Have a rally to fix all current code.
C) Have an issue on bugreports.qt.io to see that Qt 6 will have changed the 
default, to what web service developers/admins would prefer.

E.g. in KDevelop code there is a query for https://projects.kde.org/
kde_projects.xml. What kind of redirect support do KDE server admins expect to 
be supported? So what QNetworkRequest::RedirectPolicy value should be set? 
What QNetworkRequest::maximumRedirectsAllowed?
Ideally one could find answers to these questions on community.kde.org.

Cheers
Friedrich

WARNING: was bad recommendation (Re: Recommendation: drop ProvidersUrl entry to rely on default value)

[Friedrich W. H. Kossebau]

Hi,

TLDR: removing the ProvidersUrl entry actually breaks things in non-Plasma 
installations, so for now has to be hardcoded, using the non-deprecated

ProvidersUrl=https://autoconfig.kde.org/ocs/providers.xml

See below for investigation results:

Am Freitag, 31. Januar 2020, 00:14:19 CET schrieb Christoph Feck:
> On 01/30/20 13:53, Friedrich W. H. Kossebau wrote:
> > as found out by discussion on irc, a good solution for everyone relying on
> > the default GHNS storage as provided by KDE is to just not hard-code any
> > value for ProvidersUrl, but leave it out and let KNewStuff default to
> > what is built into the KNewStuff library as current value.
> 
> Does it work with all KNewStuff 5.x versions? Otherwise, the required
> KF5 version would need to be bumped where this change was made.

I was to say
"Yes, works with all existing 5.x versions."
as that behaviour was there already in kdelibs4 time.
Which I remember from relying in Okteta on it.
And felt confirmed on reading again
https://techbase.kde.org/Development/Tutorials/Collaboration/HotNewStuff/
Introduction#The_Configuration_File_.28.knsrc.29
which claims:
"
The ProvidersUrl is optional, and if you just want to use what KDE provides as 
default (http://autoconfig.kde.org/ocs/providers.xml, currently 
store.kde.org), leave this out. The advantage of not specifying this field is 
that users can add more providers using the attica kcm (kcmshell5 kcm_attica). 
"
As well as getting a +1 from a KNewStuff developer ;)

Just, looking at the actual code now to confirm this, I found that actually is 
not totally true, only holds if also Plasma is installed. Why?
If ProvidersUrl is not set, KNewStuff will get the default from Attica. Attica 
has some kind of platform-support, which though is hardcoded to search only 
for a plugin called "attica_kde". That very plugin is only coming from Plasma, 
so only installed if Plasma is installed. And only that plugin provides that 
very default with the *.kde.org url.
If that plugin is not present, the code falls back to some built-in 
QtPlatformDependent object, which delivers no default provider at all.

I tested this by removing /usr/lib64/qt5/plugins/attica_kde.so, as result 
Okteta no longer had content listed in the Structures GHNS dialog. Independent 
of running in Gnome or Plasma.

So seems there is some flaw in the design of Attica when it comes to the 
concept of platforms: having a different provider for a non-Plasma platform 
does not make sense to me.
This needs to be rethought, also when it comes to defaults.

Too sleepy to think further now. And this best is sorted out by KNewStuff 
developers :)

Cheers
Friedrich

Recommendation: drop ProvidersUrl entry to rely on default value (was: Re: Get Hot New Stuff - Legacy Endpoints)

[Friedrich W. H. Kossebau]

Hi,

as found out by discussion on irc, a good solution for everyone relying on the 
default GHNS storage as provided by KDE is to just not hard-code any value for 
ProvidersUrl, but leave it out and let KNewStuff default to what is built into 
the KNewStuff library as current value.

So:
--- 8< ---
ProvidersUrl=http://{download,autoconfig}.kde.org/ocs/providers.xml
--- 8< ---
->
--- 8< ---
--- 8< ---

Cheers
Friedrich

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Hi Stephen,

Am Sonntag, 29. Dezember 2019, 00:10:50 CET schrieb Stephen Kelly:
> On 22/12/2019 16:08, Stephen Kelly wrote:
> > On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
> >> Perhaps joining the "Release Service" (formerly known as "KDE
> >> Applications")
> >> is a better place then, it also contains a set of libraries already.
> >> That would serve the purpose of having releases happening regularly.
> > 
> > The goals of making Grantlee a Framework are:
> > 
> > * Make more frequent releases which don't depend on me
> > 
> > * Make it more easy for others to contribute to development
> > 
> > 
> > I think at the point that renaming happens, the name Grantlee will
> > disappear, and we'll have two libraries (KF5::TextDocument and
> > KF5::TextTemplates or so in CMake and probably removing the C++
> > namespace).
> > 
> > I think all of that should be done together and I don't think that
> > should be done until compatibility is broken to become Qt6-based (KF6).
> 
> My conclusion from reading this thread is that this is the way forward:
> 
> * Grantlee does not become a KF5 framework. I'll continue to make
> releases from github if needed based on Qt 5. We can consider
> re-evaluating that in the future.

Not becoming a KF5 module should not stop you/us making Grantlee a project now 
developed in the KDE community. Given your two goals cited above, making 
Grantlee hosted on KDE resources and releasing it as part of the "release 
service" should satisfy your goals already now.

And it would allow to make Grantlee already now move as close enough as 
possible to KF standards, besides the naming ones. So that at KF6 time only 
those things are left to do both on producer & consumer side which are about 
ABI breakage.

Why are you proposing to do a step back instead to the old state, which 
everyone including you considered not that satisfying?

I hope my personal objections raised about it becoming an official KF module 
already now have not arrived with you as objection in general. On the 
opposite, I agree with the ideas behind this move. I have just strict feeling 
about KF as a product itself when it comes to consumer as well as cross-module 
ontributor experience.
So please be aware that I would be sad if you decided to have Grantlee go back 
to lonely cowboy mode :)

Cheers
Friedrich

Re: Keysmith in kdereview

[Friedrich W. H. Kossebau]

Sending my reply on-list while Johan's resent reply to list seems stuck in 
moderation:

Am Samstag, 28. Dezember 2019, 15:03:33 CET schrieb Johan Ouwerkerk:
> On Wed, Dec 18, 2019 at 5:43 PM Friedrich W. H. Kossebau
> 
>  wrote:
> > Other things noticed on superficial look:
> > * UI not translated, i18n support setup missing completely
> 
> Yes, there is an issue for that on invent:
> https://invent.kde.org/kde/keysmith/issues/5

That one is a blocker though to pass kdereview, for what I understand from 
https://community.kde.org/ReleasingSoftware#Sanity_Checklist as linked from 
https://community.kde.org/Policies/Application_Lifecycle#kdereview

At least personally I would expect this to be a minimum requirement for 
software created officially in the KDE community. Perhaps new generation of 
KDE develpoers thinks differently, but in that case please reconsider whether 
i18n is not a fundamental need :)

> > * uses own "ENABLE_TESTING", not "BUILD_TESTING" flag from
> > KDECompilerSettings> 
> >   proposed:
> >   + switch flag use to BUILD_TESTING
> >   - remove option(ENABLE_TESTING "Enable tests" ON)
> >   - remove enable_testing() (done by KDECompilerSettings)

My bad, s/KDECompilerSettings/KDECMakeSettings/g here.

> I'm not entirely sure what the origins of this are but see also the CI
> template for building flatpaks:
> https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/binary-flatpak.
> yml As you can see from the example usage the `-DENABLE_TESTING` flag is
> suggested there.
> 
> Speaking as a developer I don't really care what it is called, but I
> would like it to be on by default. Is that the case for
> `BUILD_TESTING`?

Main motivation here is consistency in the code created in the KDE community, 
so people working across KDE projects do not have to switch mind all the time.

Yes, BUILD_TESTING is ON by default, either indirectly via CTest or explicit, 
see 
https://phabricator.kde.org/source/extra-cmake-modules/browse/master/kde-modules/KDECMakeSettings.cmake$190
 and https://cmake.org/cmake/help/latest/
module/CTest.html

The people doing flatpaks want to fix the template, please poke them to do so 
(did already a comment on the commit myself, but someone needs to run after 
this to also happen :) ).

Cheers
Friedrich

Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:
> On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> > Hi all,
> > 
> > in any case, maybe the discussed points should go to the KF6 workboard?
> > https://phabricator.kde.org/project/view/310/
> > 
> > I indeed believe that consistency in the KF5 world is an important
> > feature,
> > so Friedrich does have a point here. Other framework additions had to
> > adapt
> > as well (what comes to my mind is renaming of KQuickCharts or
> > KCalendarCore).
> 
> There is one important difference between KCalendarCore/KQuickCharts/etc and
> Grantlee/QKeychain/etc though. The former had no previous release promising
> a public API and therefore only KDE-internal users. The latter have such
> releases and guarantees, and a significant KDE-external user base. That's
> what makes me consider a transitional pragmatic exemption from certain
> conventions, if we assume it would help to grow our external user base, and
> thus the pool of potential contributors.

Having to make exemptions shows a principal design flaw though: if the idea is 
to pull in more libraries into KF, incl. some with previous releases & thus 
existing userbase hoping on longer-term stable ABI, the same will also happen 
in the KF6 series. And even for the currently discussed two libs Grantlee & 
QKeychain it means at least 1 1/2 years & longer (assuming KF 6.0.0 is coming 
then, and see how long kdelibs4 survived) for being just "exemptions".
It's rather that the "exemptions" become part of the rules that way.

And this would add exceptions which have to be found out about on a case-by-
case base, as nothing in the individual name suggests which KF modules follow 
all KF patterns and which not. Who in some wees remembers which modules are 
exceptions and which not? So this makes things also for current KF modules 
more complex and thus KF a worse meta-product.
More complex and worse for all of users, support people & contributors.

Ruining the current consistent rules for some hunt on some bigger numbers of 
"external user base" of KF by adding more libraries might result in a net loss 
of users though, as KF would get more confusing and thus less interesting.
I guess at least I am not the only one who prefers simple & thus easy things 
to create solutions from :)

So, IMHO if libraries do not follow KF rules, they should not use the 
"KF"/"KDE Frameworks" label. Anything else just blurs the concepts and lowers 
the quality of this meta-product.

My 2 cents as mainly KF user and only casual contributor :)

Cheers
Friedrich

PS: And yes, even current KF set of libs has some pattern issues which confuse 
and thus steal time & joy now and then, so ideally would be fixed.
Like KSyntaxHighlighting having a non-pattern repo name "syntax-highlighting" 
still, where one expects it to be "ksyntaxhighlighting".
Or modemmanager-qt/networkmanager-qt/bluez-qt being off the KDE naming 
pattern, setting them apart a bit, not feeling full kdeframeworkish.

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Sonntag, 22. Dezember 2019, 17:08:15 CET schrieb Stephen Kelly:
> On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
> > Perhaps joining the "Release Service" (formerly known as "KDE
> > Applications") is a better place then, it also contains a set of
> > libraries already. That would serve the purpose of having releases
> > happening regularly.
> The goals of making Grantlee a Framework are:
> 
> * Make more frequent releases which don't depend on me
> 
> * Make it more easy for others to contribute to development
> 
> 
> I think at the point that renaming happens, the name Grantlee will
> disappear, and we'll have two libraries (KF5::TextDocument and
> KF5::TextTemplates or so in CMake and probably removing the C++ namespace).

There is no need to drop the name "Grantlee", IMHO that is a well-known 
product/solution identifier by now for the needs it solves. There are other 
non-generic-name identifiers in KDE Frameworks (Sonnet, Purpose, Prison, 
Attica, Solid, Baloo, Syndication) instead of "K" + generic descriptive 
english name, so it is also nothing new in concept.

KF5::TextDocument & KF5::TextTemplates as target/lib names e.g. would be less 
useful, as they could describe a lot of things and would need to be longer to 
be more exact :)

So having "Grantlee" as easily searchable term which also is properly defined 
what solution scope it is about can be actually seen as an advantage.

> I think all of that should be done together and I don't think that
> should be done until compatibility is broken to become Qt6-based (KF6).
> 
> If joining the Release Service helps reach the goals, and there is
> consensus that Grantlee can't be a framework without partial renaming
> (ie renaming the CMake interface but little else) in KF5, then that
> might be the way to go.

So far I was hoping we could have both for KF5 already, backward-compatible 
CMake config files with old imported targets as well as parallel new KF5-
namespaced CMake names. Myself still no good idea how to do this in CMake 
without too much manual complicated fragile hackery.

Cheers
Friedrich

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly:
> On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
> > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> >> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> >> 
> >> I've pushed a few commits to make it depend on ECM etc.
> >> 
> >> Once the review period is finished it can be part of KF5 releases.
> > 
> > There are quite some things which yet need to be done for now:
> > to be a true KF module there is a set of policies which needs to be met,
> > see https://community.kde.org/Frameworks/Policies
> > 
> > 1) Framework directory structure:
> > moving stuff into src/, autotests/ & docs/
> > 
> > 2) Framework documentation:
> > current system needs adaption to both online (KApiDox) and
> > offline (ECMAddQCH) systems
> 
> Cool, I wonder if there's another multi-library framework for comparison?

With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their 
multiple libs.

With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit 
(not involved there),
Olivier (cc:ed) should be able to hint you what is possible.

> > Another challenge would be moving into the KF5 namespace for the library
> > artifacts (at least I would expect/recommend this to happen, for
> > consistent
> > user experience)
> > a) include dirs below subdir KF5/
> > b) CMake modules with KF5 prefix
> > c) CMake imported target in KF5 namespace
> 
> I don't support changing things like this in the KF5 timeframe.

IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, where 
the namespace gives consistent developer experience and product messaging.

Having Grantlee being a special kid, with unregular CMake modules names and 
differently namespace imported CMake targets, makes things more complex.

Being consistent is what we so like about Qt, and KF should not stay behind, 
no?

Perhaps joining the "Release Service" (formerly known as "KDE Applications") 
is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.

Cheers
Friedrich

CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> 
> I've pushed a few commits to make it depend on ECM etc.
> 
> Once the review period is finished it can be part of KF5 releases.

There are quite some things which yet need to be done for now:
to be a true KF module there is a set of policies which needs to be met, see 
https://community.kde.org/Frameworks/Policies

1) Framework directory structure:
   moving stuff into src/, autotests/ & docs/
2) Framework documentation:
   current system needs adaption to both online (KApiDox) and
   offline (ECMAddQCH) systems

I could do 1) if you like, and help with 2) on the ECMAddQCH part.

Another challenge would be moving into the KF5 namespace for the library 
artifacts (at least I would expect/recommend this to happen, for consistent 
user experience)
a) include dirs below subdir KF5/
b) CMake modules with KF5 prefix
c) CMake imported target in KF5 namespace

Now, the question is if we want Grantlee to be backwards-compatible after the 
move into KDE Frameworks, or if some breakage is possible?

When it comes to CMake targets & modules, the first challenge is:

Grantlee5 supports components, "Templates" & "TextDocument". To allow people 
doing e.g.
--- 8< ---
find_package(Grantlee5 CONFIG COMPONENTS Templates)
--- 8< ---
So when Grantlee becomes a component in KF5 itself, so people would use for 
finding it
--- 8< ---
find_package(KF5 CONFIG COMPONENTS Grantlee)
--- 8< ---
these two, "Templates" & "TextDocument", would need to become subcomponents. 
Which though is a concept CMake does not support.

So what to do here? Split Grantlee into two separate libs, with separate CMake 
config files? Done by KF5NewStuff, where one repo provides 2 separate configs.
Or just merge and do not allow making dep chain more narrow (Grantlee's 
TextDocument pulls in QtGui as dep, so fails if no devel package not present)?


Then Grantlee's CMake module brings two namespaced imported targets:
* Grantlee5::Templates
* Grantlee5::TextDocument
With Grantlee being part of KDE Frameworks, one would expect to have targets 
named like
* KF5::GrantleeTemplates
* KF5::GrantleeTextDocument
or similar.

Just, seems CMake does not expect the use case of exporting targets with 
different names, there is only one property available to set the base name, 
cmp. current
--- 8< ---
set_property(TARGET Grantlee_Templates PROPERTY EXPORT_NAME Templates)
--- 8< ---
So when wanting to keep backward compatibility, we are stuck here with the old 
basenames.
Do you know any simple trick to have a separate CMake config file with 
separate imported targets, which still refer to the same library executable?
Never done myself, so no idea what could be done. Doing a separate target and 
exporting that one will fail possibly once trying to set OUTPUT_NAME property 
to the same,
Perhaps one could do a manual cmake config file which has the old one as 
find_dependency and then defines an alias target on the imported target?

Cheers
Friedrich

Re: Submitting Grantlee as a KF5 Framework

[Friedrich W. H. Kossebau]

Hi Stephen,

Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> 
> I've pushed a few commits to make it depend on ECM etc.

You pushed only to github though it seems :) Forwarded your commits now to the 
master branch on the main KDE repo. And did some commits to make things even 
more (current) KF-like.

Speaking of making sure all is synced & moved from github to KDE systems:

There are still some merge requests open on https://github.com/steveire/
grantlee/pulls. Also are there some open issues which might be wanted to be 
moved over to bugs.kde.org?

Cheers
Friedrich

Re: Keysmith in kdereview

[Friedrich W. H. Kossebau]

Hi Bhushan,

Am Mittwoch, 18. Dezember 2019, 15:50:36 CET schrieb Bhushan Shah:
> Hello everyone!
> 
> Keysmith (https://invent.kde.org/kde/keysmith) has been moved to
> kdereview.
> 
> Keysmith is a Two-factor code generator for Plasma Mobile and Desktop
> and is using oath-toolkit for this purpose. User interface is written in
> the kirigami.

Did some usual-nitpick-CMake-code cleanup commit already (things which also 
apply to other new Plasma repos, someone might want to brush over their 
CMakeLists.txt as well, using that commit as reference).

Other things noticed on superficial look:
* UI not translated, i18n support setup missing completely
* uses own "ENABLE_TESTING", not "BUILD_TESTING" flag from KDECompilerSettings
  proposed:
  + switch flag use to BUILD_TESTING
  - remove option(ENABLE_TESTING "Enable tests" ON)
  - remove enable_testing() (done by KDECompilerSettings)
* you might want to check if KF 5.37 has minimum version of Kirigami features 
used, otherwise needs bumping

Also surprised to see org.kde namespace added to the binary executable name, 
is that a new xdg recommendation?

No clue about purpose of app otherwise, so no usage tested besides starting :)

Cheers
Friedrich

Re: KTimeTracker in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 19. November 2019, 05:20:23 CET schrieb Alexander Potashev:
> Hi,
> 
> KTimeTracker [1] has been moved to kdereview.

Did some favourite-nitpicks review comments as direct fixes.

Otherwise looks nice code on a quick superficial view. Needs other eyes though 
for proper review.

You want to instruct the Messages.sh to just care for the src/ subdir, and 
there also exclude the test/ subdir (just in case and to speed up execution).
Possibly first part can best be handled by moving Messages.sh into the src/ 
subdir.

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Samstag, 9. November 2019, 14:16:08 CET schrieb David Edmundson:
> > If one restricts oneself to use only libraries part of KDE Frameworks, but
> > not from the "Extragear" domain, one should reconsider it, this does not
> > make much sense as long one also uses non-KDE-party libraries (which also
> > do not follow KF rules).
> 
> Plasma effectively has such a rule.
> 
> Treating this as a more meta discussion about libs, sure, with KDE
> rules in extragear you can change ABI/API but the consequences still
> mean in reality you can't.
> Release an incompatible lib, things explode until recompiled.

I am confused this is assuming one releases an incompatible library not using 
respective versioning schemes and not allowing parallel install?
But people do that properly, no?
 
> If we use a lib in plasma and in an application and then change the
> lib API we always have a window where either applications latest
> release or plasma latest release won't compile against the released
> lib. Even if you bump the .so version

Why the "even"? One should. That's what the purpose of the so version is.

> the headers aren't
> co-installable.

Some projects do proper version namespaces also for include path on changed 
ABI. If projects do not, they should start to do IMHO.
Even without, normally developers only work against one version of the 
library, so just having one variant of headers installed works good enough.

> Due to this release problem Plasma has previously made any use of
> extragear (or unstable 3rd party) #ifdef'd and always not in core
> functionality.

Given Plasma requires recent versions of KF on .0 releases, the same can be 
done also for newer versions of non-KF libraries, where one then switches to 
the new API series. No need for #ifdef.

> >But I recommend to do as others and not bind to
> 
> current first ABI for some time to come
> 
> Note this is all somewhat moot for this specific case. There is only a
> QML import. It can change ABI all it wants. Changing API is also
> doable as long as QML import bumps and the old version still works.

That is no different to normal compiled library symbols, no?
One also cannot break "ABI" (not sure what the respective name would be in 
dynamic languages), i.e. change names of symbols or their types at QML layer.

Think QQC 1 and QQC 2.

Of course this comes at cost. But personally I am willing to pay that price 
over having to stick with API which proved to be not good enough and thus 
makes my own code worse.
Thus my 2 cent recommendation to stay flexible for now :) But everyone has 
different priorities, just wanted to make you consider this.

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Donnerstag, 7. November 2019, 16:21:40 CET schrieb Nate Graham:
> On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote:
> > Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:
> >> Quick Charts is a QML module that implements a set of high-performance,
> >> GPU accelerated
> >> charts. Currently the main user of it is a new KSysGuard UI I have been
> >> working on, but
> >> once it is part of Frameworks I also hope to convert several bits of
> >> Plasma to using it.
> > 
> > If there is only one user currently, might it perhaps be a better idea to
> > do some independent releases for a while to get more feedback on the API,
> > before settling to the API freeze by being part of KDE Frameworks? It
> > will be at least a year until KF6 is there to properly fix up any
> > potential API inconveniences which users might find.
> > I would at least recommend to first get some API shaping by real-world
> > exposure.
> 
> Seems like a chicken-egg problem: more exposure would be provided by
> getting it through the review process, no? I can see us porting the
> graphs in KInfoCenter to use this, for example. But since that's
> shipping code, we might not want to do that until it's formally a framework.

If one restricts oneself to use only libraries part of KDE Frameworks, but not 
from the "Extragear" domain, one should reconsider it, this does not make much 
sense as long one also uses non-KDE-party libraries (which also do not follow 
KF rules).

Review process is about passing something from playground into the set of no-
longer-playground repos. Which for libs can be KDE Frameworks domain, but also 
the "Extragear" domain. Both are equally post-review.
And "Extragear" gives the flexibility to do another product version with 
different ABI, once there has been more feedback from more users.
An approach e.g. taken by KUserFeedback. But also compare the concept of Qt 
labs modules.
Having an API mainly done for one user only right now runs a good chance to 
miss the API needs of other potential candidates. Everyone needs a different 
20 % of the API concepts, they say when throwing with numbers ;)

Np chicken-egg problem here. Release-often-and-early should be simply applied 
to KChickCharts as well. But I recommend to do as others and not bind to 
current first ABI for some time to come, like begin of KF6, instead plan for 
some optional ABI-breaking releases in the near future. So be under the rules 
of Extragear, not yet Frameworks.
But people learn best from own mistakes, so feel free to ignore some old 
person's comment-from-experience. ;)
If the API proves to be not perfect and one knows how it would be better, ~12 
months (to KF6) can be very long :P

Cheers
Friedrich

Re: Quick Charts in KDE Review

[Friedrich W. H. Kossebau]

Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:
> Hi,
> 
> Quick Charts has been moved to KDE review. The intent is to make it a
> Tier 1 framework.

Any chance the official name can be "KQuickCharts"? "Quick Charts" is a 
generic name which only asks for being misunderstood, is hard to google etc..
 
> Quick Charts is a QML module that implements a set of high-performance,
> GPU accelerated
> charts. Currently the main user of it is a new KSysGuard UI I have been
> working on, but
> once it is part of Frameworks I also hope to convert several bits of
> Plasma to using it.

If there is only one user currently, might it perhaps be a better idea to do 
some independent releases for a while to get more feedback on the API, before 
settling to the API freeze by being part of KDE Frameworks? It will be at 
least a year until KF6 is there to properly fix up any potential API 
inconveniences which users might find.
I would at least recommend to first get some API shaping by real-world 
exposure.

Sorry otherwise for not reviewing myself, not into QML the recent months.

Cheers
Friedrich

HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

[Friedrich W. H. Kossebau]

Hi,

with KF 5.64 now branched and thus the new deprecation macros going to be 
released for the first time, now please make sure when in the future marking 
API as deprecated to use the correct current version, i.e. the one where the 
deprecation will be made public the first time.

So if pushing a commit which deprecates API, make sure the "x" is matching the 
upcoming version of KF where the deprecation will be released the first time:

#if KFOO_ENABLE_DEPRECATED_SINCE(5, x)
/**
 * @deprecated Since 5.x. Use bar(). // Sadly doxygen needs data duplicated
 */
KFOO_DEPRECATED_VERSION(5, x, "Use bar()")
void foo();
#endif

((In a perfect world this boilerplate/duplication would not be needed and 
tools would automate this for us, but for now we have to do it manually.))

Do _not_ use an older KF version where the API might already have been 
considered deprecated, but was forgotten to be marked. Use the upcoming KF 
release version only.


In the last weeks, since 5.63 was branched, while the new deprecation macros 
generated with ECMGenerateExportHeader were introduced you may have seen also 
lots of older versions being used. But that was fine due to the macros not yet 
been released and changes done to be historically correct, like also matching 
any already existing version info in the API dox by the @deprecated tag. 
Hopefully we have catched any existing KF API which has been considered 
deprecated before.

But now with KF 5.64 being branched and going to be officially released 
exposing the new deprecation macros and thus the options to control visibility 
of and warnings about deprecated KF API, people using KF libraries in their 
software will e.g. start to use the *_DISABLE_DEPRECATED_BEFORE_AND_AT macros, 
to protect themselves against usage of API deprecated the first time up to a 
certain version, for which they have checked their code builds fine against.
And we would thus ran chance to break their software builds if we now marked 
more API as being deprecated in previous versions in future KF releases. Not 
our mission :)

Cheers
Friedrich

Heads-up for developers using KF modules: how to disable visibility of & warnings about deprecated API for >= 5.64

[Friedrich W. H. Kossebau]

Hi,

tldr; Please test now with git master the new available C++ macros with KF
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXXYYZZ
-DKF_DEPRECATED_WARNINGS_SINCE=0xXYYZZ
-DKF_NO_DEPRECATED_WARNINGS
-DKF_NO_DEPRECATED
as well as individual specializations per library, e.g.
-DK{LIB}_DISABLE_DEPRECATED_BEFORE_AND_AT=0xXYYYZZ
-DK{LIB}_DEPRECATED_WARNINGS_SINCE=0xXXYYZZ
-DK{LIB}_NO_DEPRECATED_WARNINGS
-DK{LIB}_NO_DEPRECATED 
so issues can be catched before the 5.64 release.


Last WE git master of all KDE Frameworks has seen the completion of the 
introduction of a new feature which allows developers building against KDE 
Frameworks libraries to control which of its deprecated API is visible to the 
compiler as well as for which versions deprecation warnings should be emitted.

You are invited or rather encouraged to give this a testing now already, so 
issues can be catched before this gets released in then KF 5.64.

Without any settings, you will get warnings when using deprecated API, any 
deprecated API is visible to your build.

To just get rid of any warnings, use (with CMake, also ff.)
add_definitions(-DKF_NO_DEPRECATED_WARNINGS)

To just hide any deprecated API to your build, use
add_definitions(-DKF_NO_DEPRECATED)

To disable warnings about API deprecated first after a given version or, in 
other words, only see warnings for API deprecated first in versions up to and 
including a given, use (example: 5.28.0)
add_definitions(-DKF_DEPRECATED_WARNINGS_SINCE=0x051C00) # 5.28.0

To hide deprecated API up to and including a certain version (e.g. the minimal 
KF version you support), use (example: 5.28.0)
add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x051C00) # 5.28.0
This also sets the default of KF_DEPRECATED_WARNINGS_SINCE to that version,
so you will not see any warnings for API deprecated in newer versions, unless
setting another version explicitly for that.

Next to these KDE Frameworks wide settings, one can also override them for 
individual libraries, using macros with a prefix matching the library name.

E.g. to override for KCoreAddons the version at and before which deprecated 
API is made invisible to the compiler, one does this (order is not relevant):
add_definitions(
-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x051C00 # 5.28.0
-DKCOREADDONS_DISABLE_DEPRECATED_BEFORE_AND_AT=0x05
)

The names here are following the similar macros introduced with Qt 5.13, cmp
https://doc.qt.io/qt-5/qtglobal.html#QT_DISABLE_DEPRECATED_BEFORE , so one can 
apply known approaches. Just using BEFORE_AND_AT, because BEFORE is not really 
correct ;)
QT_DEPRECATED_WARNINGS_SINCE also exists, with same default mechanism for API 
with a versioned deprecation macro used (only used with newer deprecated Qt 
API it seems), but so far had not been publically documented yet (cite: "Just 
forgot it (and also the reviewers) I would guess. There is no plan to change 
it, at least none I'm aware of.")

Cheers
Friedrich

Heads-up for developers working _on_ KF modules: how to mark deprecated API from now on

[Friedrich W. H. Kossebau]

Hi,

tldr; For deprecated API of KDE Frameworks modules please use 
ECMGenerateExportHeader and the respective macros to mark & wrap deprecated 
API, otherwise the whole effort breaks down. Question: where would you expect 
the documentation for how to do this?


The introduction of ECMGenerateExportHeader to KDE Frameworks has been 
completed now, all 34 KF modules having deprecated C++ API have been adapted 
to use the CMake macro ecm_generate_export_header as well as the new C++ 
macros available from the respective generated export header.

So whenever there is some API to be deprecated, its declaration would now be 
decorated like this:

#if KFOO_ENABLE_DEPRECATED_SINCE(5, x)
/**
 * @deprecated Since 5.x. Use bar(). // Sadly doxygen needs data duplicated
 */
KFOO_DEPRECATED_VERSION(5, x, "Use bar()")
void foo();
#endif

The version 5.x needs to be listed with the DEPRECATION_VERSIONS argument of 
the ecm_generate_export_header, otherwise at least KFOO_DEPRECATED_VERSION(5, 
x, "") will fail to build (you will run into this for sure as I did, just 
needs remembering, so start now :) ).

A perfect programming language would not need all this fragile duplication, 
but with current C++ this seems the closest we can do to support users of our 
libraries to control visibility of deprecated API and warnings about it, as 
well as help ourselves during ABI breaks to do smoother porting and see the 
legacy API that can be dropped.


There are some more details around all this (like when not to use the #if 
wrapper because building-against-library compiler needs to always see virtual 
methods or enum values, or disabling deprecated API from the library build 
itself using KFOO_BUILD_DEPRECATED_SINCE), my question now is where this is 
best documented in detail. I already added small snippets in some places, but 
still search for a place documenting all known cases and pitfalls.

So, if in need of guidance how to use the new deprecation mechanisms, where 
would you expect to find the help? Many answers wanted here.

Cheers
Friedrich

Re: ELF Dissector in kdereview

[Friedrich W. H. Kossebau]

Am Samstag, 12. Oktober 2019, 12:46:19 CEST schrieb Volker Krause:
> From the feedback everything should be addressed, apart from the following:
...
* "hicolor" icons for the app icon are not yet added & installed
  (proposal: copy over the breeze ones for now, like done for e.g. heaptrack)

Cheers
Friedrich

RFC: Deprecating KDesignerPlugin in favour of new ECMAddQtDesignerPlugin

[Friedrich W. H. Kossebau]

Hi,

following up on a recent discussion about kdesignerplugin currently providing 
a single Qt Designer plugin for all of those modules from KDE Frameworks which 
provide custom QWidgets, and with this coupling running against the idea of 
mpdularization with KDE Frameworks, a few patches have been sketched and made 
working to approach this.

Please see for discussion of problem and proposed solution with a series of 
patches this task:

https://phabricator.kde.org/T11289

Please add your comments there, as well as on the patches, especially the 
proposed ECMAddQtDesignerPlugin addition to ECM.

If everyone agrees with the appraoch, would be material for KF 6.62 earliest 
(so only post upcoming KF 6.61).

Cheers
Friedrich

Re: Review Request: plasma-thunderbolt

[Friedrich W. H. Kossebau]

Am Mittwoch, 15. Mai 2019, 15:27:07 CEST schrieb Daniel Vrátil:
> Thus I'd kindly ask you to take one more look at the codebase [1] and let me
> know if there are any more issues to fix, or if we can proceed to include
> this in the next Plasma release.

Pushed some small fixes to toplevel CMakeLists.txt

Other things seen on quick look at code (also not tested runtime):
* kded misses a Messages.sh file.
* no COPYRIGHT license files in the repo
* kde_enable_exceptions() duplicated a few times, perhaps only do in subdirs 
where needed or use of kde_target_enable_exceptions() if fitting
* libkbolt being a private library could be reflected in the libname, also get  
   
install(TARGETS kbolt ${KDE_INSTALL_TARGETS_DEFAULT_ARGS} LIBRARY 
NAMELINK_SKIP)

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

Hi,

tl:dr
In your CMake code replace all remaining
add_test( )
with
add_test(NAME  COMMAND )
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 
reported as failure on CI.

Long version:
It was found that on KDE CI some build states had been reported with a blue 
ball (=all good), while actually most of its tests were not run, due to the 
test executable not found. This was due to the logic on CI mapping ctest's 
 to jenkins , with the later not invalidating an "all good" 
state. This has now been changed (D20874),  with 'Unable to find 
executable' is now reported as , so will be treated like a failed 
test.
(Locally a "make test" reports not found tests as failed, so we should have 
ourselves run "make test" more often it seems :) ).

Tests executables not or no longer being found can happen when you bumped the 
minimum required ECM version to 5.38 or above and use KDECMakeSettings. 
Because this will trigger the placement of all built executable code into the 
toplevel bin/ directory, not in the normal build dir.
Which breaks the inherit assumption of

   add_executable(testfoo ${SRCS}) # add_executable( ...)
   add_test(foo-test testfoo)  # add_test( )

where the command is taken as verbatim command and usually works as the name 
of the executable target is also the name of the executable, which was placed 
in the build dir, which is the default working directory on running the 
tests.

To fix this, use the newer signature of add_test:

   add_test(NAME foo-test COMMAND testfoo)

(so just insert "NAME" & "COMMAND" before the two arguments).

Because "[i]f  specifies an executable target (created by 
add_executable()) it will automatically be replaced by the location of the 
executable created at build time." Thus the test binaries being placed in 
bin/ will no longer be an issue.
See https://cmake.org/cmake/help/latest/command/add_test.html
This signature exists already with cmake 2.8.12.

Any other related wrapper calls, like ecm_add_test, are fine and do not need 
any work.

For more background why this is needed at all, see the docs about the efforts 
trying to make tests & apps runnable uninstalled for developer convenience 
(yes, no free lunch):
https://api.kde.org/ecm/kde-module/KDECMakeSettings.html
https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel:
> Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > > > Given the actual purpose of this thread, I would be more curious how
> > > > you
> > > > have CI integrated in your workflow?
> > > 
> > > CI: sometime I look at it, sometime not, sometime some guys informs me
> > > that
> > > it's broken (I remember that Luca told me some days ago that a package
> > > didn't compile, so I fixed it).
> > > Sometime my code compiles on local so for me it's ok but it's just that
> > > I
> > > forgot to trash my builddir.
> > 
> > So you do not go on yourself to build.kde.org and check yourself? Does
> > #kde- pim have a bot reporting build failures?
> 
> Long time ago we had it in #kontact.
> It's not the case now.

Do you remember a reason why it is no longer the case?

IMHO bringing the build report bot back to the chat channel could help with 
the issue this thread is about.

People tend to look more often into the chat channel then in their email 
folder, so this bot would improve the visibility of the state on 
build.kde.org, also be in a public place so people can directly chat about 
any reasons.

> > > > more? Given you said you work daily on KDE projects, it seems that 
the
> > > > brokeness of those projects on the KDE CI has slipped your attention.
> > > > So
> > > > how does this happen, and how could this be prevented, other than
> > > > people
> > > > having to hunt you down on irc and tell you :)
> > > 
> > > I think that Luca idea to send an email directly to the people which
> > > breaks
> > > code when it breaks from several commit is a good idea.
> > 
> > Noted. Personally I would also fancy that over the generic mass emailing,
> > where most of the time it was somebody else breaking stuff, so they 
should
> > care. Given the time-offset due to build times it is also unclear who
> > broke
> > things, given the email is not easy to parse, and one might already be 
off
> > again to other things in life.
> > 
> > Question is: when would you read the email, and how quick would you 
react?
> 
> I read it sometime as it arrives in my kdepim-devel mailbox, but indeed
> sometime we can have several mail in same time because we increase a 
package
> dependancy and it breaks all other packages. So indeed I didn"t look at all
> the time.
> 
> But when a people signals me a problem I try to fix it quickly.
> 
> An email send after 1 day that package is broken can be a good idea, so it
> can't be a dependancy problem because we increase package version just that
> it's really broken.

Increasing the package version ideally should not result in CI breakages. 
Ideally CI only fails if there is a real issue, otherwise people just get 
used to it failing and do not give the deserved attention.

What would prevent you to turn to a system like used with KDE Frameworks, 
where there is some internal dependency version and a separate actual 
version, with the actual version bumped earlier and the internal dependency 
version only bumped some days later? From what I saw, you increase versions 
quite often in PIM, so related breakages would happen quite often.

Cheers
Friedrich

PS: Okay if we start to slim the list of CC:s a bit now? Would leave out 
plasma, kdevelop, frameworks-devel on any next reply at least.

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Thanks for reply. More below:

Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > Hi Laurent,
> > 
> > Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> > > For example I works all days on kde (pim or other) when I wake up, or 
at
> > > noon after my lunch or the evening, I will not wait several days for a
> > > review because nobody has time to do it.
> > > 
> > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I
> > > don't
> > > want to wait several days/weeks until someone wants to review my 
patchs)
> > 
> > Something might be lost in translation here, do you think, because you
> > work
> > daily on code of KDE projects, and other people (so potential reviewers)
> > do
> > not, this is an argument to do instant pushes of unreviewed commits?
> 
> I maintain pim* from several years, I fix bugs, I improve apps, I fix all
> bugs that I put in my code, so for this one I consider that I can commit
> without review them (as other guys on other project that they maintain).
> For framework I mainly use phabricator.

I was thinking of projects where there are multiple persons contributing/
maintaining, like Frameworks.

So for projects where you are the only person who has any real insight, 
indeed I agree to pushing directly, as I do that as well :)

Because IMHO the costs for having to hope & wait for somebody else to do a 
"review", where one then spends lots of time rather explaining things to 
someone, who is not really into the project and also never might be, is not 
anywhere worth the time one could have otherwise invested in fixing other 
existing bugs or adding new features or improving code quality.

If people want to get into a project, doing own patches or just watching the 
commits and asking normally on irc or by email about the architecture should 
work good enough. Abusing reviews for teaching about some project would annoy 
me at least, usually the patch is to fix some annoying bug or add a wanted 
feature, so it should get in as early as possible.

> > Not sure where this is from, but often I have seen an unwritten policy
> > applied where people for a patch uploaded for review after one week of no
> > response add a ping and then wait another week, before finally pushing 
the
> > change. To me this seems a fair and reasonable policy, only ignores 
people
> > who are on vacation for some more weeks or otherwise inactive, but I have
> > not seen that ever been a real issue.
> 
> 2 weeks for a commit, for me it's too long.
> I understand why people can be demotivated when they must wait long time
> until having an answer.

Well, 2 weeks is the time-out, only reached in worst case. Ideally people 
give some feedback before, which often enough happens. And indeed one also 
has to hunt people down to get a review, like at meetings or in chat (or 
trade review work with each other :) ). But isn't this the same also at work-
work, unless there is a dedicated review team which needs to react by itself? 
Co-operating on something needs social interaction after all. 

> > Given the actual purpose of this thread, I would be more curious how you
> > have CI integrated in your workflow?
> 
> CI: sometime I look at it, sometime not, sometime some guys informs me that
> it's broken (I remember that Luca told me some days ago that a package
> didn't compile, so I fixed it).
> Sometime my code compiles on local so for me it's ok but it's just that I
> forgot to trash my builddir.

So you do not go on yourself to build.kde.org and check yourself? Does #kde-
pim have a bot reporting build failures?

For what I can tell e.g. for KDevelop, personally I rely on the bot on 
#kdevelop  reporting the CI state/build results, as I only look at emails 
rather once a day, while the chat channel is more real-time, and one also can 
immediately talk to peers about why some build now fails, as well as 
coordinate who will fix that.

> > And where things could be improved, to
> > prevent the current state of unhappiness for people who care about CI 
some
> > more? Given you said you work daily on KDE projects, it seems that the
> > brokeness of those projects on the KDE CI has slipped your attention. So
> > how does this happen, and how could this be prevented, other than people
> > having to hunt you down on irc and tell you :)
> 
> I think that Luca idea to send an email directly to the people which breaks
> code when it breaks from several commit is a good idea.

Noted. Personally I would also fancy that over the generic mass emailing, 
where most of the time it was somebody else breaking stuff, so they should 
care. Given the

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 16:04:01 CET schrieb Boudhayan Gupta:
> I don't care if you lose time. I don't want the guys building my house to
> cut corners mixing my concrete because it's going to save time.

There is a difference here though, no? The people building your house will 
not live in that house. They only make money from building, so: less effort & 
lesser time for same money received -> better.

We here create software we use ourselves, no? So we are building our own 
house, and would not be expected to cut corners on our own grounds.

> As a user, I simply do not want unreviewed crap running on my computer.
> Yes, crap, because no software engineer writes bug-free code all the time,
> and if you're so overconfident that you don't need reviews on even your
> one-liners, you're probably too overconfident to be writing good code
> anyway, so I'm going to operate on the presumption that if the code hasn't
> had more than one pair of eyeballs ever looking at it, it's crap.

Hmmm... (I cannot stop myself typing the following :) )

In that case, I have to immediately notify you to make sure that you remove 
Okteta from any of the devices you have reach to, if you even ever installed 
it, best recommend your distribution to delete the package. Because 
shockingly all the >4000 commits of its >100k lines of code have been done 
without review. So it surely is an insane pile of crap by presumption, unless 
finally someone will give it another pair of eyeballs.

Though I assume no-one is using it anyway, given there are so few bugs 
reported ;)

> As a developer, I know that even one-liners, and especially one-liners, the
> sort where you think "meh, this is a tiny little thing, I don't have to be
> careful" are the ones that have the most dangerous typos and unintended
> bugs. Reviews catch that.

This sounds to me like review is magically preventing bugs.
Well, it increases the chance things get catched. Though reviews also 
increase the chance to be sloppy, as there is: review to catch that. Then 
after all is the reviewer also a developer, who also only sees a one-liner, 
where they think "meh, this is a tiny little thing, I don't have to be 
careful".

A review is only useful if the reviewers are qualified and invest the proper 
resources.

I prefer one responsible experienced developer over an unresponsible 
unexperienced developer & unresponsible unexperienced reviewer any time.

More I prefer of course one responsible experienced developer & one 
responsible experienced reviewer :)

Based on my personal experience bubble, not by any scientific means.

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Hi Laurent,

Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> For example I works all days on kde (pim or other) when I wake up, or at
> noon after my lunch or the evening, I will not wait several days for a
> review because nobody has time to do it.
> 
> (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't
> want to wait several days/weeks until someone wants to review my patchs)

Something might be lost in translation here, do you think, because you work 
daily on code of KDE projects, and other people (so potential reviewers) do 
not, this is an argument to do instant pushes of unreviewed commits?

While I understand one can get impatient if not getting instant review of 
changes one would like to depend on with further changes (I know this well :) 
), still this seems a flawed argument at least for part-time-contributors 
based KDE projects, where the people one co-operates with only have time now 
and then, like once per week. It could be seen unfair & ignorant to them if 
one simply ignores their opinion, because one has more time reserved/
available.

Not sure where this is from, but often I have seen an unwritten policy 
applied where people for a patch uploaded for review after one week of no 
response add a ping and then wait another week, before finally pushing the 
change. To me this seems a fair and reasonable policy, only ignores people 
who are on vacation for some more weeks or otherwise inactive, but I have not 
seen that ever been a real issue.

Given the actual purpose of this thread, I would be more curious how you have 
CI integrated in your workflow? And where things could be improved, to 
prevent the current state of unhappiness for people who care about CI some 
more? Given you said you work daily on KDE projects, it seems that the 
brokeness of those projects on the KDE CI has slipped your attention.
So how does this happen, and how could this be prevented, other than people 
having to hunt you down on irc and tell you :)

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 11:27:44 CET schrieb Daniel Vrátil:
> I'm completely fine with mandatory code review for everything and I'd be
> happy to have this in PIM. I think the biggest problem in PIM to overcome
> will be finding the reviewers - I dare say I'm currently the only one who
> has at least a little idea about what's going on in Akonadi, so getting for
> instance Laurent to review my Akonadi patches might be hard - same for me
> reviewing Laurent's KMail patches. This will require non-trivial amount of
> effort for all members of the community to gain deeper understanding of the
> other components within the project and a willingness to step up and do a
> code review even if they don't feel 100% comfortable with the code base.
> But I believe that in the long run the benefits clearly out-weight the
> cost.

So why do you not do this already? Why would you only do this is there is a 
policy requiring you to do it?
And why do you think this policy-driven behavioural change will work or is 
needed with everyone else?

Also, how do you ensure the review is actually of quality?
And not just socially driven "+1 for my buddie!", where buddy then also 
mentally shifts part of responsibility to other buddy, because, he, more eyes 
means I do not need to do the full work myself, glitches will be caught be 
them surely! Reviewer found a code formatting issue, done here, review 
happened.
The opposite also has been seen, reviewers feel they need to do "real" review 
and find things, so start to nitpick or to demand wrong changes, wasting 
everyone's time.

For myself I know I will happily have other people review my patches, but 
only if there are qualified people to be expected to do it with the needed 
quality in a reasonable time.

Then, trying to force by that policy other people to become proper specialist 
for certain other code projects to do qualified reviews, actually is a trade-
off. They will have less time for their actual code project, becoming less a 
specialist there (or having time to review other people's contribution to 
that project).
We need more contributors, not force existing contributors to distribute 
their abilities & resources over more projects (and thus having less for 
their actual one).

I am also not aware of many contributors to KDE projects who are not capable 
to make a responsible decision between the few obvious simple fixes and those 
normal changes which better get feedback from others first. If one is unsure 
about one's post-beer late-night quick hack, one will upload it for review, 
no? At least if one's previous late-night commits turned out to be late-night 
mental state impacted.
To deal with those few which seem challenged to do that decision properly, I 
find such a policy for everyone harmful, I know it would impact my 
contribution willingness, when I come across a typo or other simple and 
obvious to fix things. And just leave the garbage around along my current 
working path.

Besides, it will not solve the issue this thread is about, with some people 
not caring (quickly) enough if CI builds fail or if there are regressions in 
tests.

Review builds once implemented and deployed will help there partially as a 
side-effect only, catching some build fails before. But also not if this 
breaks (e.g. due to API/behavioural changes) depending projects, as CI at 
least currently does not rebuild dependent projects (cmp. also T7374).

A society with people doing things only due to policies and not intrinsic 
motivation seems very flawed to me, makes me wonder why people are in there 
given no-one forced them into this society.

https://community.kde.org/Policies/
Commit_Policy#Code_review_by_other_developers has some policies already, 
which should be enough:
1.1 Think Twice before Committing
1.2 Never commit code that doesn't compile
1.3 Test your changes before committing
1.4 Double check what you commit
1.10 Code review by other developers
1.11 Take responsibility for your commits
1.12 Don't commit code you don't understand
Well, perhaps could be amended by an explicit note about keeping CI working.

Enforcing review of any commits IMHO should be only done for people who 
notoriously failed to comply with those existing rules. If we are unable to 
pinpoint those people, talk with them and make them comply or sort out their 
reasons to not yet comply, but instead create as workaround new generic 
policies for everyone, we make this a worse society. And also a less 
effective, with more rubber stamps needed.

Cheers
Friedrich

Re: CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 09:29:22 CET schrieb Kevin Ottens:
> Hello,
> 
> On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote:
> > Please note that the commits in this instance were pushed without
> > review, so restrictions on merge requests wouldn't make a difference
> > in this case unfortunately.
> 
> Maybe it's about time to make reviews mandatory... I know it's unpopular in
> KDE, and I advocated for "don't force a tool if you can get someone to look
> at your screen or pair with you" in the past. Clearly this compromise gets
> somewhat exploited and that's especially bad in the case of a fragile and
> central component like KDE PIM.

Mandatory reviews in my experience only result in more fake reviews due to 
people pressuring each other to quickly get their simple patches reviewed, 
lowering the general quality of reviews.
Also does the overhead reduce the number of minor improvements, where one (as 
qualified person) simply would have pushed in a minute a fix and get back to 
concentrate on the real work, instead of starting an overhead of having to 
juggle with yet another patch-under-review where the current work depends on.

IMHO the actual problem here is: people do not do their post-push work and 
care for the state on CI.

From what I saw, many breakages happened with reviewed patches. Whole 
releases even get done while CI is reporting failed builds, or at least lots 
of failing tests.

I have no idea how to fix that. We would need to ask the people for whom this 
happens why it does happen, and how we can improve things so that CI checks 
become part of their workflow.

Cheers
Friedrich

Re: KDiff3 1.8 release.

[Friedrich W. H. Kossebau]

Hi Michael,

Am Samstag, 9. März 2019, 16:53:58 CET schrieb Michael Reeves:
>I would like to move forward with a 1.8 release targeting end of Apirl.
> Could someone please check over the kf5/qt5 changes to make sure there are
> no major problems? Also there is custom painter that tries to handle left
> to right text manually what is the proper way to support this? I will be
> doing at least the next few releases independent of Applications do to the
> amount time past since the last release for kdiff3. The 1.8 branch creation
> and freeze is set for 3-22 if no major issues are found.

When I gave it a (quick) look earlier today, nothing grave catched my eyes 
when it comes to Qt5/kF5 interfacing code (just a few favourite nitpicks of 
mine, which are already reviewed/pushed :) ).
No idea about the custom RL painter myself or proper ways.

Two things I noticed though which you ideally give some look:

kdiff3 -h & -v show both a window as well as print output on the commandline.
The windows are a bit unexpected and unusual given one already is on the 
commandline, perhaps that feature to also show a window could be removed?

You might also want to port the debug output from fprintf(stderr, ...) & Co. 
to qCDebug() & Co.

Cheers
Friedrich

Re: libqaccessibilityclient now in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 25. Juli 2017, 13:25:39 CET schrieb Jonathan Riddell:
> libqaccessibilityclient is now in kdereview.  It's in a git repo
> called libkdeaccessibilityclient but we filed a sysadmin request to
> rename it.
> 
> We just released 0.2.0 in unstable (for some reason 0.1.1 was released
> in stable some years ago).
> 
> What is it?
> 
> Since it's hard to grasp all the bits related to accessibility, I'll try to
> explain what the lib is for.
> Most of the stack is part of Qt 5, so nothing to worry about, that's the
> part that lets applications expose their UI over DBus for AT-SPI, so they
> work nicely with assisitve tools (e.g. Orca). In accessibility language,
> the applications act as "servers" and the screen reader for example is a
> client.
> 
> This library is for writing clients, so applications that are assistive,
> such as screen readers. It currently has two users: KMag and Simon.
> KMag can use it to follow the focus (e.g. when editing text, it can
> automatically magnify the part of the document where the cursor is.
> 
> For Simon Listens, the use is to be able to let the user trigger menus and
> buttons by voice input.

Soon it will be 2 years that libqaccessibilityclient entered kdereview, and I 
just found it seems to be still in that state, at least by what repo-metadata 
claims and given no emails to the thread which sonud like review done
I came across it when compiling kmag myself, where the optional dep on this 
exists.

It is not on build.kde.org. Possibly it is not clear yet where this library 
should end up, given there is no separate kdereview product group?

Where should it end, "Extragear"? "KDE Applications"?

Given Simon seems struggling, and KMag will not get a visum for wayland, are 
there still plans for a future, with other customers/clients? I see there have 
been a row of commits last November, incl. the 0.3.0 release, so seems there 
is some plan? 

In any case, would be good to complete the review process. To binary bin or to 
released & maintained product group.

When trying to build kmag, I found that the CMake Config files of the then 
latest libqaccessibilityclient master version were not up to modern standards 
(missing ConfigVersion.cmake file, no include dir set on imported target, 
missing deps check). I pushed some fixes for that directly, given my 
confidence in related cmake experience over what was currently in the code. 

Also fixed directly the search for Qt modules which was done without checking 
the result, And introduced the BUILD_TESTING option as known from elsewhere, 
to allow controlling whether to build the tests (and examples).

And some more clean-up for things that jumped to me from the cmake code.

Please give the commits some post-push review, though it should be fine, 
following usual coding seen elsewhere.

Actually there is more I would change, but that might get more invasive (e,g. 
using GNUInstallDirs or KDEInstallDirs) and needs more discussion/testing, so 
I would go for normal patch review then. But before that, I would like to see 
the kdereview process finished as well as build.kde.org having a normal build 
of it :)

Would be good to also have state on the last comments in this thread:
* does not compile with clang <- cannot easily check myself, so no idea
* autotests need Qt5Test, but if the dependency is not installed,
  fails silently <- should be fixed by commit d01385005c5d (BUILD_TESTING)

Cheers
Friedrich

Re: KDE Review: Rust Qt Binding Generator

[Friedrich W. H. Kossebau]

Am Sonntag, 3. September 2017, 18:14:49 CET schrieb Jos van den Oever:
> Dear KDE-ers,
> 
> A new project is up for review: Rust Qt Binding Generator.
> 
> The project is a command-line executable that creates Rust code and Qt code
> from a binding description in JSON.
> 
> The code is currently at kde:scratch/vandenoever/rust_qt_binding_generator
> 
> If you want to use Rust code in your Qt project or if you would like to add
> a Qt UI on your Rust code, this program will help you.
> 
> The binding can describe a Objects, Lists and Trees. Objects generate C
> ++ derived from QObject. Lists and Trees generate C++ classes derived from
> QAbstractItemModel. On the Rust side, a trait is created. This trait is the
> interface that the developer needs to fill with code.
> 
> The project comes with a demo application that shows Rust code powering a Qt
> widgets project, a Qt Quick Controls project and a Qt Quick Controls 2
> project. It shows a list, file system tree, a system process view and a
> chart.
> 
> That demo with the code for it is easiest way to appreciate what you can do
> with rust_qt_binding_generator.
> 
> The idea of this binding generator is that you write each part in the most
> appropriate language. Rust bindings for Qt are hard to get right and will
> still have caveats for a while. With this generator, you write the UI in C++
> or QML. The generated code has no dependencies apart from Qt Core and the
> Rust crate libc.
> 
> A simple example: Hello World.
> 
> ```json
> {
> "cppFile": "src/greeting.cpp",
> "rust": {
> "dir": "rust",
> "interfaceModule": "interface",
> "implementationModule": "implementation"
> },
> "objects": {
> "Greeting": {
> "type": "Object",
> "properties": {
> "message": {
> "type": "QString"
> }
> }
> }
> }
> }
> ```
> 
> Preparation: create a new CMake project with a Rust project in the folder
> 'rust'.
> 
> ```
> kwrite CMakeLists.txt
> kwrite bindings.json
> mkdir rust
> (cd rust && cargo init --name rust --lib)
> ```
> 
> Create bindings with this command:
> 
> ```bash
> rust_qt_binding_generator binding.json
> ```
> 
> Add the files to the main Rust library module, `rust/src/lib.rs`
> 
> ```rust
> extern crate libc;
> 
> pub mod interface;
> mod implementation;
> ```
> 
> And modify tell Cargo to build a static library in `rust/Cargo.tom`:
> 
> ```
> [package]
> name = "rust"
> version = "1.0.0"
> 
> [dependencies]
> libc = "*"
> 
> [lib]
> name = "rust"
> crate-type = ["staticlib"]
> ```
> 
> Next step: put your code in rust/src/implementation.rs:
> 
> ```rust
> use interface::*;
> 
> pub struct Greeting {
> emit: GreetingEmitter,
> }
> 
> impl GreetingTrait for Greeting {
> fn create(emit: GreetingEmitter) -> Greeting {
> Greeting {
> emit: emit,
> }
> }
> fn emit() ->  {
> 
> }
> fn message() ->  {
> "Hello world!"
> }
> }
> 
> ```
> 
> The GreetingEmitter is generated struct that can emit signals such as
> valueChanged(). It is not needed in this simple example, but the interface
> requires it. You might have new values coming in of which you'd need to
> notify the UI.
> 
> The demo has more advanced examples. List and Tree let you implement
> QAbstractItemModel with Rust code but the API is quite different.
> 
> There is no QAbstractItemModel::data and QAbstractItemModel::setData to
> implement. Instead, you define properties for each list or tree item and
> have to implement functions like
> 
> ```rust
> fn name(row: usize) ->  {
> if row == 0 {
> return "Alice";
> }
> "Bob"
> }
> ```
> 
> This project is not a typical C++ KDE project, but I hope it can be part of
> KDE anyway.

3 months passed and this is still in kdereview. Time to move it on or bounce 
it back, to playground or even outside of KDE spheres.

I would like us to accept it though, extragear/sdk seems the best fit.

Before though this should be addressed at least:
https://phabricator.kde.org/D9357 (Some fixes for CMakeLists.txt)
https://phabricator.kde.org/D9458 (Fix i18n message catalog naming, add 
catalog for generator app)

One could also argue about the name of the generator binary, 
"rust_qt_binding_generator" is quite verbose. Perhaps "rqtbindgen", 
"rustqtbindgen" or similar would be following existing naming (cmp. e.g. 
"cbindgen" Rust crate for similar purpose).

Cheers
Friedrich

Recommended modesetting driver for Intel graphic cards (was: Re: liquidshell in kdereview)

[Friedrich W. H. Kossebau]

Am Donnerstag, 16. November 2017, 23:24:52 CET schrieb Ingo Klöcker:
> On Dienstag, 7. November 2017 20:55:57 CET Martin Flöser wrote:
> > Am 2017-11-07 20:08, schrieb Martin Koller:
> > >> Are you aware that KWin uses QtQuick for all its UI elements, such as
> > >> Alt+TAB?
> > > 
> > > I have deactivated the compositor since sadly it simply does not work
> > > on my laptop (the intel graphics driver just freezes the whole
> > > machine).
> > 
> > I did not talk about compositor, I talked about QtQuick! Yes, KWin uses
> > QtQuick for rendering it's UI, that is unrelated to compositing.
> > 
> > Now you mention that your intel graphics driver freezes the whole
> > system. I'm using Intel on all my systems and it's the most used driver
> > out there. We get many, many, many bug reports in KWin about issues.
> > Freezing systems has not been in the list for now something like two
> > years.
> > 
> > Given that I am very certain that you have a hardware issue where people
> > can help you with. Intel GPUs are good enough to run the Plasma session
> > without any negative impact.
> > 
> > So let us help you fix your issues that you can enjoy our work without
> > having to spend time on writing your own shell.
> > 
> > First thing: are you using the xorg-modesettings driver? If not: install
> > it, problems solved. Do not (I repeat) do not use the xorg-intel driver.
> > 
> > For kernel I recommend at least version 4.13 as this comes with the
> > atomic modesettings driver stack enabled by default. If you do not have
> > such a kernel version yet I highly recommend to give it a try.
> 
> Martin, thanks a lot for your advice!
> 
> I've suffered from freezes since I updated my openSUSE 13.2 to Tumbleweed
> some time ago (and much longer on my laptop where I've switched to Leap and
> later Tumbleweed much earlier).

Same here, happy to finally see someone with correlated experience. I never 
got any useful hints in the log files, so was close to consider my hardware 
broken. Strange enough all freezes seemed to happen while moving the mouse 
though, which kept the hope alive it was something software-related.

Curious to see if my daily freeze will now be a thing of the past now that I 
changed the driver. Though I am on a 2nd gen 915 device, while all the 
modesettings driver talk I came across on a quick search seemed to be only 
about gen4 and later? No issues seen for one hour so far, hope grows :)

> The switch to the modesetting driver seems
> to have fixed those issues. It took me some time to find out how to enable
> the modesetting driver. To save others the time here's how to do it: Write
> #=
> Section "Device"
>Identifier  "Intel Graphics"
>Driver  "modesetting"
> EndSection
> #=
> to a file in /etc/X11/xorg.conf.d/, e.g. 50-device.conf. Make sure that this
> is the only (or at least the first) "Device" section in any of the files in
> /etc/X11/xorg.conf.d/.

Another approach seems to be to uninstall xf86-video-intel, that way the 
seemingly hardcoded driver-auto-match logic will skip forward to the 
modesetting driver:

[12.125] (==) Matched intel as autoconfigured driver 0
[12.125] (==) Matched intel as autoconfigured driver 1
[12.125] (==) Matched modesetting as autoconfigured driver 2
[12.125] (==) Matched fbdev as autoconfigured driver 3
[12.125] (==) Matched vesa as autoconfigured driver 4
[12.125] (==) Assigned the driver to the xf86ConfigLayout
[12.125] (II) LoadModule: "intel"
[12.127] (WW) Warning, couldn't open module intel
[12.127] (II) UnloadModule: "intel"
[12.127] (II) Unloading intel
[12.127] (EE) Failed to load module "intel" (module does not exist, 0)
[12.127] (II) LoadModule: "modesetting"
[12.127] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 20:08:59 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 16:42:40 CET Martin Flöser wrote:
> > Am 2017-11-03 21:30, schrieb Martin Koller:
> > I don't mind what you develop in your spare time. Not at all. What I
> > mind is if a product is added to KDE as a competitor/replacement to a
> > product I work on because of misunderstood things. What I see here is
> > that you completely misunderstood what hardware acceleration means and
> > gives to the system.
> 
> See above. I did not start liquidshell because I was bored. Believe me, I
> have other hobbies. I started it just because I got fed up with the
> problems I had with plasmashell and I need to use some DE for my daily
> work. Restarting plasmashell multiple times a day is just not funny.

I think what Martin F. is also asking here, and what surely one expects as 
standard in KDE, is that the description of the liquidshell product/project is 
not making false or unresearched claims or speaking badly about alternative 
solutions, especially from the same community. In short: being respectful :)

So e.g. if this was about some new liquidhexeditor, I as author of Okteta 
would be not happy about phrases like:

* "liquidhexeditor is a replacement for okteta"
"replacement" (to me) comes with meaning of successor, being better. Which is 
attributing things.
The more neutral word "alternative" might be better here.

* "It does not use QtQuick but instead relies on QtWidgets."
"not use X but relies on Y" also tells me that "X" sucks and better is 
avoided.
Where one could rather say "Uses X for everything because property 1, property 
2 and property 3", without losing a word about "Y".  Just listing the factors 
one made their choice on for using "X" leaves everyone with their idea about 
the qualities of "Y".
E.g. it could be said that QWidgets are a stable mature UI technology and 
(like already is sayed) provide a consistent UI across shell and apps (at 
least the QWidget-based apps).
No need to speak here about alternatives like QQ, Gtk, or EFL, there are 
people for any who think that to be a better base to build a UI on.

So Martik K., IMHO the current README carries still some of the frustration 
you had experienced with the Plasma shell. While this has been part of your 
motivation for your work on a new solution, it could be now time to step back 
and to turn completely into positive thinking like most of the README already 
is, for a peaceful, cooperative co-existence :) 

I propose to start the README with the product requirements you had in mind 
when working on liquidshell, perhaps by listing the features already 
implemented (and then listing some which you still consider to add).
With those, potential users might be able to see whether the requirements 
match those they are looking for themselves, and developers might be able to 
follow your decisions on why creating a separate project and on the 
technologies used for the implementation.

BTW, you are surely aware that other UI components of the Plasma workspace, 
like the System Settings, are ported to QtQuick currently. So given your 
implementation choices, do you plan to create a liquidsystemsettings variant 
as well?

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Dienstag, 7. November 2017, 19:27:31 CET schrieb Martin Koller:
> On Dienstag, 7. November 2017 15:32:23 CET Friedrich W. H. Kossebau wrote:
> > BTW, would you like assistance to have liquidshell covered on
> > build.kde.org? Seems it is not there yet.
> 
> Wow - didn't know that this exists.
> Is this just for testing if it compiles or are packages released from there
> ? 

It is for checking building with current state of other KDE software that is 
in the same dependency tree. As well as tracking unit tests results and other 
code quality measurements.

No packages generated there, only automated testing done.

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Am Montag, 6. November 2017, 19:24:51 CET schrieb Martin Koller:
> On Montag, 6. November 2017 17:37:15 CET Friedrich W. H. Kossebau wrote:
> > > light color theme:
> > > http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark 
> > > color
> > > theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png
> > 
> > Please consider using a non-KDE logo on the start menu on representative/
> > advertising screenshots (ideally some new liquidshell logo one, also to
> > help promoting it and building an identity).
> > Given the history meaning of the KDE logo as the logo of a desktop, using
> > the KDE logo will spoil the concerted effort of the rebranding done
> > (whether it was a good idea or not is too late to discuss) and only
> > continue the confusion, for no good.
> > 
> > So with the Plasma workspaces having moved to the Plasma logo, leaving the
> > KDE logo for the community, liquidshell should have and use its own
> > dedicated logo as well. (and yes, the start-here-kde icons would need
> > renaming finally)
> I'm very bad at creating appealing graphics, therefore I used exiting icons
> where possible.
> Is there some KDE artist who is willing to create a new logo for me ?

I recommend to follow https://vdesign.kde.org/how.html and poke the VDG people 
directly with your requirement.

> Regarding the rebranding: does that mean KDE (the people behind the project)
> does not like to promote KDE ?
> Very confusing in my view.
> I really meant to show "that is a KDE (based) application" by using its logo
> - was not clear that this is not welcomed.

Surely we want to promote KDE, the community :) Just, like e.g. apps like 
Okular, Dolphin, Okteta, KDevelop etc. also want to promote KDE, the 
community, they do it via the entry in the Help menu or in the About data. 
Still they have their own logo/icon for showing off e.g. "he, it's me, okular" 
and have their logo/icon displayed as identifier.

The start menu icon here serves a similar purpose usually, it shows "he, its 
me, workspace product X/operating system Y". But not saying "I am done by A", 
especially when A creates different variants of the product type. 

And with the history of "KDE" being once the name of a workspace product, 
using its logo on the start menu like in the formerly named "KDE" product 
could trigger the uninformed people to consider liquidshell being the new 
"KDE". Adding to confusion and wasted resources in fighting those 
misconception.
So better prevent from the start, so our time could be spent in bug fixing 
instead.


BTW, would you like assistance to have liquidshell covered on build.kde.org? 
Seems it is not there yet.

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Some more branding oriented nitpicks:

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:
> - uses existing KDE dialogs for most configurations, e.g. StartMenu, Virtual
> Desktops, Bluetooth, Network

Please consider saying rather "KDE Frameworks dialogs", due to "KDE dialogs" 
being a concept which no longer exists at age of KDE Frameworks and Plasma.

> light color theme:
> http://members.aon.at/m.koller/liquidshell_20171103_174650.png dark  color
> theme: http://members.aon.at/m.koller/liquidshell_20171103_174944.png

Please consider using a non-KDE logo on the start menu on representative/
advertising screenshots (ideally some new liquidshell logo one, also to help 
promoting it and building an identity).
Given the history meaning of the KDE logo as the logo of a desktop, using the 
KDE logo will spoil the concerted effort of the rebranding done (whether it 
was a good idea or not is too late to discuss) and only continue the 
confusion, for no good.

So with the Plasma workspaces having moved to the Plasma logo, leaving the KDE 
logo for the community, liquidshell should have and use its own dedicated logo 
as well. (and yes, the start-here-kde icons would need renaming finally)

Cheers
Friedrich

Re: liquidshell in kdereview

[Friedrich W. H. Kossebau]

Hi Martin,

Am Freitag, 3. November 2017, 21:30:19 CET schrieb Martin Koller:
> I'd like to announce an application I've implemented over the last few weeks
> - liquidshell

Congrats to the achievement. It surely feels good to run a workspace one has 
created one themselves :)

While myself I will choose Plasma over liquidshell due to my needs and 
expectations of certain features, I can see that liquidshell would satisfy 
those persons who need or want just a simple hard-coded shell following a 
well-known UI design & concept, yet stay with the usual tools and apps from 
the KDE software world, ideally perfectly integrated with the workspace (think 
filemanager, terminal, text editor, etc). People like obviously yourself :) So 
those persons might be surely happy about you sharing your work with them.

My hopes for liquidshell as another project under the KDE community umbrella:
* improvements for shared middleware, perhaps even introducing some more
  where it makes sense to share between Plasma, liquidshell & others
  (pushing for more clear UI-core separation, which in theory is for good)
  libtm might be one such thing, the weather data provider system also calls
  for being shared code with Plasma (and e.g. the Marble weather plugin)
* another testing ground for protocols & standards in development
* make more obvious that "KDE" is about a community, not a certain software
* give perhaps remaining trinity desktop developers and other
  Plasma-no-Qt-jay-fans a new center for their goals and as result also new
  contributors for the shared middleware, tools and apps (at least for their
  current QtWidgets UI variant ;) )

Re: gosh, yet another workspace
In a perfect world everybody would join work on the one true golden workspace 
solution, reality is that there is no such one-workspace-which-fits-all. Not 
to forget the mythical person-month issue.

And if people rather go and write their own software instead of joining 
existing projects, it should be the projects asking themselves why they have 
not been attractive enough in the first place.
Telling people instead "you should not do X, but Y" is rather the opposite of 
what Free Software is about. Even when first saying "Your are free, but".

I applaud you, Martin, for managing to solve your needs yourself and for 
sharing the results with the rest of the world, instead of keeping them for 
yourself.
And as KDE community we can feel honored you trust us to be the best place for 
further development of your software, instead of going github or elsewhere.

Re: liquidshell as name
When I read liquidshell I first thought about something very dynamic, highly 
animated. So not sure "liquid" is the best term to use in the name. But then 
we all know naming is hard, good luck with it :)

Cheers
Friedrich

Moving KMarkdownWebView to extragear/utils (was: Re: KMarkdownWebView (kpart) in KDE Review)

[Friedrich W. H. Kossebau]

Hi,

Am Dienstag, 22. August 2017, 00:18:19 CEST schrieb Friedrich W. H. Kossebau:
> 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).

Thanks Elvis, Albert, Allen for your replies, also anyone who gave feedback on 
irc (and those possibly who tested and stayed silent as no issues were hit).

So 14 days will have passed upcoming Tuesday, and seems no showstoppers are 
left for leaving kdereview to become a "normal" repo.

Besides the fixing commits for the things commented on no other bigger changes 
happened since it entered kdereview, cmp. https://cgit.kde.org/
kmarkdownwebview.git/log/ , but you might want to give it a final check.

> I consider it rather a hack and would favour something done natively in Qt
> (e.g. like the Markdown Okular generator in https://phabricator.kde.org/
> D7382). But for now it serves the use-case of providing a webpage-like
> rendered display of markdown documents. Especially for the live preview
> plugin for Kate & KDevelop currently worked on*.
> 
> * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> 
> See also https://cgit.kde.org/kmarkdownwebview.git/about/
> 
> The separate library libKMarkdownWebView is done for sharing code with a
> thumbnailer plugin, whose code yet is to be committed to this repo, as it
> resists to work right now.
> 
> Initial build on CI looks good:
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9
> /
> https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQ
> t5.7/

> 
> Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".

So unless anyone objects, I will ask to have the repo in extragear, in repo 
hierarchy path extragear/utils.

Once it's moved and I pinged the translators, a week later should see first 
release then.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Hi Elvis,

(seems my reply I started last week was somehow lost, pardon for late reply)

Am Dienstag, 22. August 2017, 11:31:00 CEST schrieb Elvis Angelaccio:
> On martedì 22 agosto 2017 00:18:19 CEST, Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > 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 https://phabricator.kde.org/
> > D7382). But for now it serves the use-case of providing a webpage-like
> > rendered display of markdown documents. Especially for the live preview
> > plugin for Kate & KDevelop currently worked on*.
> > 
> > * https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo
> > 
> > See also https://cgit.kde.org/kmarkdownwebview.git/about/
> > 
> > The separate library libKMarkdownWebView is done for sharing code with a
> > thumbnailer plugin, whose code yet is to be committed to this repo, as it
> > resists to work right now.
> > 
> > Initial build on CI looks good:
> > https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5
> > .9/
> > https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBS
> > DQt5.7/
> > 
> > And people on #kde-devel & #kdevelop also reported successful builds and
> > usage.
> > 
> > 
> > Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".
> > 
> > Initial release planned right after leaving kdereview.
> > 
> > Question: is there any appstream metadata possible for plugins?
> 
> Yes, have a look at kio-gdrive or kio-stash as example.

Took that as template, thanks for pointer.

> From a quick look, everything works fine.
> 
> One minor issue I spotted: if I preview a markdown file in some archive,
> the ark preview window has a menu named "No text" instead of "Edit" (with
> the "Select All" action). This could be fixed by adding the
> Edit element in kmarkdownwebviewpartui.rc (not sure if
> there is another fix).

Perhaps the Ark preview window does not load the std xmlgui config, so those 
toplevel menu entry names are missing? I remember I have seen that also with 
other parts.
Fixed for now by the workaround you proposed, an explicit Edit.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 23:38:06 CEST schrieb Friedrich W. H. Kossebau:
> Am Dienstag, 22. August 2017, 22:41:28 CEST schrieb Albert Astals Cid:
> > You don't have a Messages.sh
> 
> Thanks for taking a look, though... there is one, in src/:
> https://cgit.kde.org/kmarkdownwebview.git/tree/src/Message.sh

Seems I am blind to some trailing "s" :) My bad, fixed.

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 23:09:18 CEST schrieb Allen Winter:
> One Krazy issue about making an explicit ctor, see
> http://ebn.kde.org/krazy/reports/kdereview/kmarkdownwebview/src/index.html

Fixed.

> I ran clazy too and it found no issues.

Happy to read. Thanks for having had a look, Allen :)

Cheers
Friedrich

Re: KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Am Dienstag, 22. August 2017, 22:41:28 CEST schrieb Albert Astals Cid:
> You don't have a Messages.sh

Thanks for taking a look, though... there is one, in src/:
https://cgit.kde.org/kmarkdownwebview.git/tree/src/Message.sh

Placement missing to follow some pattern?

For completeness I just pushed added extraction from rc file, though the 
current one has no strings. But a wrong domain still, and will not hurt to be 
prepared for possibly future additions there.

Cheers
Friedrich

KMarkdownWebView (kpart) in KDE Review

[Friedrich W. H. Kossebau]

Hi,

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 https://phabricator.kde.org/
D7382). But for now it serves the use-case of providing a webpage-like 
rendered display of markdown documents. Especially for the live preview 
plugin for Kate & KDevelop currently worked on*.

* https://frinring.wordpress.com/2017/08/21/look-what-you-have-donewwdo

See also https://cgit.kde.org/kmarkdownwebview.git/about/

The separate library libKMarkdownWebView is done for sharing code with a 
thumbnailer plugin, whose code yet is to be committed to this repo, as it 
resists to work right now.

Initial build on CI looks good:
https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20SUSEQt5.9/
https://build.kde.org/job/Extragear%20kmarkdownwebview%20kf5-qt5%20FreeBSDQt5.7/

And people on #kde-devel & #kdevelop also reported successful builds and 
usage.


Target would be extragear/$SOMETHING, with $SOMETHING possibly "utils".

Initial release planned right after leaving kdereview.

Question: is there any appstream metadata possible for plugins?

Cheers
Friedrich

Re: CI Requirements - Lessons Not Learnt?

[Friedrich W. H. Kossebau]

Hi Eike,

first of all, thanks for turning this into a policy creation process :)

Am Donnerstag, 19. Januar 2017, 02:29:00 CET schrieb Eike Hein:
> On 01/17/2017 11:46 PM, Adriaan de Groot wrote:
> > But CI has a really important function: it shows us the health of the
> > sources for everything; and that's something the release team needs, and
> > the whole community can be interested in. So "opting out" of CI deprives
> > us of a good view of the state of our software products.
> 
> Agreed. But under the proposed document, you can essentially only
> opt out by behaving so badly that sysadmin sees no choice but to
> kick you out, and it labels that as "rude". I think it also
> communicates why we care about CI (e.g. as regression catcher).
> 
> This thread has slowed down now - there's been no strong objections
> raised to the current version of the doc. If everyone is happy with
> it, I propose we start linking it from the /Policies/ main page by
> start of February and try to live with it.

Given this is a policy affecting all of the KDE projects, please first propose 
it officially in a separate own thread, with a proper subject. Perhaps even on 
kde-community, as kde-core-devel might not be read by many, given it used to 
be focussed on kdelibs/core apps. Even people reading kde-core-devel might 
have missed it, as this thread here started to become heated and long, so most 
free time contributors might not have invested time into reading more than the 
first.

Some feedback on the policy itself:
"Dependency changes for software covered by the CI system should be submitted 
through code review"
-> I would propose to additionally recommend contacting sysadmin as soon as 
one knows that a new dependency is coming up, not only first at the time the 
official review request is made. That should give sysadmin some more time in 
advance to handle the needed new dependency in CI, and perhaps also give 
feedback on issues. 
Ideally it might even result in the new dependency already being available at 
the time of the review request, so if the review itself is done quickly, CI 
does not block the merge.

IIRC this would also reflect what has been done now and then :)

Cheers
Friedrich

Re: Moved to KDE Review: KProperty

[Friedrich W. H. Kossebau]

Am Dienstag, 11. Oktober 2016, 00:04:12 CEST schrieb Jaroslaw Staniek:
> On 10 October 2016 at 23:58, Albert Astals Cid  wrote:
> > The i18n system is a bit borked, you're using tr and correctly using
> > ecm_create_qm_loader
> > but then the name of the catalog doesn't match
> > kpropertycore_qt vs kproperty_qt.pot
> > 
> > And then you're trying to use
> > 
> >  ki18n_install(po)
> > 
> > that is not how you install qt-only based translations (this is also
> > broken in
> > kdb and kreport).
> > 
> > The clazy report is at https://paste.kde.org/pqqy5twmb
> 
> ​Thanks,
> CCd Friedrich who once helped with porting to tr() (IIRC).
> @Friedrich would be great to get support from you :)

Done for what all that was listed here.

Cheers
Friedrich

TRANSLATION_DOMAIN not to be used for app code (was: Re: announcement: Kwave is in kdereview)

[Friedrich W. H. Kossebau]

Am Sonntag, 9. Oktober 2016, 22:21:56 CEST schrieb Albert Astals Cid:
> El diumenge, 9 d’octubre de 2016, a les 18:05:29 CEST, Friedrich W. H. 
Kossebau va escriure:
> > Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid:
> > > El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David
> > > 
> > > Faure va escriure:
> > > > AFAIK KLocalizedString::setApplicationDomain isn't
> > > 
> > > necessary, you should
> > > 
> > > > instead define the domain as a -D flag during compilation, but
> > > 
> > > I'm no expert
> > > 
> > > > on that, check the wiki.
> > > 
> > > Don't recomend the domain flag for anything that is not a
> > > library, it is a bad idea, several things in applications break if
> > > you do that.
> > 
> > What breaks exactly?
> 
> Anything using KLocalizedString::applicationDomain()
> 
> https://lxr.kde.org/search?_filestring=&_string=KL.*%3AapplicationDoma

The XMLGUI ones though only fallback to that if the rc file has no domain tag 
set, so there one would be safe (unless missing the tag, but that is also 
needed with libs).

But kcheckaccelerators testing and KTipDialog seems to indeed rely on that 
property, was not on my radar, thanks for the info. Guess I simply never used 
them, so did not affect me.

> > (Actually I turned to use the flag also in app code to avoid 3rd-party
> > plugins being able to ruin translations in the app code by wrongly calling
> > KLocalizedString::setApplicationDomain, seen that too often (fixed it of
> > course when seen :) )).
> > 
> > The only price I know of is extra QByteArray creation per each i18n*
> > call...
> > 
> > In any case, everybody reading this, when switching to use
> > KLocalizedString::setApplicationDomain() as intended by the ki18n
> > developers, make sure that all app code is not seeing any
> > TRANSLATION_DOMAIN definition, as otherwise any i18n*() call will use the
> > flag-based variant and thus internally ignore to whatever
> > applicationDomain
> > was set.
> > So e.g. if having lib and app code in one build system, only set
> > TRANSLATION_DOMAIN for the lib code.
> 
> Isn't that obvious?

At least from my own experience and the code from others where I saw related 
issues, all the i18n magic is sadly not always obvious.
Example for definition also existing for app code that I just found:
https://lxr.kde.org/source/kde/pim/kmail/src/CMakeLists.txt
(cc:ed pimsters for heads-up)

*cough* also https://lxr.kde.org/source/kde/kdegraphics/okular/CMakeLists.txt 
*cough*

Cheers
Friedrich

Re: announcement: Kwave is in kdereview

[Friedrich W. H. Kossebau]

Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid:
> El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David
> 
> Faure va escriure:
> > AFAIK KLocalizedString::setApplicationDomain isn't
> 
> necessary, you should
> 
> > instead define the domain as a -D flag during compilation, but
> 
> I'm no expert
> 
> > on that, check the wiki.
> 
> Don't recomend the domain flag for anything that is not a
> library, it is a bad idea, several things in applications break if
> you do that.

What breaks exactly?
(Actually I turned to use the flag also in app code to avoid 3rd-party plugins 
being able to ruin translations in the app code by wrongly calling 
KLocalizedString::setApplicationDomain, seen that too often (fixed it of 
course when seen :) )).

The only price I know of is extra QByteArray creation per each i18n* call...

In any case, everybody reading this, when switching to use 
KLocalizedString::setApplicationDomain() as intended by the ki18n developers, 
make sure that all app code is not seeing any TRANSLATION_DOMAIN definition, 
as otherwise any i18n*() call will use the flag-based variant and thus 
internally ignore to whatever applicationDomain was set.
So e.g. if having lib and app code in one build system, only set 
TRANSLATION_DOMAIN for the lib code.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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. to group QML 
"classes" away from C++ classes), kapidox now would need extension of its 
spec, with semantics needed to talk about QML types and C++ classes to allow 
proper generation of nicely separated pages.

This actually touches a broader problem with the current generated 
documentation, which right now is centric to the C++ interfaces. Though 
existing KDE library products have at least interfaces in
* C++
* QML
* CMake macros [1]
and perhaps one day bindings in Python and other languages would be also 
provided directly with the products and thus it would be great to have their 
documentation covered as well easily.

[1] E.g. KCoreAddon installs a few cmake macros, like 
kcoreaddons_desktop_to_json, which have nice API dox inside, but there is 
nothing generated from that on api.kde.org currently, both bad for 
discoverability or pointing people to things with urls.


For a solution:
Perhaps at the generation side there could be another level right below the 
library, for the interface (C++, QML, CMake, ...).
So "Product" > "Library" > "Interface", 

By the example of Plasma Components 
(https://api.kde.org/frameworks/plasma-framework) there would then be in the 
header
KDE API Reference > The KDE Frameworks > Plasma > QML
KDE API Reference > The KDE Frameworks > Plasma > C++
and in the left sidebar there would be another section "Language" (or better 
term) which would allow to switch to the docs for the other interfaces 
supported (C++, QML, CMake, ...).

On the metainfo.yaml spec side, no idea yet.

Cheers
Friedrich

Re: Usage of QNetworkAccessManager

[Friedrich W. H. Kossebau]

Am Donnerstag, 14. Juli 2016, 12:50:11 CEST schrieb David Faure:
> On jeudi 14 juillet 2016 18:33:37 CEST Ben Cooksley wrote:
> > Please therefore ensure your application handles redirects
> > appropriately (the form of the code will depend on the version of Qt
> > in use) if you decide to use QNAM.
> 
> As an example,
> https://lxr.kde.org/source/playground/sdk/inqlude-client/downloadhandler.cpp
> has working Qt 5 code for this.

Could someone of you with clue about it add some tutorial/guidelines somewhere 
below https://community.kde.org/Guidelines_and_HOWTOs, please?

Cheers
Friedrich

Re: web server for appstream metadata screenshots

[Friedrich W. H. Kossebau]

Am Mittwoch, 8. Juni 2016, 13:10:04 CEST schrieb Sebastian Kügler:
> Hey,
> 
> I've been adding appstream metadata to one of the apps I maintain, among
> that are also screenshots, in the form of a URL. That means that I have to
> put the screenshots on a webserver.
> 
> Do we already have a canonical location for these screenshots? If not, let's
> create one before we get people hosting them on imgur, their private
> webserver or their router-behind-a-dsl-line. :)

Good idea, also when it comes to long-term availability of referenced images 
:)

It might make sense to reuse/share the screenshots with the ones used for the 
KDE app catalog we have at kde.org/applications/. For consistency and for 
efficiency.

Not sure though what a stable url would be like, given people planning to 
rework kde.org (and thus those app catalog pages), so perhaps relying on the 
current screenshot urls used by kde.org/applications is not perfect.

In any case, we need to keep versioning in mind, so that appdata for some 
older version of an app not suddenly gets a screenshot of the latest version 
highlighting features not present in the version the appdata is talking about.

Perhaps there would be some url scheme we can agree on, which then would be 
also used by whatever new KDE app catalog pages there will be on whatever new 
KDE website.

Cheers
Friedrich

Re: Cervisia?

[Friedrich W. H. Kossebau]

Am Sonntag, 5. Juni 2016, 14:22:45 CEST schrieb Nicolás Alvarez:
> > El 5 jun 2016, a las 09:08, Martin Koller  escribió:
> >> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> >> 
> >> Some i18n issues:
> >> 
> >> It is a QApplication so you have to add the translators tab manually with
> >> aboutData.setTranslator
> > 
> > ok. what shall I write there (names, emails ?)
> > 
> > Isn't that a limited approach to name the translators in the sourcecode,
> > since every new translation added will need a source change ?
> 
> No; you use something like i18n("TRANSLATOR NAME") (I don't remember the
> exact string), so that the name comes from the translation itself.

It would be
setTranslator(i18nc("NAME OF TRANSLATORS", "Your names"),
  i18nc("EMAIL OF TRANSLATORS", "Your emails"));

And it needs to be these very strings, as they are here, both comment and 
content, because for those by definition there will be in the catalog 
translation strings which then contain the names of the people who did the 
translations for the given language. Which means, the i18nc call will then 
return the names (and emails) of the translators for the current language, as 
stored in the currently used translation catalog. (So not the names of all the 
translators who translated to any languages, just for the current).
And there will be always such strings with their translation in the 
translation catalog, they do not need to be present in the actual code which 
makes uses of them, and thus do not need to be present in the catalog template 
(pot file).

And as Albert already said in his email, it might not need to be done when 
using KMainWindow (or derived classes like KXmlGuiWindow), as by tradition the 
KMainWindow constructor ensures those strings are set on the global 
KAboutData::applicationData object.

See
https://api.kde.org/frameworks/kcoreaddons/html/
classKAboutData.html#a9a0a3e87cede16d6bb2e96d5bc5e5d4b
for all the details in the API documentation of KAboutData.

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Mittwoch, 27. April 2016, 01:29:06 CEST schrieb Jan Kundrát:
> On Wednesday, 27 April 2016 01:21:22 CEST, Albert Astals Cid wrote:
> > No, Qt5 is not built with ASAN on CI.

Okay, good to know.
(next to the failing tests I also remembered to have seen ASAN_OPTIONS 
detect_leaks=0 as env setting with the qt5 builds on CI. So that is just 
default env setup and those vars ignored otherwise, okay).

Next to documenting things, can we start with some rule what gets or should be 
built with ASAN, so people know what to expect?
I would assume: any KDE software based on C++/C. And then there might be a few 
exceptions, for whatever reasons (built screwed, incompatible, etc).

> > It is strange that your Qt5-only tests are failing, may it be that they
> > are
> > loading some plugin that is linked against some KF5 lib?

For Marble plugins only if something is not like it should be:
for one, the current build on CI even gets "-DQTONLY=TRUE" passed, which is 
turned into the cmake var "set(WITH_KF5 FALSE)", and all KF5 deps are looked 
for with "macro_optional_find_package(KF5 QUIET COMPONENTS something)", so 
should always yield NOT_FOUND (looking at it I found a bug which still made 
KF5DocTools to be found, but now fixed and should not have any effect on 
linking to KF5 libs).
More, the only things being explicitely linked to KF5 libs are KF5 thumbnailer 
plugin, KRunner plugin, and the KF5-enhanced Marble app variant. So nothing 
which should be used in the tests.

Ah, Phonon! That is linked by at least the RoutingPlugin. And Phonon gets 
instrumented with ASAN:
https://build.kde.org/job/phonon%20master%20kf5-qt5/
PLATFORM=Linux,compiler=gcc/5/console

That might explain what we see currently.

> Qt guesses what platform one is running on in order to blend with it. In
> KDE and under the Plasma desktop, this involves loading
> plugins/platformthemes/KDEPlatformTheme.so which belongs to KF5's
> frameworkintegration.
> 
> Is the KDE CI setting some variables which might trigger loading of these
> plugins [edited]?

Good idea, that might be indeed other intrusion path for ASAN deps.
@Scarlett, can you tell?

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Dienstag, 26. April 2016, 23:21:40 CEST schrieb Albert Astals Cid:
> El dimarts, 26 d’abril de 2016, a les 18:50:55 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> > > El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> > > Kossebau
> > > 
> > > va escriure:

> > > > So do any projects which are build on KDE CI need to have
> > > > ECMEnableSanitizers.cmake included?
> > > > 
> > > > Would it make sense to have ASan as an option to be turned off?
> > > 
> > > It's compile time, it's off for your project, but you're linking against
> > > KF5 libraries that have ASAN compiled in.
> > > 
> > > > And is that possible, or is ASan usage viral (if deps built on CI have
> > > > it,
> > > > it needs to be used)?
> > > 
> > > Yes ASan usage is viral-ish, if you're using a library that was compiled
> > > with ASAN you either need to compile your binary with asan too or pass
> > > the
> > > LD_PRELOAD as the error says, that may be tricky since it needs a full
> > > path.
> > 
> > Given we have stable setting on CI, the path might be known perhaps.
> > 
> > What needs to be done with LD_PRELOAD here exactly? Perhaps that could be
> > done optionally based on a flag in the build setup in the future.
> 
> You set it to the asan library before running your binary.

Okay, that sounds doable. "Just" needs someone to add support for that :)
Filed a feature request on phabricator for that, anyone interested to earn 
some laurels on that?
https://phabricator.kde.org/T2366

> > Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based
> > buildsystem) for any projects on KDE CI to have tests being run properly
> > (if using other KDE CI products) feels like a small obstacle.
> > If possible without too much pain, it might be nice to avoid that.
> 
> It's hard to avoid unless you compile all libraries twice both with and
> without ASAN.

Double builds ideally can be avoided. And after all ASAN is very much useful 
on CI, that's why you(?) pushed it there, for some good catches already 
(myself could also harvest some bugs from it already) :)

> It is not a requirement for "any projects on KDE CI".
> 
> As pointed you can just LD_PRELOAD the ASAN library if you have troubles.
> Also that is only needed if you use other projects that are linked against
> ASAN.

As I understood it so far, almost anything built on KDE CI is built with ASAN, 
incl. 3rd-party dependencies like Qt5, no? As said above, it only makes sense 
to me to do it. But we need to also have support for the non-ECM-using 
projects, that's what I am here for and try to understand how things are done, 
to see what could be done.

> That is, you're trying not to use ECM (or ECMEnableSanitizers.cmake) but you
> depend on KF5 stuff that depends on ECM/ECMEnableSanitizers.cmake, maybe
> you're trying to be too fine in not needing ECM.

While I personally would also see to use ECM & CMake where possible, we still 
need to consider at least:

a) KF5 products do not require CMake as the buildsystem for any of its 
consumers. There is extra dance for supporting qmake/pkg-config buildsystems 
at least. So other potential KDE projects which use KF5 but not CMake cannot 
use ECM. Ideally there would be similar helpers like ECMEnableSanitizers.cmake 
one day for them, sure, but those still would be extra dependencies, and any 
extra dependency increases burdens, so would be nice to have it special 
settings for KDE CI optional if possible without a big deal.

b) Qt5 on CI is also build with ASAN (AFAIK, that is why the all Marble tests, 
which are Qt5-only, are failing, unless I missed something). So Qt5-only 
projects (as in: ECM/KF5-less) still would need to have separate support by/
for the KDE CI.

Cheers
Friedrich

Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?

[Friedrich W. H. Kossebau]

Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Hi,
> > 
> > can anyone shed full light on KDE CI and the usage of ASan?
> > 
> > Currently e.g. all tests of Marble are failing, with the message
> > "ASan runtime does not come first in initial library list; you should
> > either link runtime to your application or manually preload it with
> > LD_PRELOAD."
> > 
> > https://build.kde.org/job/marble%20master%20kf5-qt5/
> > PLATFORM=Linux,compiler=gcc/26/testReport/
> > 
> > As Marble tries to be optionally Qt-only by tradition, also the current
> > Qt5(/ KF5)-based version has lots of custom CMake logic, for full
> > independence, and only falls back to using ECM macros/settings when it
> > comes to Plasma & other KDE system integration code.
> > 
> > Which currently also means all tests are not influenced anywhere by ECM
> > macros. Incl. KDECompilerSettings.cmake (and thus
> > ECMEnableSanitizers.cmake). So the code from ECMEnableSanitizers.cmake
> > which handles the
> > "ECM_ENABLE_SANITIZERS" cmake argument is never run.
> > 
> > Where currently -DECM_ENABLE_SANITIZERS='address' seems to be passed in
> > the
> > kf5-qt5 configuration:
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=blob=build
> > %2Fkf5-qt5.cfg
> > 
> > Is this the reason that all the Marble tests fail on KDE CI, with the
> > given
> > error?
> > 
> > So do any projects which are build on KDE CI need to have
> > ECMEnableSanitizers.cmake included?
> > 
> > Would it make sense to have ASan as an option to be turned off?
> 
> It's compile time, it's off for your project, but you're linking against KF5
> libraries that have ASAN compiled in.
> 
> > And is that possible, or is ASan usage viral (if deps built on CI have it,
> > it needs to be used)?
> 
> Yes ASan usage is viral-ish, if you're using a library that was compiled
> with ASAN you either need to compile your binary with asan too or pass the
> LD_PRELOAD as the error says, that may be tricky since it needs a full
> path.

Given we have stable setting on CI, the path might be known perhaps.

What needs to be done with LD_PRELOAD here exactly? Perhaps that could be done 
optionally based on a flag in the build setup in the future.

Requiring ECMEnableSanitizers.cmake (or equivalent for non-cmake-based 
buildsystem) for any projects on KDE CI to have tests being run properly (if 
using other KDE CI products) feels like a small obstacle.
If possible without too much pain, it might be nice to avoid that.

(For Marble nevertheless I have a patch up for review to optionally use 
ECMEnableSanitizers.cmake)

Cheers
Friedrich

Moving CI server documentation to community.ko? (was: Re: KDE CI enforcing ECMEnableSanitizers.cmake/KDECompilerSettings.cmake?)

[Friedrich W. H. Kossebau]

Am Montag, 25. April 2016, 23:26:45 CEST schrieb Albert Astals Cid:
> El dilluns, 25 d’abril de 2016, a les 10:59:13 CEST, Friedrich W. H.
> Kossebau
> va escriure:
> > Hi,
> > 
> > can anyone shed full light on KDE CI and the usage of ASan?
> > 
> > Currently e.g. all tests of Marble are failing, with the message
> > "ASan runtime does not come first in initial library list; you should
> > either link runtime to your application or manually preload it with
> > LD_PRELOAD."
> > 
> > https://build.kde.org/job/marble%20master%20kf5-qt5/
> > PLATFORM=Linux,compiler=gcc/26/testReport/
> > 
> > As Marble tries to be optionally Qt-only by tradition, also the current
> > Qt5(/ KF5)-based version has lots of custom CMake logic, for full
> > independence, and only falls back to using ECM macros/settings when it
> > comes to Plasma & other KDE system integration code.
> > 
> > Which currently also means all tests are not influenced anywhere by ECM
> > macros. Incl. KDECompilerSettings.cmake (and thus
> > ECMEnableSanitizers.cmake). So the code from ECMEnableSanitizers.cmake
> > which handles the
> > "ECM_ENABLE_SANITIZERS" cmake argument is never run.
> > 
> > Where currently -DECM_ENABLE_SANITIZERS='address' seems to be passed in
> > the
> > kf5-qt5 configuration:
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=blob=build
> > %2Fkf5-qt5.cfg
> > 
> > Is this the reason that all the Marble tests fail on KDE CI, with the
> > given
> > error?
> > 
> > So do any projects which are build on KDE CI need to have
> > ECMEnableSanitizers.cmake included?
> > 
> > Would it make sense to have ASan as an option to be turned off?
> 
> It's compile time, it's off for your project, but you're linking against KF5
> libraries that have ASAN compiled in.
> 
> > And is that possible, or is ASan usage viral (if deps built on CI have it,
> > it needs to be used)?
> 
> Yes ASan usage is viral-ish, if you're using a library that was compiled
> with ASAN you either need to compile your binary with asan too or pass the
> LD_PRELOAD as the error says, that may be tricky since it needs a full
> path.
> > While using ASan seems to be useful for improved test coverage, this
> > requirement still would need to be explained and documented somewhere,
> > please.
> 
> Where would you document it?

Right now AFAIK the only documentation about CI is at https://
sysadmin.kde.org/services/continuous-integration/

Though perhaps it makes sense to move that over to somewhere below https://
community.kde.org/Infrastructure, both to improve finding it and
to lower the burden for non-sysadmin people to maintain the pages (possibly 
still need higher edit restrictions to minimize wrong information there).

Sysadmin & else, what do you think?

Cheers
Friedrich

Re: State of Proposal to improving KDE Software Repository Organization?

[Friedrich W. H. Kossebau]

Am Dienstag, 19. Januar 2016, 13:57:10 schrieb Ben Cooksley:
> On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
> 
> <kosse...@kde.org> wrote:
> > 4 months ago there was the thread "Proposal to improving KDE Software
> > Repository Organization" on this mailinglist.
> > What happened to that plan? Are people preparing its execution?
> 
> That plan is tied up in other things taking priority / lack of time / etc.
> We'll get there eventually. It is also in part related to the Phabricator
> move.

Okay, so still work in progress. Good.

> > And would that be a time where some bigger reorganization of the repos is
> > possible?
> > 
> > Reason that I ask is that due to the split of Calligra into several repos
> > (see background^) the layout in the repo structure does no longer
> > properly reflect the project organisation. Right now there are three
> > active repos in the calligra/ repo substructure:
> > "calligra" at "calligra/"
> > "krita"at "calligra/krita"
> > "kexi" at "calligra/kexi"
> > 
> > (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
> > to mpyne about if moving it to "calligra/calligra" should fix it.))
> 
> Repositories within repositories is a known bad thing to do, the
> systems don't handle it properly at all (as it was never an intended
> thing you should do). The proper fix is to move the repo to
> calligra/calligra (ie. have a "calligra/" top level grouping project).

This move is now requested on https://phabricator.kde.org/T1337 , the 
respective kde-build-metadata change locally prepared.

> > Things that are not properly matching organization:
> > * Krita starting with 3.* no longer is part of Calligra project
> > 
> >   (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
> >   what people think to which project Krita belongs)
> > 
> > * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
> > 
> >   so no reason to be in a complete own toplevel structure,
> >   rather should be in the same sub structure, i.e. "Extragear",
> >   like extragear/calligra/* and extragear/graphics/krita
> 
> In the Phabricator world I had envisioned Extragear as no longer existing.

Okay, sounds good.

> > More, not only Calligra & Krita related:
> > * "Extragear" is an awful grouping name for apps with individual
> > 
> >   release plans, a legacy term that no longer fits most of the apps
> >   in that substructure
> > 
> > * "KDE Applications" is a misleading grouping name for apps with a
> > 
> >   central release plan, as if those with individual release plans
> >   are not "KDE" applications (as in, not done in the KDE community)
> > 
> > * a single category per app as needed by the current tree structure layout
> > 
> >   of the repos, like "office", "graphics", "utils", is rather awkward,
> >   many apps do not match exactly one or would match multiple categories
> 
> Phabricator will allow multiple "categories" to be tagged to a repository...

Nice, sounds even better.

> > So IMHO some update of the repository organisation would be good, to
> > reflect how things are these days.
> > Renaming of "Extragear" and "KDE Applications" is surely something which
> > needs care from promo/marketing/VDG people first to find if that makes
> > sense at all and what a good solution would be.
> 
> Extragear is really an internal structure, not part of marketing so I
> think we can go ahead and just kill it...

Seems we all pull on the same string then, glad to see that :)

> > (Being both maintainer of Okteta, which is in "KDE Applications", and
> > meta-co- maintainer of Calligra, which is not, but still done in the very
> > same KDE community, that current naming seems so wrong to me).
> > 
> > But the actual names and grouping aside, for the pure technical renewing
> > (which also involves all infrastructure like translation system,
> > documentation, phabricator, etc), who is currently planning or working on
> > what?
> 
> Like most things in this department, Sysadmin...

So in good hands, I leave it there :P Nah, ready to also do some share of work 
on this, as I would like this itch scratched as well. Please call me where you 
see fit.

> > So does it makes sense to wait some more, or should we assume the current
> > organization stays for longer, and Calligra & Krita repos should be moved
> &