Re: libksane, KSaneCore and QT_NO_KEYWORDS

[Ahmad Samir]

On 29/9/22 10:22, Tobias Leupold wrote:

Hi all!

I recently had to port Scandoc from libksane to KSaneCore, and now, I have
questions ;-)

Question 1:

On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an
Artix machine I run, there's only 22.08.1 (those guys are even more bleeding
edge than Gentoo ...). I could not link against libksane 22.08.1 anymore
there. I knew that there was effort going on to create a separate library only
containing the SANE communication backend, without the QWidgets dependencies.
This is of course a reasonable thing to do -- but if I get this correctly,
libksane itself now depends on KSaneCore, and one can't link against it as
before.

So what's the rationale behind still releasing libksane, when it can't be used
anymore, and one has to port one's code to KSaneCore anyway?

Apart from that:

The KSaneCore API docs say that one should use "target_link_libraries(yourapp
KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't
work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it
work. Am I missing something, or should either the documentation be changed
and/or the "KF5::SaneCore" target be added/defined?

Question 2:

KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my
CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to
figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now
set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and
"Q_EMIT" instead of "signals", "slots" and "emit".

I know that defining these keywords is argued about, as it "pollutes" the
global namespace. But afaik, the only scenario where one has to define "-
DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so
seems to be reasonable when coding the frameworks (as Qt add-ons) to leave
this up to the user. But what's the rationale or benefit of doing so by
default for applications?



Switching to Q_EMIT was done in KF because "emit" is going to be used by the 
STL in C++20 and later:
https://lists.qt-project.org/pipermail/development/2020-February/038812.html
https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit


Thanks for all clarification and/or explanation!

Cheers, Tobias




Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature

Re: New releases for bugfixes

[Ahmad Samir]

On 8/9/22 13:51, Nicolas Fella wrote:

Hi,

I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that maintainers can use as a reference when
making decisions. That would match very well how decisions and policies
are made in KDE.

Cheers

Nico



As I said somewhere else in this thread, any fixes should be backported to the stable branch/tag in 
git (that is most likely the current work flow for the release teams).


From the git-archive manual page:

«git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In 
the first case the current time is used as the modification time of each file in the archive. In the 
latter case the commit time as recorded in the referenced commit object is used instead. 
Additionally the commit ID is stored in a global extended pax header if the tar format is used; it 
can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.»


so:
- backport fix to the stable branch
- packagers can look at that branch to find what extra commits their downstream 
packages don't have yet

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature

Re: Notice of impending change to Gitlab CI

[Ahmad Samir]

On 4/9/22 10:42, Ben Cooksley wrote:

Hi all,

Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run
their respective jobs as root within the Docker containers that Gitlab
spawns for them.

This is a restriction that was previously required by the simultaneous use
of these same images by Jenkins, which following the shutdown of
build.kde.org this weekend is no longer a problem.

I will look into making this adjustment to our CI image(s) in the coming
week for Linux (SUSE). Once implemented, tests which made use of root
privileges may begin to fail (and those that were incompatible with it will
begin to pass).

Android Qt 5 builds still share the image with the Binary Factory and
therefore will have to continue to run as root at this time until we are
able to discontinue the BInary Factory (or at least, Android's use of it).

Thanks,
Ben



Good work!

This is especially good news for KIO (and possibly other frameworks with unittests that make heavy 
use of I/O operations).


Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature

Re: Incubating app (Git Klient)

[Ahmad Samir]

On 22/8/22 18:10, samuel ammonius wrote:

Sorry. I was just trying to help.

What would the right action be?



That would be following the steps at https://community.kde.org/Incubator

(Which what Hamed Masafi appears to be doing, first step is posting to this ML).

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature

[Heads-up] ECM 5.96 KDECompilerSettings will add -Werror=undef to GCC/Clang build flags

[Ahmad Samir]

This[1] should catch undefined preprocessor expressions, i.e. instead of
showing a warning if FOO_BAR_H is undefined:
 #if FOO_BAR_H

make the build fail with an error instead.

This combined with using #cmakedefine01 (instead of #cmakedefine), could
catch things like:
https://invent.kde.org/pim/kdepim-runtime/-/commit/05a0e5bbfbb06ed6aa88640f25f563cf7e5b1330


[1]https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/25bbb2a4776d36b542857709bb0448a7ea030b59

Regards
Ahmad Samir

Re: KF 5.95-rc1 delayed

[Ahmad Samir]

On 5/6/22 21:26, Ahmad Samir wrote:
[...]


Could be an issue due to change in 
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/178
KNewStuff header install locations:
https://invent.kde.org/utilities/yakuake/-/merge_requests/61
https://invent.kde.org/games/ksirk/-/merge_requests/9




KnewStuff issue was solved by backporting the fixes to yakuake and ksirk in 
release/22.04.

--
Ahmad Samir

Re: KF 5.95-rc1 delayed

[Ahmad Samir]

On 5/6/22 20:57, Nicolas Fella wrote:

On 6/5/22 20:53, David Faure wrote:

Hi everyone,

I'm delaying the tagging of KF 5.95 rc1 until:

- the regression in kirigami is fixed
https://invent.kde.org/frameworks/kirigami/-/merge_requests/548#note_462793

- the regression in kio (trash) is fixed
https://invent.kde.org/frameworks/kio/-/merge_requests/854

Please let me know if there are other blocker issues.


Hi,

while we're at it we might also add
https://bugs.kde.org/show_bug.cgi?id=454635 to the list of blockers.

The relevant change that caused it is from plasma-framework:
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/500

Cheers

Nico



Could be an issue due to change in 
https://invent.kde.org/frameworks/knewstuff/-/merge_requests/178
KNewStuff header install locations:
https://invent.kde.org/utilities/yakuake/-/merge_requests/61
https://invent.kde.org/games/ksirk/-/merge_requests/9


--
Ahmad Samir

5.94 respin request: Commit fixing bug in KFileWidget

[Ahmad Samir]

Due to a (my) previous refactoring in KFileWidget the "show full path" action in KUrlNavigator 
didn't work any more.


https://invent.kde.org/frameworks/kio/-/commit/f2ef14ad1be7e9c87c3a21569ff94a99cd5d4c93

Thanks,

Ahmad Samir

Re: The KIPI fate

[Ahmad Samir]

On 16/4/22 18:11, Tobias Leupold wrote:

Hi all,

I'm just the small junior dev here, with surely no authority to decide
anything.

But don't do that. That will make a lot of people stop using our software. I'm
pretty sure about that. Either, we create a surveillance state or, in the best
case, it's just plain annoying (would you like to collect and submit telemetry
data? -- No).

Do we really want to shift in this direction?! Please someone say no.

At least for the projects I created or work on, I want my user feedback via
IRC, mailing lists, bug reports, feature requests or whatever. But not via
data collected by my applications and sent to some central server.

Cheers, Tobias



FWIW, the KDE telemetry policy can be found at 
https://community.kde.org/Policies/Telemetry_Policy

It's _always_ opt-in, i.e. the user has to explicitly enable it if he/she chooses so. also any such 
changes, to add kuserfeedback support, in KDE software are required to go through code review ...etc.


It's just like any other software that has an option to collect anonymous data for the sake of 
improving the software, not for tracking users.




Am Samstag, 16. April 2022, 17:09:39 CEST schrieb o lu:

On 4/15/22 07:42, Harald Sitter wrote:

Going off on a tangent:
I think you are hitting on a very important point. No matter what
happens with kipi here, we should add userfeedback support for
features that we'd like to remove and get a sense of the users the
removal impacts. Right now we have no metrics, so all we are left with
is removing stuff and see how many people complain and possibly
backpedaling after the fact. That is not ideal.

HS


I used to be *completely* against telemetry of any sort until I saw an
article a couple of weeks ago that explained a use case in Firefox: they
were able to make a "heat map" of where users click in the toolbar to
see which buttons were being pressed and with what frequency.  So I
think that all KDE applications should have a (configurable and
inspectable) telemetry option to let developers know exactly which
features are being used and how much.  This would solve (at least in
part) the problem described above.








--
Ahmad Samir

Re: RFC: Frameworks headers install location

[Ahmad Samir]

On 12/4/22 02:17, Aleix Pol wrote:

Back when we did KF5, what we tried to do was mainly to make sure kde4
code still compiled after the big split.

I think that stanradrising how they're placed within submodules of
include/KF6 is a good idea.

The fact that headers from some repositories can be included using the
project name is more an artifact of time than a feature. Those that
are meant to be used that way (e.g. Plasma or Purpose), are already
namespaced within "include/KF*/".

Ensuring that no KF6 project brings "include/KF6" as its include
directories will be a useful cleanup.
Aleix



Thanks for the feedback.

We discussed that again in the previous KF6 meeting[1], and since there are no objections so far, 
we'll go ahead and put that into motion, starting with[2].


[1] 
https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/3#note_431116
[2] https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/305

Thanks,
Ahmad Samir


On Tue, Apr 5, 2022 at 4:19 PM Ahmad Samir  wrote:


Hello.

- In KF5, ECM, magically, added /usr/include/KF5/ to the CMake targets 
interface include directories
(IIUC for reasons of backwards compatibility, which was necessary in the 4-5 
transition era, I could
be wrong because I wasn't around at that time :))

- While building KF against Qt6, this suddenly broke building in some modules 
due to #include
directives not finding the headers, as /usr/include/KF6/ didn't have the same 
magic-injection
treatment as KF5

- To fix the issue, proper paths had to be added to targets interface include 
directories so that
module A linking against module B will have the proper include paths to search 
for headers

- The typical include dir layout for a KF module is:
/usr/include/KF*/ModuleName/{ForwardingHeaderA,headera.h}

e.g. KCMutils, #include , and /usr/include/KF5/KCMUtils added to 
KCMutils target
include dirs.

- If there is a namespace, the original plan was to guard the include paths, by 
making them match
the C++ namespaces, e.g.:
/usr/include/KF*/ModuleName/NameSpace/ForwardingHeaderA
/usr/include/KF*/ModuleName/namespace/headera.h

e.g. KSynatxHighlighting:
/usr/include/KF*/KSyntaxHighlighting/
/usr/include/KF*/KSyntaxHighlighting/KSyntaxHighlighting/Repository
/usr/include/KF*/KSyntaxHighlighting/ksyntaxhighlighting/repository.h


There are some issues with the namespace use-case:
- On case-insensitive and/or case-preserving filesystems (which still exist in 
2022...) extra care
has to be taken so that installation actually works, as you can't have two dirs 
in the same path
with the same name but different cases
- Compiler warnings when using e.g. #include  
if the dir that was
installed first was ksyntaxhighlighting, and all files ended up there (and 
vice-versa, e.g. if the
CamelCase dir got installed first #include  
would give a warning)
- A more complicated layout

The proposal is to change the layout when there is a namespace:
- Only have one dir, /usr/include/KF*/ModuleName/NameSpace/, where all headers 
(ForwadingHeaders and
lowercase.h ones) are installed


Pros:
- less complicated layout/setup (simpler CMake code)
- all KDE namespaces are CamelCase, we don't have any that are lower case
- we promote/encourage using FowardingHeaders everywhere; that's what we use in 
our own code and
what the API docs advise to use

Cons:
- The case not matching when using , but as I 
said above the
argument for this is mitigated by the fact that all our namespaces are CamelCase

If we agree with that change this will be for KF6 so as not to break source 
compatibility for KF5.

Best regards,
Ahmad Samir

RFC: Frameworks headers install location

[Ahmad Samir]

Hello.

- In KF5, ECM, magically, added /usr/include/KF5/ to the CMake targets interface include directories 
(IIUC for reasons of backwards compatibility, which was necessary in the 4-5 transition era, I could 
be wrong because I wasn't around at that time :))


- While building KF against Qt6, this suddenly broke building in some modules due to #include 
directives not finding the headers, as /usr/include/KF6/ didn't have the same magic-injection 
treatment as KF5


- To fix the issue, proper paths had to be added to targets interface include directories so that 
module A linking against module B will have the proper include paths to search for headers


- The typical include dir layout for a KF module is:
/usr/include/KF*/ModuleName/{ForwardingHeaderA,headera.h}

e.g. KCMutils, #include , and /usr/include/KF5/KCMUtils added to KCMutils target 
include dirs.


- If there is a namespace, the original plan was to guard the include paths, by making them match 
the C++ namespaces, e.g.:

/usr/include/KF*/ModuleName/NameSpace/ForwardingHeaderA
/usr/include/KF*/ModuleName/namespace/headera.h

e.g. KSynatxHighlighting:
/usr/include/KF*/KSyntaxHighlighting/
/usr/include/KF*/KSyntaxHighlighting/KSyntaxHighlighting/Repository
/usr/include/KF*/KSyntaxHighlighting/ksyntaxhighlighting/repository.h


There are some issues with the namespace use-case:
- On case-insensitive and/or case-preserving filesystems (which still exist in 2022...) extra care 
has to be taken so that installation actually works, as you can't have two dirs in the same path 
with the same name but different cases
- Compiler warnings when using e.g. #include  if the dir that was 
installed first was ksyntaxhighlighting, and all files ended up there (and vice-versa, e.g. if the 
CamelCase dir got installed first #include  would give a warning)

- A more complicated layout

The proposal is to change the layout when there is a namespace:
- Only have one dir, /usr/include/KF*/ModuleName/NameSpace/, where all headers (ForwadingHeaders and 
lowercase.h ones) are installed



Pros:
- less complicated layout/setup (simpler CMake code)
- all KDE namespaces are CamelCase, we don't have any that are lower case
- we promote/encourage using FowardingHeaders everywhere; that's what we use in our own code and 
what the API docs advise to use


Cons:
- The case not matching when using , but as I said above the 
argument for this is mitigated by the fact that all our namespaces are CamelCase


If we agree with that change this will be for KF6 so as not to break source 
compatibility for KF5.

Best regards,
Ahmad Samir

KIdleTime commit fixing crash

[Ahmad Samir]

Hello.

Please include:

https://invent.kde.org/frameworks/kidletime/-/commit/cd5040684723b87c7ba5b7cc1b1a63402902a641

in 5.93.

Thanks,
Ahmad Samir

Re: Submitting KTextTemplate for KF6

[Ahmad Samir]

On 20/2/22 17:02, Stephen Kelly wrote:


Hello,

The Qt 5 based Grantlee libraries were depended on by some KDE applications.

For Qt 6, I've created a separate repo for KTextTemplate for one of the
Grantlee libraries. The other library is separate and can be dealt with
separately.

Currently the code lives here:

https://github.com/steveire/ktexttemplate

I'd like to get the process moving on getting this reviewed and into KF6.

It's not clear to me what the next step is. I tried googling terms like
"how to submit a library to kde frameworks", but didn't find anything
useful.

https://techbase.kde.org/KDE_Frameworks describes how to build
frameworks, but not how to submit a new one.

I've checked and I can still use invent.kde.org, so it would be good if
there is a standard process I can follow for the rest.

Thanks,

Stephen.




Not a documented procedure, but an example of submitting a new Framework:
https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html

The relevant Grantlee task on the KF6 workboard: 
https://phabricator.kde.org/T14887


Best regards
Ahmad Samir

Re: Gitlab Bugzilla integration

[Ahmad Samir]

On 8/1/22 09:40, Ben Cooksley wrote:

Hi all,

This afternoon work has been completed to better link Gitlab with Bugzilla,
allowing people to get from Gitlab more quickly to Bugzilla and also
enabling us to link CCBUG/BUG references in commits, issues and merge
requests from Gitlab over to Bugzilla.

This functionality can be seen in action on
https://invent.kde.org/graphics/digikam/-/commit/7ca7bf03b11ae72842006af8a66ed02894a4a605
(note that content posted prior to this being enabled may not feature links
due to caching in Gitlab)

This integration does not change in any way the use of Gitlab Issues, which
continue to remain intended for contributor collaboration and project
planning.

Use of this functionality requires the setup of some metadata within
sysadmin/repo-metadata which a number of projects have already completed.
Once added it will be synced to Gitlab overnight and will become available
the next day.

Thanks,
Ben Cooksley
KDE Sysadmin



Good work. That should come in handy. :-)

Thanks!

--
Ahmad Samir

Re: KF6 meeting notes 2022-01-04

[Ahmad Samir]

On 4/1/22 19:07, Volker Krause wrote:

https://phabricator.kde.org/T15127 (Qt6 build status update):
- 60+ modules build
- Kate (without plugins) with Breeze style and platform file dialogs mostly
working
- Kirigami might not be doable without branching (Button.icon,
QtGraphicalEffects)
- CI setup in progress
- in some places includes with the framework prefix don't seem to work anymore
(ie.  vs ), any idea where those extra include
directories came from/got lost?

https://invent.kde.org/frameworks/kwallet/-/merge_requests/22
- was launching kwalletmanager via deprecated KService API
- KIO::ApplicationLaunchJob becomes possible after a QtKeyChain migration of
KIO > - QProcess as temporary porting scaffolding is an option, but how to 
ensure
this doesn't stay around for KF6?
- make this conditional on KF version < 6.0? needs to fail hard when disabled,
not silently drop code for the release



Actually on second thought, David F's plan is to move (at least some of) the classes from kiogui to 
KService, that includes ApplicationLauncherJob and CommandLauncherJob, so it can be fixed by using 
those from KService in KF6.



https://invent.kde.org/frameworks/kio/-/merge_requests/677
- same solution might be applicable here

Timeline
- KF6 branching is not too far away given the current speed
- so we'll need to discuss whether that already makes sense, or whether there
are hard KF blockers to sort out first, and whether that's too fast for apps/
Plasma and we need to help those catch up first
- full branching vs. only branch some modules

https://phabricator.kde.org/T14316 - QtKeyChain porting
- David E found a lot of problems for porting
- QtKeyChain doesn't support KWallet's concept of two folders - might be a
problem limited to Plasma/KF users, applications use their own top-level entry
- use a separator char in the key name for implementing backward compatible
two-level lookup in KWallet

https://phabricator.kde.org/T15140
- "using namespace" in a public header isn't a good idea
- check if typedef aliases are an option for this instead

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/214
- ready to be merged

KDeclarative
- its KCM module contains generic code used outside of KCM context as well,
like the GridView
- Because we want to split up KDeclarative, it is probably better placed in
kirigami-addons, but we finally need to get that into KF and released.
- KCM specific QML files should be moved to KCMUtils

https://phabricator.kde.org/T13970
- can be closed

Topics to discuss in a slightly larger scope:
- solution for the QTextCodec problem
- determine hard KF6 blocker tasks



--
Ahmad Samir

KF6 meeting notes

[Ahmad Samir]

Due to only a few making it to the meeting, we didn't discuss any major tasks.

An open question, are we going to have a meeting next week? What with Christmas 
and all?

Regards,
Ahmad Samir

Re: State of server-side retrace of KDE crashes?

[Ahmad Samir]

On 19/12/21 20:26, Antonio Rojas wrote:

El domingo, 19 de diciembre de 2021 17:27:52 (CET), Kevin Kofler escribió:


PS: Those major distributions have had this sorted out for a couple years
already. I really do not understand why it is such a problem
for Arch to get
this working. The current situation is a pain for everyone. I cannot
reasonably do any debugging on my PinePhone running Manjaro ARM. Even the
limited debugging support in the form of prebuilt rebuilds of GTK and Qt
with debugging information is available only for x86_64.


Because, unlike those other "major distributions", Arch infrastructure and
packaging work relies entirely on volunteers in their free time. And the
commercially-oriented derivatives that take advantage of this work (such as
the one you mention) do not ever contribute back.



As usual, "open-source, if you want something done, do it yourself, or send 
patches."

Regards,
Ahmad Samir

Re: Merge stable to master vs cherry-picking

[Ahmad Samir]

On 9/12/21 12:08, Ben Cooksley wrote:

On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau 
wrote:


Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:

This is why I have been pushing for people to use @stable in their
.kde-ci.yml files - even for the 'master' branch.
It is much simpler for people if you can use stable/released dependencies
when conducting development.


Other than developers the CI though has no issues building all the deps
from
the master branches, right? So I wonder about the relationship here.



The relationship is that developers may accidentally end up using new API
or other functionality that only exists in current master.
That prevents people from using distribution packagers to develop on our
software, and increases the barrier to entry.




But that doesn't apply to the Frameworks? since there is no stable branch.

Newcomers are advised to either use kdesrc-build (and expect lots of building to fix anything in a 
repo that's 30-80 layers deep, which isn't that newcomer-friendly as you usually end up having to 
fix a load of stuff to get that big number of repos to build, the firs time around), or use a distro 
that packages daily master git snapshot (e.g. OpenSuse Tumbleweed, or other distros that cater to 
that workflow, i.e. a rolling distro with frequent master git builds).


[...]

Regards,
--
Ahmad Samir

Re: Merge stable to master vs cherry-picking

[Ahmad Samir]

On 8/12/21 01:08, Sandro Knauß wrote:

Hi,


Fixing it in master means i have to build a zillion of repositories before
even trying to start fixing the bug, it may also happen that once I built
master i can't reproduce the bug because master has been fixed for various
reasons (re-architecture, fixed the bug and forgot to cherry-pick, etc)



Fixing it in the stable branch is much easier, just build the kmail repo
and fix the bug.


I fully agree: merge stable is much clearer and easier.


Until you have to use git-bisect, then the merge commits are a pain in the neck 
sometimes.




Maybe I'm missing something but in case which You described, You will still
need to build all that from master branch to propose patch from stable to
master. Otherwise how You will know if patch needs to be in master or maybe
it's already fixed in other way there?


Well for kdepim master means: I need the newest KDE Frameworks available, my
distro is not that fast shipping them every month. Than I need to build the
complete pimstack, as you cannot mix different version. This is a lot of work
just to fix one bug I know that isn't addressed ;) And the bugs are nasty when
you only see them once in while, so you need to run your fix for several days
to make sure something is fixed. That's why it is that hard to run it from
master branch.


Fix in stable then cherry-pick to master? either it's going to apply cleanly or with small 
conflicts, or it's going to involve more work to apply. If the merge-stable-to-master works, I don't 
know why cherry-picking a commit (or a range of commits) wouldn't work.


I am more accustomed to the KF workflow, there is no stable branch, it's master and release every 
month; with the "leaf" apps, Konsole, Dolphin, Kate ...etc, fixing in master then cherry picking to 
stable isn't an issue, whereas with PIM, it's more of a bundle/suite of libs/apps.


So PIM is a special case in this regard.


I think that the entrace barrier is higher, when we only have cherry-picking
and that means that even less people are able to fix kdepim.
I think especially for newcommers and drive-by committers it is much easier to
be able to just rebuilt one repo instead of a complete stack.

My gut feeling is that git is smarter when you merge than cherry-pick. If
there are renames or code refactoring happing in master than merge strategy is
more reliable. At least I get often very small issues when merging stable.

One big argument against cherry-picking is that you are never know if
everything is inside master because the branches have differnt commits. When
merging stable to master, than you can be sure that everything changed on
stable is in master.

Cheers,

sandro






--
Ahmad Samir

Re: Merge stable to master vs cherry-picking

[Ahmad Samir]

On 3/12/21 21:21, Glen Ditchfield wrote:

I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request

Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* branch, and commit there to get the changes out to the users
in the next release.  I think bug-fixing on master and cherry-picking
back to release wouldn't work so well.




It should; that's how KF works, it doesn't have a stable branches, so any fix is "backported" from 
master to stable, it may need some rebasing, but usually it works.


Merging stable to master will need rebasing too, right? so if you're rebasing a commit anyway, 
taking from master to fix stable makes more sense, and also means master is the source of all 
changes in 99% of the cases.


The same goes with e.g. Konsole, usually it's fixed on master then backported 
to stable.

So, give it a shot the next time you're fixing something in PIM? (a practical proof is the best 
kind). :)


--
Ahmad Samir

Re: drag/drop into dolphin window - help?

[Ahmad Samir]

On 11/11/21 04:17, Robby Stephenson wrote:

Hi all,

I wonder if someone might be able to help figure out what I'm doing wrong
with regard to dragging and dropping an image into a dolphin window, trying
to get it saved as a new file. I've been using this code in Tellico, and
I'm pretty sure it used to work a while ago, but I'm not sure when it
stopped.

I made a short test case in https://invent.kde.org/rstephenson/dragdroptest
where I essentially show a widget that creates a QDrag object with image
data. I drag/drop that into a Dolphin window, and I get a dialog box
asking for a file name and to choose the data format. No matter what format
I choose, the file is never created.


From debugging, it looks like the QMimeData inside the KIO::DropJob has

zero bytes for any data requested which is why the file is never created.
But now I'm at a dead-end - can anyone give me a pointer or suggestion as
to why that might be the case?

Relevant Tellico code is at
https://invent.kde.org/office/tellico/-/blob/master/src/gui/imagewidget.cpp#L448
but I did reduce it to a short test case, available in
https://invent.kde.org/rstephenson/dragdroptest

Thanks!
Robby



Hello.

If this is on wayland, then it sounds like 
https://invent.kde.org/frameworks/kio/-/merge_requests/619 ?

--
Ahmad Samir

Re: How do you label code to be deleted in KF6?

[Ahmad Samir]

On 11/9/21 04:33, Glen Ditchfield wrote:

I would like to have some members of KCalendarCore's incidence classes
removed during the transition from KF5 to KF6, and I'd like to be sure
that the changes won't be missed in the excitement.

Do you have some preferred way to label such changes?  For example, is
there some `#if` statement that can be wrapped around the code, such
that it will be compiled into KF5 but compiled out of KF6?




Hello. We use deprecation macros, grep for DEPRECATED in any KF repo, and see the manual pages for 
those macros (defined by extra-cmake-modules), lots of examples in the repos already.


--
Ahmad Samir

Reminder: KF6 weekly meeting

[Ahmad Samir]

Hello.

As was said in the last meeting's notes, the time of the meeting has been changed to 17:00 CET (due 
to DST change in continental Europe), so that's 16:00 UTC.


Have a good day.
--
Ahmad Samir

Correction to git script to create a work branch

[Ahmad Samir]

This concerns this section:
https://community.kde.org/Infrastructure/GitLab#Using_work_branches_instead_of_forks

The first version of the script (written by me) had a stupid flaw, it didn't guard against being 
called with an empty arg; usually it should be used like this:

$ git work branch-name

if you end up using it without an arg, just `git work`, the setup of your git repo could get screwed 
up, for example, trying to create a branch afterwards, you could end up with:

warning: refname 'origin/master' is ambiguous.
warning: refname 'origin/master' is ambiguous.
fatal: Ambiguous object name: 'origin/master'.


Fortunately, the fix seems to be simple:
$ git show-ref master
a6b947711efdf83718ad4d5ffb384a2bd36e559d refs/heads/master
3ae9d7d897d248024d5bc060fe89f7c30154d4c6 refs/heads/origin/master
a6b947711efdf83718ad4d5ffb384a2bd36e559d refs/remotes/origin/master

$ git update-ref -d refs/heads/origin/master

see this excellent https://stackoverflow.com/a/26046933 post for explanation (I am not a git expert, 
but that worked, AFAICS).


Anyway, the script has been fixed to bail out early if it's called without an 
arg.

Sorry for the inconvenience. :)

--
Ahmad Samir

Debugging io-slaves

[Ahmad Samir]

The wiki has been updated recently 
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves#If_KDE_FORK_SLAVES_is_set


With KIO master, now we should be able to catch a kio-slave in gdb when slaves are forked (the 
current default), just like we were able to do with kdeinit (when io-slaves aren't forked).


Regards,
Ahmad Samir

Re: 5.87 respin request

[Ahmad Samir]

On 10/4/21 14:01, David Faure wrote:

On lundi 4 octobre 2021 13:22:22 CEST Ahmad Samir wrote:

On 10/3/21 08:29, Ahmad Samir wrote:

Please include
https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/99d8dca607327ebf
0b6d2f3cff089207c61d7276

Fixes https://bugs.kde.org/show_bug.cgi?id=442332

Regards,
Ahmad Samir


And
https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/3687f696a48b5917e
3edb5d1513543c0d9939de1

(Which replaces 99d8dca607327e with a supposedly better fix).


Yes this second commit makes more sense, the comment was wrong in the old
commit. But for users it should be all the same, so isn't 99d8dca607327e good
enough for 5.87 ?



Thinking about it, yes, disconnecting all signals before making our one, should 
have the same effect.

--
Ahmad Samir

Re: 5.87 respin request

[Ahmad Samir]

On 10/3/21 08:29, Ahmad Samir wrote:

Please include
https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/99d8dca607327ebf0b6d2f3cff089207c61d7276

Fixes https://bugs.kde.org/show_bug.cgi?id=442332

Regards,
Ahmad Samir



And 
https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/3687f696a48b5917e3edb5d1513543c0d9939de1

(Which replaces 99d8dca607327e with a supposedly better fix).

--
Ahmad Samir

5.87 respin request

[Ahmad Samir]

Please include 
https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/99d8dca607327ebf0b6d2f3cff089207c61d7276


Fixes https://bugs.kde.org/show_bug.cgi?id=442332

Regards,
Ahmad Samir

Re: KF API Documentation proposed, small, addition

[Ahmad Samir]

On 09/09/2021 23:34, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 23:23:29 CEST schrieb Ahmad Samir:

On 09/09/2021 22:47, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 22:35:05 CEST schrieb Ahmad Samir:

On 09/09/2021 22:24, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 21:45:33 CEST schrieb Ahmad Samir:

On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote:

Thanks for pushing this here.

Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir:
Open question:
in which places is it a good idea to use "code"-style with class names
and
method names? So when does readability suffer by too many changes in
the
formatting in a text body?

Looking e.g. at the Qt docs for a reference, they do not use
"code"-style
when referencing classes or methods from text, as well as in the
listing
of classes and methods. So I wonder if this is by design or just
historic?


They use QDoc, IIUC; and it looks like they recommend using \c
https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html

at least that page suggests so.


Then our question was not "if" they have a command to markup things to
be
printed code-like, but "when" it should be used. And the examples they
give
(not sure though if exclusive or inclusive) are

"
variable names, user-defined class names, and C++ keywords (for example,
int and for)
".

So no mention of names of the methods, members, properties and classes
the
documentation is about (note the "user-defined"). And looking at the
existing Qt API documentation, I would guess the given list is rather
exclusive then, and \c with Qt is not to be used when referencing the
elements of the documented API itself (at least in flow text).

Myself I meanwhile rather think that this might be a good choice.
Imagine
how e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text
elements referencing Qt classes or method names would be in code-style.
I
guess the reading flow in the flow text blocks would suffer a lot.


So one vote for and one vote against, we need a tie-breaker.


What I would like to see are some argument for why you want this change?
What is broken now, what does it improve?
Can you give an example where your proposal is applied and what the result
is, before and after?


I think it's useful to markup the method names, that makes reading the API
docs in text format in a header file easier, the same way marking up
true/false is useful, the same way syntax highlighting in most text editors
is useful.


I see, that is where you are coming from, it makes some sense there. But...

... it only makes sense for people looking at headers in a plain text editor
which also is capable of parsing doxygen comments and adding respective
highlighting.

.. for every other plain text viewers/editors, including on the gitlab file
viewer, it makes things harder to read.



I don't see how it's harder to read the API docs than '@c true' or '@param'
or any other doxygen command when viewed in an editor that doesn't highlight doxygen syntax 
properly; those same editors highlight C++ code properly?



.. it very possibly lowers the quality of the generated API docs, which should
be the main purpose of writing those API documentation snippets, no?

So im summary not convinced this would be a change for the better.

Cheers
Friedrich




Since no one else seems to care either way, I'll drop the matter.

Regards,
Ahmad Samir

Re: KF API Documentation proposed, small, addition

[Ahmad Samir]

On 09/09/2021 22:47, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 22:35:05 CEST schrieb Ahmad Samir:

On 09/09/2021 22:24, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 21:45:33 CEST schrieb Ahmad Samir:

On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote:

Thanks for pushing this here.

Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir:
Open question:
in which places is it a good idea to use "code"-style with class names
and
method names? So when does readability suffer by too many changes in the
formatting in a text body?

Looking e.g. at the Qt docs for a reference, they do not use
"code"-style
when referencing classes or methods from text, as well as in the listing
of classes and methods. So I wonder if this is by design or just
historic?


They use QDoc, IIUC; and it looks like they recommend using \c
https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html

at least that page suggests so.


Then our question was not "if" they have a command to markup things to be
printed code-like, but "when" it should be used. And the examples they
give
(not sure though if exclusive or inclusive) are

"
variable names, user-defined class names, and C++ keywords (for example,
int and for)
".

So no mention of names of the methods, members, properties and classes the
documentation is about (note the "user-defined"). And looking at the
existing Qt API documentation, I would guess the given list is rather
exclusive then, and \c with Qt is not to be used when referencing the
elements of the documented API itself (at least in flow text).

Myself I meanwhile rather think that this might be a good choice. Imagine
how e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text
elements referencing Qt classes or method names would be in code-style. I
guess the reading flow in the flow text blocks would suffer a lot.



So one vote for and one vote against, we need a tie-breaker.


What I would like to see are some argument for why you want this change?
What is broken now, what does it improve?
Can you give an example where your proposal is applied and what the result is,
before and after?



I think it's useful to markup the method names, that makes reading the API docs in text format in a 
header file easier, the same way marking up true/false is useful, the same way syntax highlighting 
in most text editors is useful.


For examples, open any header file in a KDE repo and add @c before a method name in the comment 
above any method. :)



Cheers
Friedrich





Regards,
Ahmad Samir

Re: KF API Documentation proposed, small, addition

[Ahmad Samir]

On 09/09/2021 22:24, Friedrich W. H. Kossebau wrote:

Am Donnerstag, 9. September 2021, 21:45:33 CEST schrieb Ahmad Samir:

On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote:

Thanks for pushing this here.

Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir:
Open question:
in which places is it a good idea to use "code"-style with class names and
method names? So when does readability suffer by too many changes in the
formatting in a text body?

Looking e.g. at the Qt docs for a reference, they do not use "code"-style
when referencing classes or methods from text, as well as in the listing
of classes and methods. So I wonder if this is by design or just
historic?


They use QDoc, IIUC; and it looks like they recommend using \c
https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html

at least that page suggests so.


Then our question was not "if" they have a command to markup things to be
printed code-like, but "when" it should be used. And the examples they give
(not sure though if exclusive or inclusive) are

"
variable names, user-defined class names, and C++ keywords (for example, int
and for)
".

So no mention of names of the methods, members, properties and classes the
documentation is about (note the "user-defined"). And looking at the existing
Qt API documentation, I would guess the given list is rather exclusive then,
and \c with Qt is not to be used when referencing the elements of the
documented API itself (at least in flow text).

Myself I meanwhile rather think that this might be a good choice. Imagine how
e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text elements
referencing Qt classes or method names would be in code-style. I guess the
reading flow in the flow text blocks would suffer a lot.

Cheers
Friedrich




So one vote for and one vote against, we need a tie-breaker.

Regards,
Ahmad Samir


--
Ahmad Samir

Re: KF API Documentation proposed, small, addition

[Ahmad Samir]

On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote:

Thanks for pushing this here.

Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir:

I would like to add the following to:
https://community.kde.org/Frameworks/Frameworks_Documentation_Policy#Documen
t_the_Classes


One can use [https://www.doxygen.nl/manual/commands.html Doxygen commands]
to improve readability, for example
* @c which will make the word after it use a monospace/typewriter font face,
typically e.g. @c true, @c false, @c setSomeValue(); for multiple words
you'll have to use: multiple words
* @copydoc to copy the docs of a different method, e.g. if one method
overloads another


I propose to turn "can use" into "should use" and define where which command
should be used where (and which variant in case of aliases), for a consistent
result.
Doxygen commands are already used, so I cannot see how the current proposal
for an addition makes a difference about helping when to do what?

So in the given case, the motivation of the proposal is to improve the
resulting documentation to have all in-text (C++) code expressions to be
formatted in code-typical ways (i.e. monospace fonts). So far this was mainly
done for literal code expressions like "nullptr", "true" and "false", whereas
method names or class names were not, until recently at least.



I agree about "should use".

For how to use a command, one should read the Doxygen docs, which are linked in 
the text.


Open question:
in which places is it a good idea to use "code"-style with class names and
method names? So when does readability suffer by too many changes in the
formatting in a text body?

Looking e.g. at the Qt docs for a reference, they do not use "code"-style when
referencing classes or methods from text, as well as in the listing of classes
and methods. So I wonder if this is by design or just historic?



They use QDoc, IIUC; and it looks like they recommend using \c
https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html

at least that page suggests so.


Leaving @copydoc for a separate discussion.


There are 123 instances of @copydoc in kdelibs, with the the first appearance being [1] from back in 
2003, I am mainly trying to bring it back into use, by pointing it out in the docs.


Incidentally, I think whenever we update one of the core guide pages in the wiki, we should also 
post a link to the new addition in this ML, otherwise people who already know the guidelines 
inside-out won't read the whole thing again, so they miss the new bit (or miss disagreeing with it 
and starting a discussion).


[1] 
https://invent.kde.org/unmaintained/kdelibs/-/commit/cd9de18af7a5b8fc752346596d1ddde512203537



Cheers
Friedrich




Regards,
--
Ahmad Samir

Please include this in 5.86

[Ahmad Samir]

Fixes KMountPoint::findByPath():
https://invent.kde.org/frameworks/kio/-/commit/147193f5661173d24d75f6558e5607d3418f6c71

Thanks,
Ahmad Samir

KF API Documentation proposed, small, addition

[Ahmad Samir]

I would like to add the following to:
https://community.kde.org/Frameworks/Frameworks_Documentation_Policy#Document_the_Classes


One can use [https://www.doxygen.nl/manual/commands.html Doxygen commands] to improve readability, 
for example
* @c which will make the word after it use a monospace/typewriter font face, typically e.g. @c true, 
@c false, @c setSomeValue(); for multiple words you'll have to use:

multiple words
* @copydoc to copy the docs of a different method, e.g. if one method overloads 
another



--
Ahmad Samir

Re: RFC: Konsole profile groups

[Ahmad Samir]

On 31/07/2021 14:30, Konstantin Kharlamov wrote:

On Sat, 2021-07-31 at 13:49 +0200, Ahmad Samir wrote:

Hello.

Is anyone using Konsole profile groups? that is to say, any objections if that
code is removed from
Konsole?

I've never used them, and I don't have any precise idea how they're supposed
to work, if no one is
using them any more we could remove them and simplify the code a bit.


Are you talking about Settings → "Edit Current Profile" and Settings → "Switch 
Profile"?

If yes, then I do use them, they are quite handy. I have default fancy profile 
with an image I set on Konsole background, that is the default profile.

However, the image is light-colored, and not every terminal application uses 
colors that are light-friendly (GCC in particular uses light-blue color that is 
hard to read on light background), so in cases I really need to read that, I  
switch to the older boring-completely-black profile.



No, "profile groups" are a different concept; from reading the code in 
ProfileGroup.cpp it's like a
group of profiles having one parent profile, and when you change the settings 
it can be applied to
all the child profiles, or to specific ones... I am not 100% sure, since I've 
never seen that
concept in action.

[...]

--
Ahmad Samir

RFC: Konsole profile groups

[Ahmad Samir]

Hello.

Is anyone using Konsole profile groups? that is to say, any objections if that code is removed from 
Konsole?


I've never used them, and I don't have any precise idea how they're supposed to work, if no one is 
using them any more we could remove them and simplify the code a bit.


regards,

--
Ahmad Samir

Heads-up: kioslaves .so libs have been renamed

[Ahmad Samir]

Due to a change in kcoreaddons_add_plugin() macro, kioslaves (e.g. kio_file), the name of the actual 
.so has changed from /bin/kf5/kio/file.so to /bin/kf5/kio/kio_file.so, the same 
goes for when you install with `make install`, (the change makes sense as now the file name matches 
the name of the kio slaves, and the plugin unique id...etc).


This isn't an issue for distro-provided packages as e.g. RPM packages remove the file from the old 
package and replace it with the new ones, but it is an issue if you build from source and test right 
from the build-dir (without cleaning the build-dir, as most of us do) or from your kdesrc-build 
installation; so you may want to clear up that situation.


That leads to interesting issue, as kioslave5 binary could pick either kf5/kio/file.so or 
kf5/kio/kio_file.so and you get weird results.


Have a good day.

--
Ahmad Samir

Re: Porting notes / deprecation docs

[Ahmad Samir]

On 10/07/2021 18:00, Frederik Schwarzer wrote:

Hi,

as mentioned earlier, I would like to document classes/methods/etc that
are going to be deprecated during KF6 development.

For that I scraped up all the deprecation macros from the frameworks and
edited them to be more unified.



Good work, that must have been a huge task! (82 frameworks ... :)).


Now I need some opinions.

For once, there is still some stuff in deprecation from KDE4 times.
E.g. void setDoScanFile(bool scanFile); from kiowidgets.

I looked up a few of them in
https://community.kde.org/Frameworks/Porting_Notes but they are not
mentioned there.

Do you think these need to be mentioned in current porting notes as well
or have they been deprecated for long enough to consider them "over with"?



I would agree, these ones were probably just forgotten after the kdelibs split, and then couldn't be 
removed after the first KF5 release so as not to break BIC... etc. (Others who have been around 
longer will know for sure).




As for the location, I would probably start putting content in the
community wiki to a place like
https://community.kde.org/Frameworks/KF6_Porting_Notes. Does anyone see
a problem with that? Might is be better to write such docs in markdown
or restructured text for being better suited for a more modern location?



A wiki page is not most friendly way of editing huge technical documents. Personally, I think a 
markdown file in a git repo would be great, and then it can be "published" to a wiki page or a 
static web page on one of KDE's web sites. Or, we start with an markdown text file, then after it's 
fleshed out / polished, put it in the wiki, editing/adding a small section here or there would be 
easier. (But I do prefer text files, much easier to edit in my usual editor of choice).


FWIW, there is supposed to be a KF6 meeting soon[1]. Not sure if we'll start this week or the next 
one though.


[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2021-July/118028.html



Thanks!

Cheers,
Frederik




--
Ahmad Samir

Re: Weekly KF6 meeting poll

[Ahmad Samir]

On 09/07/2021 19:08, Ahmad Samir wrote:

On 29/06/2021 16:48, Ahmad Samir wrote:

Hello, as was discussed during the KF6 BoF at Akademy, David Edmundson (aka "David 
2", not to be
confused with "David 1" aka "4" or David 3, aka "the David who still has all 
the hair on his
head"... sorry, I digress :)).

David has created a poll as a way to find a more suitable time for the weekly 
KF6 meeting (that we
used to have on Saturdays 13:00 UTC), apparently the link might have gone too 
far under the radar in
the KF6 meeting notes that were posted to this ML by Volker. So here it is, 
please vote:
https://doodle.com/poll/94646r75keyxgqkx

Have a good day.



It's been 18 days since the poll was created, I'd say that's long enough. If no 
one disagrees, I'd
say the deadline is today 00:00 UTC.

As it stands now, it looks like most of the participants find the 03:00 - 04:00 
PM slot most
convenient, and it's a tie between Monday, Tuesday and Friday (each with 
exactly 11 votes).

Best regards.



OK, poll is done now (since no one disagreed).

And the result is that it looks like we'll have the meeting on Mondays at 015:00-016:00 UTC. The 
BigBlueButton room link is at https://community.kde.org/Frameworks#Meetings (I'll update the wiki 
page with the new meeting time shortly).


Have a good day.

--
Ahmad Samir

Re: Weekly KF6 meeting poll

[Ahmad Samir]

On 29/06/2021 16:48, Ahmad Samir wrote:

Hello, as was discussed during the KF6 BoF at Akademy, David Edmundson (aka "David 
2", not to be
confused with "David 1" aka "4" or David 3, aka "the David who still has all 
the hair on his
head"... sorry, I digress :)).

David has created a poll as a way to find a more suitable time for the weekly 
KF6 meeting (that we
used to have on Saturdays 13:00 UTC), apparently the link might have gone too 
far under the radar in
the KF6 meeting notes that were posted to this ML by Volker. So here it is, 
please vote:
https://doodle.com/poll/94646r75keyxgqkx

Have a good day.



It's been 18 days since the poll was created, I'd say that's long enough. If no one disagrees, I'd 
say the deadline is today 00:00 UTC.


As it stands now, it looks like most of the participants find the 03:00 - 04:00 PM slot most 
convenient, and it's a tie between Monday, Tuesday and Friday (each with exactly 11 votes).


Best regards.

--
Ahmad Samir

Weekly KF6 meeting poll

[Ahmad Samir]

Hello, as was discussed during the KF6 BoF at Akademy, David Edmundson (aka "David 2", not to be 
confused with "David 1" aka "4" or David 3, aka "the David who still has all the hair on his 
head"... sorry, I digress :)).


David has created a poll as a way to find a more suitable time for the weekly KF6 meeting (that we 
used to have on Saturdays 13:00 UTC), apparently the link might have gone too far under the radar in 
the KF6 meeting notes that were posted to this ML by Volker. So here it is, please vote:

https://doodle.com/poll/94646r75keyxgqkx

Have a good day.

--
Ahmad Samir

Re: KF5 modules development branches now build in C++17 mode (but keep public headers compatible)

[Ahmad Samir]

On 20/06/2021 12:36, Albert Astals Cid wrote:
[...]


Semi-related question, does anyone know why we're not using
   set(CMAKE_CXX_EXTENSIONS OFF)
?



Good question. Given there _are_ differences between libstdc++ (gcc) and libc++ (clang) and 
sometimes we have issues due to those differences, it does make sense to disable compiler specific 
extensions.



Cheers,
   Albert

>


--
Ahmad Samir

Pushing and creating a merge request from the command line

[Ahmad Samir]

Hello. Remember when we used to use Phabricator and just 'arc diff' and it would push and create a 
diff review in one go? There is a way to do that with Gitlab using Git push options, see:

https://community.kde.org/Infrastructure/GitLab#Creating_a_merge_request_using_the_command_line

Have a good day.

--
Ahmad Samir

Weekly meeting reminder

[Ahmad Samir]

Hello; today is Saturday, we're supposed to have an hour-long weekly
meeting, 13 UTC (that's 15:00 CEST), the usual room on KDE's BigBlueButton:
https://meet.kde.org/b/ada-mi8-aem

See: https://community.kde.org/Frameworks#Meetings for more details

The KF6 board https://phabricator.kde.org/project/board/310/, we're supposed to 
whittle it
down if we want to finally, branch for KF6, no rush, but it should hopefully 
happen at some
point, preferably during our lifetimes. :)

All are welcome to join, even if you just want to listen/see how things are 
done in KDE.

Have a good day.

--
Ahmad Samir

Re: Progress is good for us but bad for documentation

[Ahmad Samir]

On 09/06/2021 18:02, Johannes Zarl-Zierl wrote:

Hi,

Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer:

I would like to ask you to report such documentation to me. We see the
topic come up here and there but it then sometimes sinks into oblivion
again because it was part of a merge request that has then been merged
or so.
[...]
So what to report? Documentation that ...
- explains outdated technology or concepts like KDE 4 or HAL.
- has holes in it. For example a tutorial where you suddenly think,
you skipped an important step.
- you wish was there but you could not find it.


Is this an effort with universal scope, or is there a limit?
Obviously you are at least talking about the wikis. Are you also (at the
current time) talking about other websites and/or application handbooks?

Cheers,
   Johannes



... and API docs :)


--
Ahmad Samir

Re: Can we get tags and tarballs for the KDE Qt patch collection

[Ahmad Samir]

On 07/06/2021 22:52, Albert Astals Cid wrote:

El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va escriure:

Hello folks,

The Fedora packagers were mentioning to me today that it would be a lot
easier for them to ship Qt with our patch collection if we made tags and
tarballs. Is this something we could look into doing?


We explicitly do not want to make releases
   https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F

Making a release means having to use of a version number, and any version 
number we use will be wrong.

Don't think this as a product, think of it as a central place where patches are 
collected.

If they want a tarball because using git is a problem, they can always use 
https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 ?

Cheers,
   Albert



Alternatively they could treat it like backported kernel patches? 
https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog I don't know the 
details but it's doable is what I am saying.


The thing is, IIUC the KDE Qt patch curators don't want to create a release, just a set of 
"important" patches on top of the last open-source Qt release, i.e. deal with it like any other 
project whose upstream hasn't made any new releases in a long time, but there are new commits in 
git; I am sure most distro packagers have seen one or two cases as such.


My 2p.

Have a good day.

--
Ahmad Samir

KF6 weekly meeting

[Ahmad Samir]

Hello; it's been a week already, and today Saturday, we're supposed to have an hour-long weekly 
meeting, 13 UTC (that's 15:00 CEST), the usual room on KDE's BigBlueButton: 
https://meet.kde.org/b/ada-mi8-aem


See: https://community.kde.org/Frameworks#Meetings for more details

Remeber the KF6 board https://phabricator.kde.org/project/board/310/ ? we're supposed to whittle it 
down if we want to actully, finally, branch for KF6, no rush, but it should hopefully happen at some 
point, preferably during our lifetimes. :)


All are welcome to join, even if you just want to listen/see how things are 
done in KDE.

Have a good day.

--
Ahmad Samir

KF6 weekly meeting

[Ahmad Samir]

Hello; it's Saturday - you know the drill - weekly meeting, 13 UTC (that's 15:00 CEST), the usual 
room on KDE's BigBlueButton: https://meet.kde.org/b/ada-mi8-aem


See: https://community.kde.org/Frameworks#Meetings for more details

We spend about an hour discussing the various tasks that still aren't finished on the huge KF6 
board, https://phabricator.kde.org/project/board/310/, according to those who can actually keep 
track of all the discussions going on in those meetings, it seems to actually be useful, and indeed 
some tasks do get finished.


You can join just to listen, see how stuff are discussed, maybe there is a task there that has your 
name on it, something that intrigues you and you'd like to work on ...etc.


Have a good day.

--
Ahmad Samir

KF6 weekly meeting

[Ahmad Samir]

Hello :)

Just like last Saturday, meeting usually starts at 13 UTC (that's 15:00 CEST), the usual room on 
KDE's BigBlueButton: https://meet.kde.org/b/ada-mi8-aem


See: https://community.kde.org/Frameworks#Meetings for more details

We typically spend about an hour trying to bring the number tasks of the ever growing KF6 board, 
https://phabricator.kde.org/project/board/310/, down; by discussing any stuck/needs-input tasks 
(which sometimes results in more tasks being created, so, sometimes the number goes up instead of 
down... at least it's not stuck any more, right?).



(I would like to take this chance to thank Luigi, who somehow can keep track of all the tasks being 
discussed and posts the meeting notes on this ML every week o/).


Have a good day.

--
Ahmad Samir

T14471: Make Qt 5.15.0 to 5.15.2 for frameworks

[Ahmad Samir]

ahmadsamir added a comment.


  Anything other than the methods that were added for "portability at the 
expense of performance", should be OK, famous last words™. :)
  
  I've been bitten twice by the QStringView API in Qt5, it has too many 
surprises, basically because upstream decided to make "code" portable any which 
way... but I digress.
  
  Since QStringRef is in a Qt6 compat module, I think QStringView should wait 
until we branch KF6; we also get QStrinTokenizer Qt6 (yes, it means we might 
scramble a bit between when we branch KF6 and the first release to fix affected 
public API's, but I think that's safer).

TASK DETAIL
  https://phabricator.kde.org/T14471

To: ahmadsamir
Cc: ahmadsamir, nicolasfella, kde-frameworks-devel, usta, LeGast00n, cblack, 
michaelh, ngraham, bruns

KF6 weekly meeting reminder

[Ahmad Samir]

Hello :)

This is a reminder that since today is Saturday we are supposed to have our KF6 weekly meeting, 
which usually starts at 13 UTC (that's 15:00 CEST), the usual room on BBB 
https://meet.kde.org/b/ada-mi8-aem


https://community.kde.org/Frameworks#Meetings

We typically spend an hour trying to chisel away at the ever growing KF6 tasks board 
https://phabricator.kde.org/project/board/310/


Have a good day.

--
Ahmad Samir

Re: Including instead of , does it upset POSIX?

[Ahmad Samir]

On 21/04/2021 15:34, Ahmad Samir wrote:

On 21/04/2021 15:20, Harald Sitter wrote:

To conclude this our verdict is to always use the modern headers?



I am re-checking the rest of the frameworks that failed the first time around; Albert already 
reported that it built for him locally with '#include '; I'll test again, push the changes 
and if the CI doesn't barf on any of it, then my conclusion is it's OK so far.




I've now pushed all those changes; only remains:

Deprecated:
kdelibs4support
kjs

kdesu/src/kdesu_stub.c: this stays since this is C code

these two files are generated by some tool, I left them be:
kholidays/src/parsers/plan2/holidayscannerplan.cpp
kholidays/src/parsers/plan2/holidayscannerplan.lpp


kinit/src/kdeinit/kinit_mac.mm: no idea about mac, can't test, so didn't change 
it
kinit/src/start_kdeinit/start_kdeinit.c: C code


They seemed to build fine on the CI.

--
Ahmad Samir

Re: Including instead of , does it upset POSIX?

[Ahmad Samir]

On 21/04/2021 15:20, Harald Sitter wrote:

To conclude this our verdict is to always use the modern headers?



I am re-checking the rest of the frameworks that failed the first time around; Albert already 
reported that it built for him locally with '#include '; I'll test again, push the changes 
and if the CI doesn't barf on any of it, then my conclusion is it's OK so far.


--
Ahmad Samir

Re: Including instead of , does it upset POSIX?

[Ahmad Samir]

On 15/04/2021 00:16, Albert Astals Cid wrote:

[...]


karchive/autotests/karchivetest.cpp:28:#include 
karchive/src/karchive.cpp:23:#include 


I changed those and it compiles just fine here.



kdesu/src/kdesu_stub.c:31:#include  (this is C code (guessing since I 
don't know C), so it
makes sense to leave that one in)


Yes, this is not C++


kholidays/src/parsers/plan2/holidayscannerplan.cpp:1313:# include 
kholidays/src/parsers/plan2/holidayscannerplan.lpp:17:# include 


This works too


kinit/src/kdeinit/kinit.cpp:24:#include 
kinit/src/kdeinit/kinit_mac.mm:25:#include 
kinit/src/kdeinit/kinit_win.cpp:15:#include 
kinit/src/klauncher/klauncher.cpp:21:#include 
kinit/src/start_kdeinit/start_kdeinit.c:12:#include 
kinit/src/wrapper.cpp:23:#include 


Same (obviously excluding start_kdeinit.c)



ktexteditor/src/buffer/katesecuretextbuffer.cpp:12:#include 
ktexteditor/src/buffer/katetextbuffer.cpp:20:#include 


Same.

Maybe your problem was that you tried to change C files?



I'll try again, maybe there is/was something in my build environment... no idea 
what though. :)

There was only a couple of .c files (I remember kdesu); but ktexteditor doesn't 
have an .c files.

Thanks for re-checking.


Cheers,
   Albert

  


--
Ahmad Samir

Re: Including instead of , does it upset POSIX?

[Ahmad Samir]

On 14/04/2021 22:20, Albert Astals Cid wrote:

El dimecres, 14 d’abril de 2021, a les 15:13:09 (CEST), Ahmad Samir va escriure:

Hello :)

A week or so ago I created an MR to include  instead of  in 
KIO[1].

  From /usr/include/c++/10/cerrno:
/** @file cerrno
   *  This is a Standard C++ Library file.  You should @c \#include this file
   *  in your programs, rather than any of the @a *.h implementation files.
   *
   *  This is the C++ version of the Standard C Library header @c errno.h,
   *  and its contents are (mostly) the same as that header, but are all
   *  contained in the namespace @c std (except for names which are defined
   *  as macros in C).
   */


And then I made similar commits to a lot of the other Frameworks (not all, 
since the build failed
for some of them, so I left them alone).


I honestly didn't think this would be a problem, but you say the build of some 
of them failed, so i guess it is :D

Could you link to the particular MR's that failed?



I created one MR for KIO, once that was reviewed, I then applied similar patches to the other 
Frameworks directly.


Fortunately, it's easy to find which ones weren't changed, grep/rg; (I excluded frameworks that are 
going to be deprecated, kdelibs4support and kjs):


karchive/autotests/karchivetest.cpp:28:#include 
karchive/src/karchive.cpp:23:#include 

kdesu/src/kdesu_stub.c:31:#include  (this is C code (guessing since I don't know C), so it 
makes sense to leave that one in)


kholidays/src/parsers/plan2/holidayscannerplan.cpp:1313:# include 
kholidays/src/parsers/plan2/holidayscannerplan.lpp:17:# include 

kinit/src/kdeinit/kinit.cpp:24:#include 
kinit/src/kdeinit/kinit_mac.mm:25:#include 
kinit/src/kdeinit/kinit_win.cpp:15:#include 
kinit/src/klauncher/klauncher.cpp:21:#include 
kinit/src/start_kdeinit/start_kdeinit.c:12:#include 
kinit/src/wrapper.cpp:23:#include 

ktexteditor/src/buffer/katesecuretextbuffer.cpp:12:#include 
ktexteditor/src/buffer/katetextbuffer.cpp:20:#include 



Cheers,
   Albert




--
Ahmad Samir

Including instead of , does it upset POSIX?

[Ahmad Samir]

Hello :)

A week or so ago I created an MR to include  instead of  in 
KIO[1].

From /usr/include/c++/10/cerrno:
/** @file cerrno
 *  This is a Standard C++ Library file.  You should @c \#include this file
 *  in your programs, rather than any of the @a *.h implementation files.
 *
 *  This is the C++ version of the Standard C Library header @c errno.h,
 *  and its contents are (mostly) the same as that header, but are all
 *  contained in the namespace @c std (except for names which are defined
 *  as macros in C).
 */


And then I made similar commits to a lot of the other Frameworks (not all, since the build failed 
for some of them, so I left them alone).


Harald Sitter asked me to raise the point here, basically he's wondering whether this change might 
cause issues, not being 100% POSIX compliant...etc; I'll quote him because he explained it much 
better than I would:


 ahmadsamir: 
https://invent.kde.org/frameworks/kcrash/-/commit/7a20755723dc1527edb7ed5c3fdcccdbcf7fa768 was this 
ever discussed anywhere? cause there are others like this and my thinking up until now was that 
using the C .h is more appropriate since we use them for POSIX APIs and from that POV the POSIX 
specified header is errno.h


[...]

 might be worth raising for discussion on the mailing list. with c++>=14 there's a whole 
mountain of "deprecated" headers OTOH I also recall reading that the c++ standard doesn't guarantee 
compatibility
 which may or may not be a concern when we use stuff specifically with the expectation that 
they will behave as documented from a POSIX or linux POV (such as signal safety in kcrash)



[1] https://invent.kde.org/frameworks/kio/-/merge_requests/397
--
Ahmad Samir

Saturday, 2021-04-11 KF6 meeting notes

[Ahmad Samir]

Hello, we held the second ever KF6 weekly meeting yesterday, and here are the meeting notes, taken 
by Luigi Toscano (lightly proof-read by myself).



Investigate replacing KSelectAction with QActionGroup 
(<https://phabricator.kde.org/T12097> )

Moved back to backlog, because it (most likely) doesn't require any input. Nicolas Fella will check 
whether any work is really needed.




KGlobalAccel cleanup and improvement for desktop files 
(<https://phabricator.kde.org/T12063>)

A bit of recap:

* the original API has some issues (see the ticket)
* some time ago it was changed to accepte a desktop file with shortcut definitions, but the code is 
not trivial


The question is: should we support only the desktop file as a way to define the 
global shortcuts?

Probably fine for applications, it may not work for plasma or kwin, which have a lot of actions. A 
huge file with all actions would be needed. But in fact anything that can be installed can install a 
desktop file.


The discussion moved to some cross -framework dependencies (powerdevil uses kxmlgui to access 
shortcut stuff for example), and to the question on whether KGlobalAccel should be part of 
Frameworks or Plasma.


In short, KGlobalAccel is made of an API and a daemon.

The deamon is really Plasma-specific, but there are really no drawbacks of keeping that in 
Frameworks, as long as the code is fixed to never trigger it outside Plasma (not even through 
dbus-activation). Right now it can happen and it leads to bad interference with other DE's shortcuts 
API (e.g. GNOME).


The API can probably stay as it is. While the only implementation is on Plasma, it may stay with the 
current Windows/macOS code to allow people to easily compile it on those platforms without #ifdefs, 
and smart enough to disable for example the global shortcut creation integration in KXMLGui when 
running on other platforms.


Future contributors may decide whether a) revamp the platform-specific backends or b) create a new, 
really multiplatform API which would use KGlobalAccel as Plasma backend.




Create replacement for KPluginInfo::kcmServices 
(<https://phabricator.kde.org/T13555>)

The work is mostly done: a refactor of the way plugins and their KCMs are associated, with a direct 
link in the plugin definition instead of the complicated code which runs right now (and which relies 
on a deprecated classes).


The pending question is whether to allow each plugin to list multiple KCMs (which would cover some 
use cases, like Kontact plugins, even though those don't use this mechanism right now). After some 
discussion, it seems there is really no drawback on using a list of KCMs instead of a single KCM.



What we forgot to do is pick the tasks for discussion for the next meeting, so if you have 
suggestions please post them somewhere (on this ML would work best).


--
Ahmad Samir

Request for wide spread testing

[Ahmad Samir]

Hello.

Just to give this more visibility, there is a plan being contemplated to set evn var 
KDE_FORK_SLAVES=1 by default, see[1] for details.


So, if you can, please set KDE_FORK_SLAVES=1 in your env, and report any 
breakage.


[1] https://phabricator.kde.org/T12140


Thanks and have a good day.

--
Ahmad Samir

clang-format section added to the coding style guide

[Ahmad Samir]

Thanks to Alexander Lohnau, there is now a section in the KF coding style that explains about the 
usage of clang-format in the Frameworks:

https://community.kde.org/Policies/Frameworks_Coding_Style#Clang-format_automatic_code_formatting

including tips and tricks (mainly to trick clang-format so that it doesn't 
mangle your code)


Have a good day. :)

--
Ahmad Samir

D27224: add Kongress icon

[Ahmad Samir]

ahmadsamir added a comment.


  Hello. FWIW, I would also close/abandon this diff :) (nice icon BTW).

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D27224

To: mbruchert, dkardarakos, #vdg, ndavis
Cc: ahmadsamir, ndavis, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

Re: Retiring

[Ahmad Samir]

On 13/01/2021 22:57, Christoph Feck wrote:

Hello developers,

my personal situation allows for much less time for KDE
related work, at least during the Corona times.

I would like to retire as soon as possible from these
responsibilities:
- bug triaging
- release service
- KIconTheme maintainer
- KPlotting maintainer
- KWidgetAddons maintainer

For bugzilla, I see many new and old contributors doing awesome
work with triaging, so departing here shouldn't be a big issue.
I hope someone can continue checking responses to NEEDINFO bugs
and REPORTED bugs that didn't get a reply within about two weeks.

Regarding the release service work, I have made sure the load
isn't all back to Albert. For future release work, Heiko Becker
volunteered to help, but maybe another hand would be awesome, too.

For the frameworks modules, I initially assumed each module
must have a separate maintainer, so I volunteered. Today I
see many modules still just community-maintained, and I hope
the community can take over maintainance. Not that I did any
relevant work here in the recent years...

I might eventually continue to prepare some patches, so please
keep all my accounts intact, but only de-list me as the maintainer.

Thank you,
Christoph



This is sad, but I guess life happens and things change and time constraints 
change too.

Thanks a lot for your work on KDE, you are the oldest bugzilla gate keeper, looking at all those 
reports (any ones you didn't have a look at? :D).


(Actually you gave my account elevated privileges when you saw me regularly commenting on bugs a 
couple of years ago, so thanks for that too, it was a very appreciated leg up :))


I wish you and yours the best and hope to still see you around; when time permits and there is an 
itchy bug that bothers you enough to warrant a patch to fix it :)



--
Ahmad Samir

Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

[Ahmad Samir]

On 17/12/2020 22:06, David Faure wrote:
[...]


Right. That's a reason to fix something indeed, but there are still two ways
to fix that, if it was the only reason : either raise min req to Qt 5.14, or
ask for a Qt 5.13 CI.



Ben said on IRC:
"I used 5.14 as a practical matter as 5.13 is essentially unavailable"

That's why team jumped to 5.14 directly, don't know the details however.

[...]

--
Ahmad Samir

T8349: Improve Places panel usability and presentation

[Ahmad Samir]

ahmadsamir added subscribers: sitter, ahmadsamir.
ahmadsamir added a comment.


  ATM, the behaviour is that if you go to /foo/bar/baz/ and "bar" is present in 
the places panel, then while you're at baz or any of its sub-folders then "bar" 
is highlighted in the places panel, i.e the "closest" bookmark is highlighted. 
There is a bug report about changing the behaviour to only highlight the 
"current" folder if it's in the panel.
  
  Posting here to start discussing the issue.
  
  https://bugs.kde.org/show_bug.cgi?id=156678

TASK DETAIL
  https://phabricator.kde.org/T8349

To: ngraham, ahmadsamir
Cc: ahmadsamir, sitter, #frameworks, tomsk, bruns, michaelh, acrouthamel, 
sharvey, mmustac, jtamate, rkflx, #dolphin, ngraham, fabiogomes, waitquietly, 
azyx, dmenig, nikolaik, pberestov, manueljlin, iasensio, Orage, aprcela, 
fprice, cblack, konkinartem, ian, jguidon, Ghost6, jraleigh, fbampaloukas, 
squeakypancakes, alexde, IohannesPetros, GB_2, Codezela, feverfew, 
trickyricky26, meven, crozbo, spoorun, ndavis, navarromorales, firef, 
andrebarros, skadinna, emmanuelp, rdieter, mikesomov, aaronhoneycutt, mbohlender

Re: CI Breakage in Solid on FreeBSD

[Ahmad Samir]

On 2020-10-15 13:32, Adriaan de Groot wrote:

On Thursday, 15 October 2020 11:22:02 CEST Ben Cooksley wrote:

Yesterday changes were landed to Solid, allowing it to make use of new
libimobiledevice API. Unfortunately these changes failed to handle the
situation where an older version of libimobiledevice is in use, causing a
build failure on FreeBSD.


We -- Ahmed, Kai Uwe, me -- are on it. It won't be an instant-fix because
IDEVICE_DEVICE_PAIRED isn't a #define, it's an enum value, but we'll get to
it.

[ade]



Should hopefully be fixed by Kai Uwe's MR 
https://invent.kde.org/frameworks/solid/-/merge_requests/17

merged and now we wait to see what the CI will say :)

--
Ahmad Samir

Re: Dropping the moderation by default flag

[Ahmad Samir]

On 2020-07-21 21:16, Albert Astals Cid wrote:

Hi, this list has an unusual setting [for kde mailing lists] inherited from 
kde-core-devel that is that even subscribed people get moderated, and then the 
list moderator can decide to clear the moderate flag for each person one by one.

I'm proposing to change that because:
  * it's non consistent with the rest of kde mailing lists
  * as moderator of this list i don't think i've seen ever any spam coming from 
a subscribed member.

Opinions?

Cheers,
   Albert




Hello. I asked recently on #kde-devel about the kde-core-devel ML, because I sent an email there and 
it was postponed due to moderation.


Given that kde-core-devel and kde-frameworks-devel are similar, could you please set that same 
setting for kde-core-devel too?


Thanks. :)

--
Ahmad Samir

Re: stale MR triaging - you can help!

[Ahmad Samir]

On 2020-10-13 17:24, David Hurka wrote:

Moin


Moin :)


First list of stale MRs here:
https://invent.kde.org/sysadmin/gitlab-triaging/-/issues

[ ] https://invent.kde.org/graphics/okular/-/merge_requests/234


Ah, that’s mine. It is listed as “waiting for this” in issue okular#21.

What would be the correct way to mark an MR as waiting for something else?
AFAIK we can not create dependency trees, like in Phabricator, right?




Hello :)

From https://invent.kde.org/sysadmin/gitlab-triaging/-/issues/1:

«MRs which are blocked on another MR but otherwise fine to land should get a label 'Blocked' added 
so future triage runs will skip them.»


--
Ahmad Samir

"Approve"ing an MR

[Ahmad Samir]

Hello; this is just a reminder that at the moment the "Approve" button in an MR doesn't send an 
email/notification, so please if you approve an MR also add a comment (otherwise it could be some 
while before it actually gets merged by the author of the MR).


This has been reported by bshah at 
https://gitlab.com/gitlab-org/gitlab/-/issues/231351

Have a good day :)

--
Ahmad Samir

"Approve"ing an MR

[Ahmad Samir]

Hello; this is just a reminder that at the moment the "Approve" button in an MR doesn't send an 
email/notification, so please if you approve an MR also add a comment (otherwise it could be some 
while before it actually gets merged by the author of the MR).


This has been reported by bshah at 
https://gitlab.com/gitlab-org/gitlab/-/issues/231351

Have a good day :)

--
Ahmad Samir

Re: KIO on Android Failure

[Ahmad Samir]

On 18/08/2020 13:52, Ben Cooksley wrote:

Hi all,

At some point recently functionality was added to KIO which broke the
build on Android.

I'm not sure why we're building KIO on Android, but it appears that
some applications may be using it - and this in turn causes the
Dependency Build jobs to fail.

Could someone take a look please?
https://build.kde.org/job/Administration/job/Docker%20Generate%20AndroidQt5.14%20KF5-SDK/lastFailedBuild/console

Thanks,
Ben



It looks like it's caused by systemd integration in kprocessrunner; also it seems Q_OS_UNIX includes 
Android systems, so we need to guard it with !defind(Q_OS_ANDROID). Should hopefully be fixed by 
https://invent.kde.org/frameworks/kio/-/merge_requests/107 .


--
Ahmad Samir

Re: Porting a project to KDE

[Ahmad Samir]

On 16/08/2020 15:12, Yiqing Yu wrote:

I have sent an email to kde-devel-unsubscr...@kde.org, but it was
undeliverable. This address is invalid.
Is there an alternative to unsubscribe me from the mailing list? Thanks.



You can also simply use the web interface:
https://mail.kde.org/mailman/listinfo/kde-devel

follow the instructions there to unsubscribe.

Have a good day.
--
Ahmad Samir

D28460: Add KCModuleData as base class for plugin

[Ahmad Samir]

ahmadsamir closed this revision.
ahmadsamir added a comment.


  Has been moved to 
https://invent.kde.org/frameworks/kcmutils/-/merge_requests/10

REPOSITORY
  R295 KCMUtils

REVISION DETAIL
  https://phabricator.kde.org/D28460

To: bport, #plasma, ervin
Cc: ahmadsamir, meven, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D28460: Add KCModuleData as base class for plugin

[Ahmad Samir]

ahmadsamir added inline comments.

INLINE COMMENTS

> kcmoduleloader.cpp:164
> +
> +QVariantList args2(args.cbegin(), args.cend());
> +

Hello. This breaks the build for Qt 5.12 on the CI, (the min. required version 
in KF is still 5.12):
https://build.kde.org/job/Frameworks/job/kcmutils/job/kf5-qt5%20SUSEQt5.12/155/console

REPOSITORY
  R295 KCMUtils

REVISION DETAIL
  https://phabricator.kde.org/D28460

To: bport, #plasma, ervin
Cc: ahmadsamir, meven, broulik, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D28774: [KFontRequester] Port from QFontDialog to KFontChooserDialog

[Ahmad Samir]

ahmadsamir added a comment.


  In D28774#676000 , @volkov wrote:
  
  > Why not add support for `QPlatformTheme::FontDialog` in 
`KdePlatformTheme::createPlatformDialogHelper()`?
  
  
  Sorry about the late reply; I had looked into the platformtheme integration 
stuff, but at the time I didn't think it was a viable solution (nor was it easy 
for me to port); see https://phabricator.kde.org/D27808 for more details.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D28774

To: ahmadsamir, #frameworks, dfaure, cfeck
Cc: volkov, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: Who merges Merge Requests, and when?

[Ahmad Samir]

On 10/06/2020 18:19, Glen Ditchfield wrote:

In the Phabricator work flow, I would submit a patch, someone knowledgeable
would accept it, and I would `arc land` it.  Clear and simple.

GitLab doesn't have that "accept" step AFAIK.  The KDE Wiki's Infrastructure/
GitLab page says "Once the Merge Request is accepted, KDE Developers will
merge it for you!"  That is imprecise;  I'm in the Developer group, but I'm
just a casual.



AFAIU, with GitLab "accept" could to be, "+1", "ship it", "merge it", I've seen all three used, I've 
also seen a reviewer just committing/merging the change, that counts as accept too :)


Also note that if there are any "unresolved" threads in the MR, the merge button will be disabled, 
so this sort of acts like Phabricator "this review requires changes to proceed".




So, I have a couple of MRs in flight:

https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/1 hasn't
attracted any review comments.  I don't think I _should_ merge it,



Exactly.


but I think I _can_, which makes me uneasy.


As has been said, anyone with a developer account could/can push to pretty much most repos in KDE. 
Having one's code reviewed before committing is always good because it's possible one might have 
missed something.


You can use @user in a comment so that user/dev gets a notification/email to get their attention, 
then "ping" (maybe 1-2 times), then maybe post to this ML, or ask on IRC. I know it's more work, but 
apparently there are always more review requests than there are devs to review them :D



https://invent.kde.org/pim/kcalutils/-/merge_requests/5 had comments, which I
resolved.  So, do I merge it?  Do I wait for both reviewers to upvote it?
Does a reviewer merge it?




Personally, I'd wait for one of the reviewers to merge it; but it happens that sometimes a reviewer 
has already said "change this and that then merge it" in which case, you can go ahead and merge it.


I hope that helps (and that my understanding of the issue isn't wrong :)).

--
Ahmad Samir

D28880: [KWallet] Port last usage of QRegExp to QRegularExpression

[Ahmad Samir]

ahmadsamir added a comment.


  @blaze, (I couldn't find your user name at invent.kde.org); FYI:
  https://invent.kde.org/network/falkon/-/merge_requests/7

REPOSITORY
  R311 KWallet

REVISION DETAIL
  https://phabricator.kde.org/D28880

To: ahmadsamir, #frameworks, dfaure, blaze
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29017: WIP: Introduce three new methods that return all "entries" in a folder

[Ahmad Samir]

ahmadsamir abandoned this revision.

REPOSITORY
  R311 KWallet

REVISION DETAIL
  https://phabricator.kde.org/D29017

To: ahmadsamir, #frameworks, dfaure
Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29017: WIP: Introduce three new methods that return all "entries" in a folder

[Ahmad Samir]

ahmadsamir reopened this revision.
ahmadsamir marked an inline comment as done.
ahmadsamir added a comment.


  Move to gitlab https://invent.kde.org/frameworks/kwallet/-/merge_requests/2

REPOSITORY
  R311 KWallet

REVISION DETAIL
  https://phabricator.kde.org/D29017

To: ahmadsamir, #frameworks, dfaure
Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29810: Don't use the setenv function after fork

[Ahmad Samir]

ahmadsamir added a comment.


  In D29810#674824 , @jpalecek wrote:
  
  > In D29810#674815 , @dfaure wrote:
  >
  > > This breaks FreeBSD compilation. Please check: 
https://build.kde.org/job/Frameworks/job/kcrash/job/kf5-qt5%20FreeBSDQt5.14/17/
  >
  >
  > I see. It needs the declaration of `environ`, which is only provided on 
GNU. Should I amend it here?
  
  
  This has been committed already, create a new review request. (Note that KDE 
has moved to Gitlab at https://invent.kde.org, best if you create a merge 
request there; Phabricator still works, but it's planned to become read-only). 
:)

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D29810

To: jpalecek, #frameworks, dfaure
Cc: ahmadsamir, bruns, apol, anthonyfieroni, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham

D29017: WIP: Introduce three new methods that return all "entries" in a folder

[Ahmad Samir]

This revision was not accepted when it landed; it landed in state "Needs 
Revision".
This revision was automatically updated to reflect the committed changes.
Closed by commit R311:1a19afb6a06d: WIP: Introduce three new methods that 
return all entries in a folder (authored by ahmadsamir).

REPOSITORY
  R311 KWallet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29017?vs=80670=83224

REVISION DETAIL
  https://phabricator.kde.org/D29017

AFFECTED FILES
  CMakeLists.txt
  src/api/KWallet/CMakeLists.txt
  src/api/KWallet/kwallet.cpp
  src/api/KWallet/kwallet.h
  src/api/KWallet/org.kde.KWallet.xml
  src/runtime/kwalletd/backend/kwalletbackend.cc
  src/runtime/kwalletd/backend/kwalletbackend.h
  src/runtime/kwalletd/kwalletd.cpp
  src/runtime/kwalletd/kwalletd.h

To: ahmadsamir, #frameworks, dfaure
Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29017: WIP: Introduce three new methods that return all "entries" in a folder

[Ahmad Samir]

ahmadsamir added a comment.


  In D29017#664279 , @blaze wrote:
  
  > Check this commit message 
https://phabricator.kde.org/R32:f56cdda54b7f88b119f2c7cfb2f534b4fe74478f
  
  
  Sorry for the delay. We applied a workable hack in 
https://phabricator.kde.org/D28880 to get rid of the '[^/]' in the string that 
wildcardToRegularExpression returns, and it seemed to work when I tested falkon.
  
  I guess I'll have migrate this to invent.kde and try addressing the review 
comments.

REPOSITORY
  R311 KWallet

REVISION DETAIL
  https://phabricator.kde.org/D29017

To: ahmadsamir, #frameworks, dfaure
Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29362: [KCharSelect] Initially give focus to the search lineedit

[Ahmad Samir]

ahmadsamir added a comment.


  Moved to https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/2

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D29362

To: ahmadsamir, #frameworks, cfeck
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29362: [KCharSelect] Initially give focus to the search lineedit

[Ahmad Samir]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R236:c0c93cc0fcb5: [KCharSelect] Initially give focus to the 
search lineedit (authored by ahmadsamir).

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29362?vs=81741=83183

REVISION DETAIL
  https://phabricator.kde.org/D29362

AFFECTED FILES
  src/kcharselect.cpp

To: ahmadsamir, #frameworks, cfeck
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29445: [KOpenWithDialog] When pointing at a non-executable file print more meaningful error

[Ahmad Samir]

ahmadsamir added inline comments.

INLINE COMMENTS

> kopenwithdialog.cpp:1009
> +if (QDir::isAbsolutePath(binaryName)) {
> +QFileInfo fi(binaryName);
> +if (fi.exists() && !fi.isExecutable()) {

It's created on the next line. Anyway my initial comment was a nit-pick... it's 
a micro-optimisation for when the code goes through the if block, technically 
DesktopExecParser should get the absolute path in most cases.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29445

To: broulik, #frameworks, #vdg
Cc: ahmadsamir, dfaure, apol, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29445: [KOpenWithDialog] When pointing at a non-executable file print more meaningful error

[Ahmad Samir]

ahmadsamir added inline comments.

INLINE COMMENTS

> broulik wrote in kopenwithdialog.cpp:1008
> Actually, that doesn't exist

https://doc.qt.io/qt-5.15/qfileinfo.html#isAbsolute ?

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29445

To: broulik, #frameworks, #vdg
Cc: ahmadsamir, dfaure, apol, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29782: [StatJob] Make mostLocalUrl ignore remote (ftp, http...etc) URLs

[Ahmad Samir]

ahmadsamir added a comment.


  This wasn't landed on master, but rather phabricator is confused by me 
pushing to work/ branch on gitlab :)

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29782

To: ahmadsamir, #frameworks, dfaure, sitter
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29782: [StatJob] Make mostLocalUrl ignore remote (ftp, http...etc) URLs

[Ahmad Samir]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R241:f2984ff28e72: [StatJob] Make mostLocalUrl ignore remote 
(ftp, http...etc) URLs (authored by ahmadsamir).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29782?vs=82974=83130#toc

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29782?vs=82974=83130

REVISION DETAIL
  https://phabricator.kde.org/D29782

AFFECTED FILES
  autotests/jobtest.cpp
  autotests/jobtest.h
  src/core/statjob.cpp
  src/core/statjob.h
  src/ioslaves/trash/tests/testtrash.cpp
  src/ioslaves/trash/tests/testtrash.h

To: ahmadsamir, #frameworks, dfaure, sitter
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28765: KSettings::Dialog: add support for KPluginInfos without a KService

[Ahmad Samir]

ahmadsamir added a comment.


  I guess a proper fix will need to revert part of this to have the KModuleInfo 
ctor that took a KService not use KPluginInfo internally; better still, of 
course, is having the KPluginInfo ctor work for the case of 
X-KDE-ServiceTypes=SystemSettingsExternalApp, (I couldn't grok KPluginInfo 
stuff fully yet).

REPOSITORY
  R295 KCMUtils

REVISION DETAIL
  https://phabricator.kde.org/D28765

To: dfaure, pino, broulik, mart, davidedmundson, ngraham, svuorela
Cc: ahmadsamir, rikmills, wbauer, kossebau, svuorela, cblack, 
kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D28765: KSettings::Dialog: add support for KPluginInfos without a KService

[Ahmad Samir]

ahmadsamir added a comment.


  systemsettings uses KCModuleInfo::service() to check whether the moduleinfo 
is valid[1], the problem is creating a KPluginInfo from the KService based on a 
.desktop file with X-KDE-ServiceTypes=SystemSettingsExternalApp fails because 
it doesn't seem to have valid metadata. Since the KPluginInfo ctor fails, 
accessing d->pluginInfo.service() causes a crash, I've submitted a proposed fix 
at [2]. This doesn't fix the bug, but merely prevents the crash.
  
  [1] 
https://invent.kde.org/plasma/systemsettings/-/blob/master/core/ModuleView.cpp#L229
  [2] https://invent.kde.org/frameworks/kcmutils/-/merge_requests/1

REPOSITORY
  R295 KCMUtils

REVISION DETAIL
  https://phabricator.kde.org/D28765

To: dfaure, pino, broulik, mart, davidedmundson, ngraham, svuorela
Cc: ahmadsamir, rikmills, wbauer, kossebau, svuorela, cblack, 
kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D28673: [PackageUrlInterceptor] Make QRegularExpression static

[Ahmad Samir]

ahmadsamir commandeered this revision.
ahmadsamir added a reviewer: broulik.
ahmadsamir added a comment.


  Should be handled by 
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/2

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D28673

To: ahmadsamir, #plasma, broulik
Cc: ahmadsamir, bruns, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham

D28673: [PackageUrlInterceptor] Make QRegularExpression static

[Ahmad Samir]

ahmadsamir abandoned this revision.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D28673

To: ahmadsamir, #plasma, broulik
Cc: ahmadsamir, bruns, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham

D29800: Fix URL being passed as argument when launching a .desktop file

[Ahmad Samir]

ahmadsamir added a comment.


  In D29800#672399 , @fvogt wrote:
  
  > Landed to invent - hopefully correctly: 
https://invent.kde.org/frameworks/kio/commit/84e9372f4fa2636f57dc456ac2fa2be271d6a7ec
  
  
  LGTM.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29800

To: fvogt, dfaure, marten
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29558: Add KIO::OpenUrlJob::setShowOpenWithDialog as replacement for KRun::displayOpenWithDialog

[Ahmad Samir]

ahmadsamir added a comment.


  In D29558#672395 , @dfaure wrote:
  
  > Not committed after all.
  
  
  It was committed, as I had it when I did git pull, but you lucked out, it 
seemed to have been eaten by the migration to gitlab somehow; I had to 'git 
reset --hard' to be in sync with invent.kde.org :)

REPOSITORY
  R241 KIO

BRANCH
  2020_05_displayOpenWithDialog

REVISION DETAIL
  https://phabricator.kde.org/D29558

To: dfaure, ahmadsamir, broulik, svuorela
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29787: Fix krununittest

[Ahmad Samir]

ahmadsamir added a comment.


  In D29787#672139 , @dfaure wrote:
  
  > Let's hope the CI has xterm installed I doubt it. Maybe we'll need to 
pick "ls" instead, even if that will look weird.
  
  
  The CI seems to have xterm available as the unit test passed (and then after 
the switch to gitlab, a new CI setup will be available, let's hope it has xterm 
too :)).

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29787

To: ahmadsamir, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29787: Fix krununittest

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:ef7708d1f5ec: Fix krununittest (authored by ahmadsamir).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29787?vs=82975=83011

REVISION DETAIL
  https://phabricator.kde.org/D29787

AFFECTED FILES
  autotests/krununittest.cpp

To: ahmadsamir, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29610: [kio_file] Handle renaming file 'A' to 'a' on FAT32 filesystems

[Ahmad Samir]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:bed09e39fe24: [kio_file] Handle renaming file 
A to a on FAT32 filesystems (authored by ahmadsamir).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29610?vs=82750=83010

REVISION DETAIL
  https://phabricator.kde.org/D29610

AFFECTED FILES
  src/core/copyjob.cpp
  src/ioslaves/file/file_unix.cpp

To: ahmadsamir, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29782: [StatJob] Make mostLocalUrl ignore remote (ftp, http...etc) URLs

[Ahmad Samir]

ahmadsamir added a comment.


  I've just realised, we won't get an error with an http url; in that case we 
return the url the statjob was called on as-is and cancel the job.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29782

To: ahmadsamir, #frameworks, dfaure, sitter
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29782: [StatJob] Make mostLocalUrl ignore remote (ftp, http...etc) URLs

[Ahmad Samir]

ahmadsamir added a comment.


  In D29782#672157 , @dfaure wrote:
  
  > Can you add a unittest for a KIO::mostLocalUrl() in testtrash.cpp (which is 
:local, so it should work)
  
  
  I don't see where the trash ioslave sets UDS_LOCAL_PATH; I think it doesn't 
set it, I could be wrong, though.
  
  > and another one in jobtest.cpp for a http URL (e.g. to test which error 
code we're getting, if any?)
  
  I'll look into that next.
  
  > + call mostLocalUrl() on a "normal" StatJob in testtrash.cpp
  
  Same as the first point :)
  
  [...]

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29782

To: ahmadsamir, #frameworks, dfaure, sitter
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29787: Fix krununittest

[Ahmad Samir]

ahmadsamir created this revision.
ahmadsamir added reviewers: Frameworks, dfaure.
Herald added a project: Frameworks.
ahmadsamir requested review of this revision.

REVISION SUMMARY
  After 6452a34cf01d03d316 
, 
DesktopExecParser::resultingArguments() needs
  to find the terminal app binary, otherwise it returns an empty QStringList.

TEST PLAN
  krununittest passes again

REPOSITORY
  R241 KIO

BRANCH
  l-terminal (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29787

AFFECTED FILES
  autotests/krununittest.cpp

To: ahmadsamir, #frameworks, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29782: [StatJob] Make mostLocalUrl ignore remote (ftp, http...etc) URLs

[Ahmad Samir]

ahmadsamir updated this revision to Diff 82974.
ahmadsamir retitled this revision from "[StatJob] Change mostLocalUrl to only 
handle protocols with Class=:local" to "[StatJob] Make mostLocalUrl ignore 
remote (ftp, http...etc) URLs".
ahmadsamir edited the summary of this revision.
ahmadsamir edited the test plan for this revision.
ahmadsamir added a comment.


  Improve

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29782?vs=82959=82974

BRANCH
  l-most-local-url-local (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29782

AFFECTED FILES
  src/core/statjob.cpp
  src/core/statjob.h

To: ahmadsamir, #frameworks, dfaure, sitter
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29385: Introduce KIO::OpenUrlJob, a rewrite and replacement for KRun

[Ahmad Samir]

ahmadsamir added a comment.


  In D29385#671987 , @dfaure wrote:
  
  > That's the point, a NFS mount *is* a local URL, so we do use QFile for it. 
And then it takes forever because the kernel has to talk over a socket to 
answer us.
  >  Yes this is horrendous. I hate network mounts :-)
  
  
  I don't have *any* network mounts, never have, so I wasn't aware of that. 
Yep, that is horrendous.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29385

To: dfaure, ahmadsamir, broulik, meven, kossebau, davidedmundson, nicolasfella, 
svuorela
Cc: feverfew, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns