Re: 5.94 respin request: Ark drag-and-drop fix

2022-05-12 Thread David Faure
On jeudi 12 mai 2022 03:03:41 CEST Fusion Future wrote:
> Due to my previous mistake in KIO::DropJob, the "Ark drag-and-drop" will
> crash plasmashell.
> 
> https://invent.kde.org/frameworks/kio/-/commit/5a53a629f0cc6c8836dda37dcde70
> 2bd5f37d6ff

And one more

kio v5.94.0-rc5
6ef16db5989294a28f9c341793054ee224eb1cbc
85c0bf8e49d845730d95c85c0292330a5bf03ed63a008cbf02ec9d02f990d09b  
sources/kio-5.94.0.tar.xz

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KWayland 5.94 respin request

2022-05-12 Thread David Faure
On jeudi 12 mai 2022 08:53:14 CEST David Redondo wrote:
> Please include
> https://invent.kde.org/frameworks/kwayland/-/commit/2e94a425120971ec53527862
> 9e216f5e632fe9bc It fixes a crash with a newly added function

This release is one of the most problematic ones :-)

Done:

kwayland v5.94.0-rc2
4657ddaf298a2ff3992bf438dbc98582a31beabd
b2a4d8e1b4d81ce798c991cfb34210ba095f6406a37f4714ae3ab64abaca2636  
sources/kwayland-5.94.0.tar.xz

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





QFileSystemWatcher fails with sockets on FreeBSD

2022-05-03 Thread David Faure
I just debugged the reason for some of the kwayland failures on FreeBSD.

The warnings like
QKqueueFileSystemWatcherEngine::addPaths: open: Operation not supported
seen on
https://build.kde.org/job/Frameworks/view/Platform%20-%20FreeBSDQt5.15/job/kwayland/job/kf5-qt5%20FreeBSDQt5.15/165/testReport/projectroot.autotests/client/kwayland_testDataSource/
are actually the reason for the failure
FAIL!  : TestDataSource::testDestroy() 'connectionDiedSpy.wait()' returned 
FALSE. ()
since this is normally triggered by QFileSystemWatcher noticing that the socket 
got deleted.

But on FreeBSD, it looks like QFileSystemWatcher doesn't support sockets, it 
tries to open them as a file?

$ truss bin/testDataSource testOffer |& grep datasource

openat(AT_FDCWD,"/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0.lock",O_RDWR|O_CREAT|O_CLOEXEC,0660)
 = 8 (0x8)
fstatat(AT_FDCWD,"/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0",0x7fffc840,AT_SYMLINK_NOFOLLOW)
 ERR#2 'No such file or directory'
bind(9,{ AF_UNIX "/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0" },56) 
= 0 (0x0)
connect(12,{ AF_UNIX "/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0" 
},57) = 0 (0x0)
openat(AT_FDCWD,"/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0",O_RDONLY|O_CLOEXEC,00)
 ERR#45 'Operation not supported'
unlink("/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0") = 0 (0x0)
unlink("/tmp/runtime-dfaure/kwayland-test-wayland-datasource-0.lock") = 0 (0x0)

This comes from QKqueueFileSystemWatcherEngine::addPaths calling qt_safe_open() 
on the socket.
I guess it needs to do this differently, at least for sockets? Anyone with 
kqueue/kevent experience? 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Windows unittests: KConfig

2022-03-20 Thread David Faure
On dimanche 20 mars 2022 22:13:17 CET Christoph Cullmann (cullmann.io) wrote:
> On 2022-03-20 22:07, David Faure wrote:
> > The KConfig unittests rely on DBus nowadays (for change notification).
> > This is turned off on Android, and is a cmake option elsewhere,
> > defaulting to ON.
> > 
> > On Windows, I'm sure a lot of other modules rely on DBus, so I suppose
> > it's just a matter of starting the dbus daemon for those modules that
> > need it?
> > Currently the kconfig tests fail for lack of dbus:
> > 
> > 21:55:23  ERROR: The process "dbus-daemon.exe" not found.
> > https://build.kde.org/job/Frameworks/view/Platform%20-%20WindowsMSVCQt5.15
> > /job/kconfig/job/kf5-qt5%20WindowsMSVCQt5.15/217/console
> Hi,
> 
> actually, if one can just disable that on Windows, I would be rather in
> favor of that.
> Any dbus stuff is just a pain there and at least Okular/Kate/... as
> packaged for Windows store avoid the use of any dbus calls.

Makes sense.

I was thinking "akonadi needs dbus anyway", but indeed, that doesn't apply to 
standalone apps, and the DBus stuff in KConfig seems to be mostly for 
workspace-level notifications (color theme changed, etc.).

Made a merge request to turn this off on Windows by default:
https://invent.kde.org/frameworks/kconfig/-/merge_requests/120

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Windows unittests: KConfig

2022-03-20 Thread David Faure
The KConfig unittests rely on DBus nowadays (for change notification).
This is turned off on Android, and is a cmake option elsewhere, defaulting to 
ON.

On Windows, I'm sure a lot of other modules rely on DBus, so I suppose it's 
just a matter of starting the dbus daemon for those modules that need it?
Currently the kconfig tests fail for lack of dbus:

21:55:23  ERROR: The process "dbus-daemon.exe" not found.
https://build.kde.org/job/Frameworks/view/Platform%20-%20WindowsMSVCQt5.15/job/kconfig/job/kf5-qt5%20WindowsMSVCQt5.15/217/console

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Unit tests all pass in Jenkins on Linux

2022-03-20 Thread David Faure
On dimanche 13 mars 2022 17:53:13 CET Ben Cooksley wrote:
> On Mon, Mar 14, 2022 at 4:40 AM David Faure  wrote:
> > After the recent discussions on state of CI, I fixed the last unittest
> > failures (kio, purpose... + apol fixed ECM) so that
> > https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/
> > is all green^H^Hblue again.
> > Please keep it that way!
> 
> Thanks for looking into and fixing all of these David.

Now I'd like to fix the remaining unittest failures on FreeBSD.

I just fixed kcrash by reading the unittest code.
However for the remaining ones, I need to actually debug on FreeBSD.
Is there a FreeBSD virtual machine with the full setup already done for 
building KDE Frameworks, that I could either run locally or log into?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Unit tests all pass in Jenkins on Linux

2022-03-13 Thread David Faure
After the recent discussions on state of CI, I fixed the last unittest failures 
(kio, purpose... + apol fixed ECM) so that
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/ 
is all green^H^Hblue again.
Please keep it that way!

Note however that

* kwayland has a flaky test:

https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/job/kwayland/job/kf5-qt5%20SUSEQt5.15/171/testReport/junit/projectroot.autotests/client/kwayland_testDataDevice/

FAIL!  : TestDataDevice::testReplaceSource() Compared values are not the same
   Actual   (selectionOfferedSpy.count()): 1
   Expected (2)  : 2
   Loc: [autotests/client/test_datadevice.cpp(557)]

Who can look at this one? git log mostly shows Martin Flöser 

who I think isn't active anymore?

* krunner has a flaky test [2] because it measures time spent and expects small 
values like 65ms
(I changed that one to 100ms), 250ms, 300ms. With only 10% safety margins. On a 
busy CI system,
this is bound to fail regularly, even with bigger safety margins. In my 
experience this kind of test
is just not possible (we're not running on a real time OS), I vote for removing 
the test.
CC'ing Eduardo.

https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/job/krunner/job/kf5-qt5%20SUSEQt5.15/325/testReport/junit/projectroot/autotests/runnermanagertest/

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Urgent Kirigami issue (Fwd: Re: 3 respins for 5.91.0)

2022-02-12 Thread David Faure
--  Forwarded Message  --

Subject: Re: 3 respins for 5.91.0
Date: samedi 12 février 2022, 12:48:15 CET
From: Tobias C. Berner 
To: David Faure 

Moin moin

kirigami2 seems to fail with ninja now:

CMake Error:
 Running

  '/usr/local/bin/ninja' '-C'
'/wrkdirs/usr/ports/x11-toolkits/kf5-kirigami2/work/.build' '-t'
'recompact'

 failed with:

  ninja: error: build.ninja:1504: multiple rules generate
src/org/kde/kirigami.2/swipenavigator/PageTab.qml [
-w dupbuild=err]


mfg Tobias

On Sat, 12 Feb 2022 at 11:04, David Faure  wrote:
>
> Many severe bugs found and fixed this week...
>
> kirigami v5.91.0-rc3
> e44ad90a733b476fda87ce9dec462c118911ed2e
> 083204c5f3d12fc85e24d0e1763c935120efcf6d69482bd9e19b0e97bf8822a3  sources/
kirigami2-5.91.0.tar.xz
> due to https://invent.kde.org/frameworks/kirigami/-/merge_requests/
494#note_396227
>
> kio v5.91.0-rc2
> 7571449b2fb5b960db693de443fe319bb76c4f8b
> f2ddea299f3dc98835df445dd1d622d90233115ad0200e75da5e954523466293  sources/
kio-5.91.0.tar.xz
> due to https://invent.kde.org/frameworks/kio/-/merge_requests/
752#note_396030
>
> knewstuff v5.91.0-rc2
> 2a1129c5686f5c278cd661532265531da8550ead
> 5dd9fb32fe7e99b64f8dc4b8801bbdba5dc5ba2eda9bec2fb1fc563a53ec6a2a  sources/
knewstuff-5.91.0.tar.xz
> due to https://marc.info/?l=kde-frameworks-devel=164445401017044=2
>
> Thanks for updating the packages. I'll make the tarballs public
> in 8 hours or so, to give you time to do that.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>

-
-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Kirigami Respin

2022-02-07 Thread David Faure
On lundi 7 février 2022 00:56:50 CET Arjen Hiemstra wrote:
> Hi,
> 
> Any chance of a respin for Kirigami? https://invent.kde.org/frameworks/
> kirigami/-/commit/5e2416257bc5b07d3468647204671a6d360fbd1b fixes an issue
> where some files are installed to the wrong location.

Done:

kirigami v5.91.0-rc2
bdb5605880696b48dd7dd8bdd36699773451537a
ad6a810b00a5a74ddb1598b46253abc979f526512884507106007f0c2efd4f4f  
sources/kirigami2-5.91.0.tar.xz

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





KF6 meeting notes 2021-11-02

2021-11-02 Thread David Faure
https://phabricator.kde.org/T14744
* how to handle deprecation of methods that take a keyword as default 
parameter? Example:
void registerPlugin(const QString , CreateInstanceWithMetaDataFunction 
instanceFunction)
{
registerPlugin(keyword, ::staticMetaObject, instanceFunction);
}
* Decision: remove (via deprecation macros) the keyword parameter from all 
registerPlugin overloads that take one.
* The overloads taking the CreateInstance are considered internal and can be 
deprecated as soon as the internal usage is taken care of.

https://phabricator.kde.org/T13940
* Porting from 
QProcess::setupChildProcess (deprecated) to setChildProcessModifier (Qt6 only) 
can obviously not be done until branching KF6, task moved to "waiting for KF6 
branching"

https://invent.kde.org/frameworks/kservice/-/merge_requests/61
* needs review
* relates to https://invent.kde.org/frameworks/kservice/-/merge_requests/11 
"Deprecate KToolInvokation::kdeinitExecWait" which itself requires porting 
kdesu away from kdeinitExecWait, see next item.

https://phabricator.kde.org/T12166
* KDESu: Close fds manually instead of relying on KService
David documented how to test this in the task. The idea is to derive from 
QProcess, reimplement setupChildProcess (deprecated), close all file 
descriptors (like kdeinit does).

https://invent.kde.org/pim/kdepim-runtime/-/merge_requests/58
* We also discussed the pop3resource implementation (porting it away from a 
connected kioslave). Blocking jobs might become a problem for D-Bus calls so 
better use a different thread, David will work on that.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KF6 meeting notes 2021-10-19

2021-10-20 Thread David Faure
On mardi 19 octobre 2021 17:57:42 CEST Volker Krause wrote:
> * https://phabricator.kde.org/T11632#264728
> Has been discussed several times already, agreement has been that QML
> bindings go into the module they are for, where needed with an built-time
> optional dependency on qtdeclarative. This is the existing practice in e.g.
> ki18n and syntax-highlighting already.
> Check with David F if his concerns on that from two years ago still stand.

No concerns from me anymore, the solution used in ki18n and syntax-
highlighting seems to be fine.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Respin request Kirigami

2021-10-11 Thread David Faure
On lundi 11 octobre 2021 12:46:04 CEST Carl Schwan wrote:
> I don't think it is so urgent that we need a 5.87.1 version of
> Kirigami. So it can't wait a month.

Do you mean "it can't wait" or "it can wait"?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Respin request Kirigami

2021-10-11 Thread David Faure
On lundi 4 octobre 2021 12:39:35 CEST Carl Schwan wrote:
> Please include
> https://invent.kde.org/frameworks/kirigami/-/commit/e7ffa04038307efef10c168
> 2042e795d4a32a935
> 
> This fixes some nasty bugs for the Kirigami settings component.

Hello Carl,

I missed this email. 
Please send respin requests to release-t...@kde.org

I suppose a 5.87.1 version of kirigami is needed then?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: 5.87 respin request

2021-10-04 Thread David Faure
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 ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Problem with frameworks 5.86.0 and Konqueror

2021-09-19 Thread David Faure
On dimanche 19 septembre 2021 10:22:38 CEST Stefano Crocco wrote:
> This problem doesn't only affect http(s) URLs: if I enter, for example, a
> man: URL, the man page isn't opened in Konqueror, as it used to, but in
> KHelpCenter, which is something which shouldn't happen at all.

Ah, that part isn't fixed.

My fix with "disabling external browsers" is about http(s).
For other things like man and info, the logic is really "this KRun is being 
called from an application which can display HTML itself, don't launch another 
process for that". We could add yet another setter, but it's getting ugly, 
especially for a deprecated class.

I'm thinking more and more that we need to copy KRun and KParts::BrowserRun 
into konqueror, merging it all into KonqRun. Not just because of this issue of 
course, but because KRun is deprecated (in favour of OpenUrlJob) for most use 
cases, while the konqueror use case is different (opening things in-process 
rather than launching an external application, in many cases).

What do you think?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Problem with frameworks 5.86.0 and Konqueror

2021-09-19 Thread David Faure
Hi Stefano,

I think I just fixed that.
See konqueror commit and kio MR linked from 
https://bugs.kde.org/show_bug.cgi?id=442636

Cheers,
David.

On dimanche 19 septembre 2021 10:22:38 CEST Stefano Crocco wrote:
> Hello to everyone.
> I'm the current Konqueror maintainer and I need help about how to solve an
> incompatibility between the 5.86.0 version of KIO and Konqueror itself.
> 
> After upgrading KDE frameworks from version 5.85.0 to 5.86.0 on my system, I
> noticed that whenever I entered an http(s) URL in the location bar, the
> page would be opened in a new tab, instead of the current tab like it used
> to (and should) do.
> 
> After a bit of investigation, I came to the conclusion that the cause of
> this behaviour is the change introduced to
> KIO::DesktopExecParser::hasSchemeHandler() by the commit https://
> invent.kde.org/frameworks/kio/-/commit/
> 5fa55a2395cbfb6504e56bf71c869c8e49902e13
> 
> If I understand correctly, this commit removes the precedence previously
> given to kioslaves when there's both a kioslave and a protocol handler for
> the given URL. In Konqueror, this causes the problem I described because
> Konqueror relies in KRun::foundMimeType being called on a subclass of KRun
> to determine how to open an URL when its mimetype is initially unknown. In
> KIO 5.86.0 this doesn't happen anymore because
> KIO::DesktopExecParser::hasSchemeHandler (called from krun.cpp:460) now
> returns true for http(s) URLs, which causes KRun to directly launch the
> preferred application for those URLs. In my case, this is kfmclient_html,
> which is part of Konqueror itself. Depending on the user's settings,
> calling kfmclient_html could either open the URL in a new tab (my
> situation) or even in a new Konqueror window.
> 
> This problem doesn't only affect http(s) URLs: if I enter, for example, a
> man: URL, the man page isn't opened in Konqueror, as it used to, but in
> KHelpCenter, which is something which shouldn't happen at all.
> 
> Looking at the documentation and the source code for KRun I couldn't find a
> way to restore the pre-5.86.0 behaviour. Am I missing something? What would
> be the best way to solve this issue? Initially, when I hadn't yet realized
> that this issue wasn't only for http(s) URLs, I thought of handling those
> in a special way. However, given that the problem is more widespread, I
> don't think this can be done.
> 
> Please, add me as CC to any answer to this mail, as I'm not subscribed to
> this list. I hope that this is the correct list for this kind of issues. I
> had originally sent this mail to kde-devel, and they suggested me to send
> it here.
> 
> Thanks in advance
> 
> Stefano


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Extending the license policy to include ODbL-1.0

2021-09-16 Thread David Faure
+1

On mercredi 15 septembre 2021 17:26:57 CEST Volker Krause wrote:
> Hi,
> 
> there's a MR [1] for ki18n containing data tables generated from OSM data,
> which implies the ODbL-1.0 license [2]. We also already have other places
> ([3], [4]) actually doing this.
> 
> However that's a license not yet covered by our license policy, so I suggest
> we add it.
> 
> ODbL is essentially LGPL-y but for data rather than code, so conceptually
> compatible with our existing licensing.
> 
> It's also not like there's any viable alternative to OSM data, so not doing
> this would imply not being able to implement features integrating
> OSM-derived data.
> 
> The proposed addition to the policy section of https://community.kde.org/
> Policies/Licensing_Policy would be:
> 
> 
> # ''Geographic data'', in particular data based on or derived from
> OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/
> ODbL-1.0.html Open Data Commons Open Database License v1.0]'''.
> 
> 
> What do you think?
> 
> Regards,
> Volker
> 
> [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19
> [2] https://spdx.org/licenses/ODbL-1.0.html
> [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/
> timezonedb_data.cpp
> [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/
> knowledgedb/linemetadata_data.cpp


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Gitlab CI - Inbound

2021-09-05 Thread David Faure
On dimanche 5 septembre 2021 12:26:50 CEST Ben Cooksley wrote:
> On Sun, Sep 5, 2021 at 10:22 PM David Faure  wrote:
> > For frameworks, I think we should be able to write a one-time script that
> > generates .kde-ci.yml files using the dependencies listed in kde-build-
> > metadata (and the platforms listed in metainfo.yaml) ?
> 
> Yes, that should work nicely (although that information now lives in
> sysadmin/repo-metadata, dependencies folder)

All done for Frameworks.

The script that collects platforms from metainfo.yaml won't be useful for 
other KDE modules, but the script that collects deps from dependency-data-kf5-
qt5 is attached, in case it's useful to anyone else.

> Once we've transitioned across to the .kde-ci.yml files the existing
> dependency metadata and branch group files will no longer be required.
> (We'll need to work out a way of exporting this information for easy
> consumption by kdesrc-build and other clients before it can be removed
> though)

OK. Duplication is bad so I agree :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5


collect_deps.pl
Description: Perl program


Re: Gitlab CI - Inbound

2021-09-05 Thread David Faure
On dimanche 5 septembre 2021 12:11:05 CEST Ben Cooksley wrote:
> It would be appreciated if people could please work on getting these files
> populated in Frameworks (as everyone needs those) as well as in their own
> repositories as they are required before we can proceed much further.

Like this https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/135 ?

For frameworks, I think we should be able to write a one-time script that 
generates .kde-ci.yml files using the dependencies listed in kde-build-
metadata (and the platforms listed in metainfo.yaml) ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Noteworthy changes when porting to C++17

2021-07-19 Thread David Faure
On dimanche 18 juillet 2021 02:34:24 CEST Frederik Schwarzer wrote:
> So the question is: did you notice things that have been removed from
> the C++ standard since C++11 that were used in our applications?

I found a list of things that were removed from C++11 in C++17:

http://www.cplusplus2017.info/removed-features-from-c17/

Maybe you can simply link to this document?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Task boards

2021-06-24 Thread David Faure
Hello everyone,

here's a summary of today's BoF discussion relating to the tasks in the KF6 
board: those are supposed to be only those tasks that have to be done before 
6.0, e.g. because they break API or ABI.

Tasks that could be done at any time (including possibly deprecating some 
methods, as long as overall dependencies don't change) should be tagged 
"Frameworks" rather than "KF6", so they go into the Frameworks board.

This also means: please don't tag "Frameworks" those tasks that are 
specifically for the KF6 board, otherwise they appear in both boards.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





T12567: Reduce code/effort duplication around color scheme support

2021-06-24 Thread David Faure
dfaure removed a project: Frameworks.

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

To: ndavis, dfaure
Cc: davidedmundson, ognarb, plasma-devel, kde-frameworks-devel, ndavis, Orage, 
LeGast00n, The-Feren-OS-Dev, cblack, hannahk, jraleigh, zachus, davidre, 
fbampaloukas, GB_2, ragreen, domson, ahmadsamir, dkardarakos, ZrenBot, ngraham, 
kpiwowarski, himcesjf, usta, lesliezhai, ali-mohamed, jensreuterberg, 
asturmlechner, jucato, cfeck, abetts, cgiboudeaux, cullmann, vkrause, sebas, 
cordlandwehr, apol, ahiemstra, mart, knauss, dfaure, michaelh, bruns


Re: Problem with ksycoca not being regenerated under flatpak

2021-06-23 Thread David Faure
On dimanche 20 juin 2021 11:29:39 CEST Albert Astals Cid wrote:
> El diumenge, 13 de desembre de 2020, a les 22:15:26 (CEST), Albert Astals 
Cid va escriure:
> > El dissabte, 12 de desembre de 2020, a les 22:59:58 CET, David Faure va 
escriure:
> > > Time flies, sorry for the delay.
> > > 
> > > On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote:
> > > > flatpak mounts all files as if created on January 1st 1970.
> > > 
> > > Isn't that a bug in itself? Why doesn't it preserve mtimes?
> > 
> > I don't know, because reasons i guess, i never fully understood the
> > answers i got on the flatpak mailing list
> > 
> > https://lists.freedesktop.org/archives/flatpak/2020-October/002049.html
> > 
> > https://lists.freedesktop.org/archives/flatpak/2020-November/002057.html
> > 
> > > > This has the unfortunate effect that when we add new plugins to a
> > > > flatpak
> > > > (i.e. we just added markdown preview support in kate), they are not
> > > > seen
> > > > because ksycoca doesn't feel the need to regenerate itself (the sycoca
> > > > file
> > > > for flatpak is written "outside" flatpak container and thus has a
> > > > newer
> > > > date).
> > > > 
> > > > I remember talking about this probably a year ago at least with Aleix,
> > > > but i guess we did not come up with any solution since it's still
> > > > broken :D
> > > > 
> > > > I don't know much about sycoca, but can we make it so the cache always
> > > > get
> > > > regenerated on app launch when run under flatpak?
> > > 
> > > Is there no way to manually "touch" a directory after adding new files?
> > > 
> > > Otherwise, the hack you have in mind could be implemented as in the
> > > attached patch. Untested, except that it compiles.
> > 
> > I'll test the patch at some point, thanks for caring :)
> 
> So I did *not* test the patch, but I got someone else to test it
> https://github.com/flathub/org.kde.kdenlive/issues/118#issuecomment-86438285
> 7
> 
> And it seems to solve the problem :)
> 
> Big question left is, should we apply that patch you made directly in
> KService or do you prefer we apply it only when compiling the flatpak
> runtime?

I'm OK with this going into KService upstream, it will have no noticeable 
effect on non-flatpak users (one stat() per process, nothing to worry about).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KF6 meeting notes 2021-06-12

2021-06-13 Thread David Faure
On dimanche 13 juin 2021 20:32:42 CEST Luigi Toscano wrote:
> -> we need need input about dfaure presence and try to avoid conflicts with
> Plasma BoFs

I'm available Mon-Thu, but since Tue-Wed is also Qt Contributor Summit,
maybe better plan for the KF6 BoF on Monday (outside the AGM time)?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Respin request for KIO

2021-06-12 Thread David Faure
On vendredi 11 juin 2021 20:50:12 CEST Aleix Pol wrote:
> Hi David,
> It would be good that
> https://invent.kde.org/frameworks/kio/-/commit/3bc92c23dd3456bb18efd44968fab
> f32dd9c3402 was included since 9c9c8df545ab5bd2362e7c01467d3875d79f30ce is
> also inside and it fixes a regression.
> 
> Sorry for the inconvenience and thank you very much!

Just in time ;)
Done:

kio v5.83.0-rc2
db88cf59dd46aebff4072e714dda5a5554a8d699
faa5a519e0cccb7197a4025f4b267a7683b49ad9d03e730a57969f33072f51c1  
sources/kio-5.83.0.tar.xz


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Respin requests (plasma-framework, qqc2-desktop-style)

2021-06-08 Thread David Faure
On lundi 7 juin 2021 18:46:17 CEST Kai Uwe Broulik wrote:
> can we please get a respin for the plasma-framework tarball with
> https://invent.kde.org/frameworks/plasma-framework/-/commit/6b932130a2805f93
> 311de47221ccd52a2071ed42 inside?

Done:
plasma-framework v5.83.0-rc2
487b9e42f50a7d7837aa90c35039abff8fb41010
7adf5f77d7ecf6a45626e7a329c941f6bfe21154b2ff9c6c943727b0e68f145d  
sources/plasma-framework-5.83.0.tar.xz

On lundi 7 juin 2021 17:58:10 CEST Nicolas Fella wrote:
> can we please get a respin for the qqc2-desktop-style tarball with
> https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/73
> inside?

Done: 
qqc2-desktop-style v5.83.0-rc2
071366f0b7d9a9a4068b174413c85aeeb514f389
c10cbde91dc9ef1ba68d8eb8648f3b9452abdff8b38c2a6df829e2b9c8c8f3a1  
sources/qqc2-desktop-style-5.83.0.tar.xz

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Re KIO workers

2021-06-05 Thread David Faure
On samedi 5 juin 2021 21:07:39 CEST Kevin Ottens wrote:
> Hello,
> 
> On Saturday, 5 June 2021 17:51:18 CEST David Faure wrote:
> > On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote:
> > > Do KIO slaves still need the klauncher/kinit loading mechanism?
> > 
> > No. My request for developers to test KIO_FORK_SLAVES=1
> > for daily use is so that apps fork kio worker processes directly, without
> > going via klauncher/kinit. BTW it seems to work fine. I wonder if we
> > should
> > toggle that in 5.84, as part of the incremental move to the KF6 world.
> 
> Actually it works so well that I almost forgot I turned KIO_FORK_SLAVES
> on...

I hope we're both wrong: the env var is *KDE*_FORK_SLAVES :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re KIO workers

2021-06-05 Thread David Faure
On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote:
> Do KIO slaves still need the klauncher/kinit loading mechanism?

No. My request for developers to test KIO_FORK_SLAVES=1
for daily use is so that apps fork kio worker processes directly, without going 
via klauncher/kinit.
BTW it seems to work fine. I wonder if we should toggle that in 5.84, as part of
the incremental move to the KF6 world.

> or could
> that be replaced by json metadata based plugin loading as well?

Err, that's an orthogonal question.

When not going via klauncher/kinit, the app first launches the kioslave5 
process, which then loads the .so with the kio worker plugin. As you can see 
from your process list:

PREFIX/lib64/libexec/kf5/kioslave5 PREFIX/lib64/plugins/kf5/kio/file.so file  
local:/run/user/1000/kded5ymjnPa.3.slave-socket

That .so is determined by slave.cpp using
 QString lib_path = KPluginLoader::findPlugin(_name);
which I believe means it finds the plugin by filename, no .protocol file needed
and no json metadata needed, right?

> - is the performance benefit of kinit still relevant there?

We decided it wasn't. For KIO workers it was never measured anyway.

> - for in-process KIO that would be needed anyway

That would remove the separate process (kioslave5) from the equation
but that's unrelated to plugin loading.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D28861: Sonnet add Malayalam trigram

2021-05-02 Thread David Faure
dfaure accepted this revision.
dfaure added a comment.
This revision is now accepted and ready to land.


  Pushed in 
https://invent.kde.org/frameworks/sonnet/commit/6eb2c6392548772b2c594dfebf0ec53b9a8635d7

REPOSITORY
  R246 Sonnet

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

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


Re: KF6 meeting notes 2021-04-24

2021-05-01 Thread David Faure
Yep, see you all in less than half an hour. I'll be in today.

David.

On vendredi 30 avril 2021 21:54:41 CEST Dominik Haumann wrote:
> Hi Luigi,
> 
> with respect to the reminder of the weekly meetings: It might make
> sense to send such a reminder *before* these meetings and not after
> 
> :-)
> 
> Besides that, thanks for sending these minutes to keep us all informed.
> 
> Best regards
> Dominik
> 
> On Sat, Apr 24, 2021 at 4:19 PM Luigi Toscano  
wrote:
> > Hi all,
> > we had more Plasma people around today, so the work focused on Plasma
> > notes
> > (some of which turned out to not be really KF6.0 blockers).
> > 
> > Before going into the notes, I'd like to remind everyone that the meeting
> > happens every Saturday at 15.00 CEST (currently 13.00 GMT) and it uses the
> > same infrastructure (BBB) of the KF6 sprint:
> > https://community.kde.org/Sprints/KF6/2021Virtual
> > 
> > Now, the notes.
> > 
> > ---
> > https://phabricator.kde.org/T11587 "Investigate making KColorScheme tier1"
> > Very useful as it touches several dependencies, but no people around for
> > this, let's move it to another meeting.
> > 
> > 
> > https://phabricator.kde.org/T13889 "Plasma::PluginLoader cleanup"
> > -> not really KF6, just Plasma. Moved to backlog.
> > 
> > 
> > https://phabricator.kde.org/T12611 "Make Breeze a framework and relocate
> > all of its Plasma theme stuff (e.g. wallpaper) to a different repo still
> > on the Plasma release schedule"
> > -> no need for input, move to "move to KF6 branching"
> > 
> > 
> > https://phabricator.kde.org/T13467 "Theming in Plasma 6"
> > A lot of discussions, agreement in place, just a lot of work.
> > But not blocking for KF6.0.
> > The only task related to KF6 is the creation/splitting of a SVG library
> > and
> > its addition to KF6, which is tracked by
> > https://phabricator.kde.org/T12109
> > -> remove the KF6 tag
> > 
> > 
> > https://phabricator.kde.org/T12105 "Plasma Framework: Discussion
> > Configuration dialogs"
> > It's a cleanup task, Plasma-only
> > -> will be updated and KF6 tag removed
> > 
> > 
> > https://phabricator.kde.org/T12117 "Plasma framework: qml imports plasma
> > Core" Clean up in the imports of plasma-frameworks. Relevant for KF6 (and
> > the part of plasma-frameworks which will stay in KF6).
> > -> improve the description, move to "at branching time"
> > 
> > 
> > https://phabricator.kde.org/T12542 "Fix circular dependency of
> > applications.menu in KService and plasma-workspace"
> > Still need some discussion, but no  one around remembers the details right
> > now.
> > 
> > 
> > https://phabricator.kde.org/T11903 "KWayland for KF6"
> > To be reevaluated now that the we have split some wayland stuff in
> > separate
> > repositories.
> > Client part should be ported away from KWayland.
> > -> no "needs input", the direction "port away from kwayland client" is
> > clear (see last comment), move to "backlog"
> > 
> > 
> > There were some questions about a proposed tasks which affects KIconLoader
> > to switch the default to 24x24  (instead of 22x22)
> > https://phabricator.kde.org/T14397
> > -> people are going to look which code is potentially affected this
> > change. On the Frameworks side, it only affects the "when" to switch the
> > size
> > 
> > 
> > For the next meetings: there are tasks which would benefit from having
> > around:
> > 
> > - Kai Uwe (https://phabricator.kde.org/T12536 ,
> > https://phabricator.kde.org/T11833 , https://phabricator.kde.org/T11875 ,
> > https://phabricator.kde.org/T12008 )
> > 
> > - more Davids (https://phabricator.kde.org/T12275,
> > https://phabricator.kde.org/T12542, etc etc etc)
> > 
> > so if you match the description above and read this, please try to be
> > around next time!
> > 
> > Ciao
> > --
> > Luigi


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE CI: Frameworks » ki18n » kf5-qt5 SUSEQt5.15 - Build # 58 - Still Unstable!

2021-05-01 Thread David Faure
Hi Nicolas,

It looks like the ki18n commit

Backport FindIntl.cmake from CMake 3.20

might have broken the lookup of translations on CI?

https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/job/ki18n/job/kf5-qt5%20SUSEQt5.15/57/testReport/junit/projectroot/autotests/ki18n_klocalizedstringtest/

The test still passes for me locally, so I'm quite confused.
Maybe it would be worth the experiment of reverting the commit, seeing what CI 
says, to find out if it's related?

The unittest uses a .po file from the autotests src dir, so this doesn't depend 
on actual installed translations.

Thanks for taking a look,
David.

On vendredi 30 avril 2021 23:41:45 CEST CI System wrote:
>   BUILD UNSTABLE
> Build
> URL   https://build.kde.org/job/Frameworks/job/ki18n/job/kf5-qt5%20SUSEQt5.15
> /58/ Project: kf5-qt5 SUSEQt5.15
> Date of build:Fri, 30 Apr 2021 21:38:47 +
> Build duration:   2 min 57 sec and counting
> 
> 
> 
> BUILD ARTIFACTS
> 
> abi-compatibility-results.yaml
> acc/KF5I18n-5.82.0.xml
> compat_reports/KF5I18n_compat_report.html
> logs/KF5I18n/5.82.0/log.txt
> 
> 
> 
> JUnit Tests
> Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s),
> Total: 1 test(s) Name: projectroot Failed: 1 test(s), Passed: 4 test(s),
> Skipped: 0 test(s), Total: 5 test(s)
> 
> Failed: projectroot.autotests.ki18n_klocalizedstringtest
> 
> 
> 
> Cobertura Report
> Project Coverage Summary
> Name  PackagesFiles   Classes Lines   Conditionals
> Cobertura Coverage Report 100% (2/2)  100% (17/17)100% (17/17)
> 68%
> (1962/2871)   48% (960/1985) Coverage Breakdown by Package
> Name  Files   Classes Lines   Conditionals
> autotests 100% (5/5)  100% (5/5)  89% (382/427)   55% (243/438)
> src   100% (12/12)100% (12/12)65% (1580/2444) 46% (717/1547)


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D29371: KMainWindow: remove doc paragraph about KGlobal::ref usage

2021-04-14 Thread David Faure
dfaure abandoned this revision.
dfaure added a comment.


  This has been done meanwhile.

REPOSITORY
  R263 KXmlGui

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

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


D29371: KMainWindow: remove doc paragraph about KGlobal::ref usage

2021-04-14 Thread David Faure
dfaure commandeered this revision.
dfaure edited reviewers, added: dvratil; removed: dfaure.
This revision is now accepted and ready to land.

REPOSITORY
  R263 KXmlGui

BRANCH
  master

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

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


Today's meeting

2021-04-10 Thread David Faure
Hi everyone,

I will not be available today for the meeting.
Can someone else drive the discussions?

[Or exceptionally we could move the meeting to Sunday.]

Reminder: today's agenda is:
- KGlobalAccel (T12063)
- KPluginInfo kcmservices (T13555)
- KSelectAction (T12097)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KNotifications usage

2021-04-04 Thread David Faure
On dimanche 4 avril 2021 11:38:05 CEST Corentin BACQUÉ-CAZENAVE wrote:
> I can't do that because I use QMake instead of CMake. 

That is unfortunate, all my condoleances :)

> I tried QT +=
> KNotifications, but QT return an error unknown project.

You want to export the QMAKEPATH environment variable so it points to
the install prefix for KF5 (KNotifications specifically, if you installed it 
by hand).

In other words, you want to set QMAKEPATH so that
$QMAKEPATH/mkspecs/modules/qt_KNotifications.pri
exists.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KNotifications usage

2021-04-04 Thread David Faure
On dimanche 4 avril 2021 10:28:37 CEST Corentin BACQUÉ-CAZENAVE wrote:
> I tried to include knotification.h in my project, but I've an error
> because knotification_export.h is not found.

Do you link to KF5::Notifications?

Linking to a target brings in the include dirs, that's the modern cmake way.

Of course before that you need 
find_package(KF5Notifications CONFIG REQUIRED) 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KF6 sprint meeting notes 2021-04-03

2021-04-03 Thread David Faure
On samedi 3 avril 2021 22:42:36 CEST Ben Cooksley wrote:
> On Sun, Apr 4, 2021 at 2:18 AM David Faure  wrote:
> > Here are the notes from today's meeting (thanks Luigi )
> > 
> > Feature deprecation process
> > =
> > - when to deprecate a feature? Deprecation signals people that they should
> > start porting, but on the other hand the users of a certain feature may
> > need
> > help and the new feature may require some stabilization;
> > - a change on a complex application (ex kmymoney) may require help from
> > both
> > the Frameworks developers and the application developers, both with their
> > specific knowledge
> > - conclusion: deprecate as soon as the replacement is proven to be
> > effective
> > in relevant use cases, and the deprecation doesn't mean the people who
> > worked
> > on the deprecation stop working on the porting of the application
> > 
> > Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version)
> > =
> > 
> > TODO: build a proof of concept with solution 2) (make sure
> > find_package(Qt) is
> > called explicitly before find_package(ECM)) with some real repository and
> > see
> > how it looks like. Other discussions about the general solution. See
> > solution
> > 3 added to the task right now.
> > 
> > Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake
> > targets)
> > ===
> > 
> > (brief summary from the sprint discussion, please check the task)
> > The perfect solution would be to accept both (versioned and unversioned)
> > targets but write the correct one in the configuration files, but such a
> > solution doesn't seem to be possible from the previous discussion (may
> > need
> > additional discussion with steveire, and changes in cmake)
> > 
> > 
> > Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup)
> > ===
> > 
> > The feature is only used by Konqueror, so it can be moved to the
> > application
> > and removed from Frameworks
> > 
> > Timeline for bumping dependencies?
> > ===
> > (Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It
> > needs
> > to be done (can happen now, since tagging just happened) and be advertised
> > in
> > the proper channels (announce). Problem solved!
> 
> If we could get a heads up when this is supposed to happen so I can
> decommission the Qt 5.14 CI jobs that would be appreciated.
> That should also avoid a flurry of failure messages to the list when those
> jobs inevitably fail :)

Very good point. Well, there's no time like the present :)

Packagers agreed, 5.81 RC1 is tagged, so we're all set for bumping the 
dependencies. Can you deactivate the Qt 5.14 CI jobs and let me know when I 
can go ahead?

Can you also confirm that all CI systems support C++17 (gcc >= 8, clang >= 6, 
or MSVC >= 2017) and CMake >= 3.16 ? 
I assume so, but it doesn't hurt to make sure :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





KF6 sprint meeting notes 2021-04-03

2021-04-03 Thread David Faure
Here are the notes from today's meeting (thanks Luigi )

Feature deprecation process
=
- when to deprecate a feature? Deprecation signals people that they should 
start porting, but on the other hand the users of a certain feature may need 
help and the new feature may require some stabilization;
- a change on a complex application (ex kmymoney) may require help from both 
the Frameworks developers and the application developers, both with their 
specific knowledge 
- conclusion: deprecate as soon as the replacement is proven to be effective 
in relevant use cases, and the deprecation doesn't mean the people who worked 
on the deprecation stop working on the porting of the application

Back on https://phabricator.kde.org/T14233 (ECM and multiple Qt version)
=

TODO: build a proof of concept with solution 2) (make sure find_package(Qt) is 
called explicitly before find_package(ECM)) with some real repository and see 
how it looks like. Other discussions about the general solution. See solution 
3 added to the task right now.

Back on https://phabricator.kde.org/T14164 (Create version-less KF cmake 
targets)
===

(brief summary from the sprint discussion, please check the task)
The perfect solution would be to accept both (versioned and unversioned) 
targets but write the correct one in the configuration files, but such a 
solution doesn't seem to be possible from the previous discussion (may need 
additional discussion with steveire, and changes in cmake)


Update on https://phabricator.kde.org/T13806 (KParts plugin cleanup)
===

The feature is only used by Konqueror, so it can be moved to the application 
and removed from Frameworks

Timeline for bumping dependencies?
===
(Qt 5.15, C++17, CMake >= 3.16). Already agreed (by distributions). It needs 
to be done (can happen now, since tagging just happened) and be advertised in 
the proper channels (announce). Problem solved!

Possible point of discussions for the next KF6 meetings (so that people are 
around)?
==
Possibility: Plasma-related topics; KIO-related topics. Maybe solve lower-
level first? (QTextCodec - blocked on Qt regaining support on those old 
codecs, state changed).
Proposed for next week's meeting:
- KGlobalAccel (T12063)
- KPluginInfo kcmservices (T13555)
- KSelectAction (T12097)

See you next week!

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Requiring Qt 5.15 for KDE Frameworks 5?

2021-03-27 Thread David Faure
On samedi 27 mars 2021 17:07:14 CET Nicolás Alvarez wrote:
> > El 27 mar. 2021, a la(s) 12:30, Fabian Vogt 
> > escribió: Moin,
> > 
> > Am Samstag, 27. M?rz 2021, 14:11:38 CET schrieb David Faure:
> >>>>> On samedi 27 mars 2021 12:51:37 CET Kai Uwe Broulik wrote:
> >>>> Hi everyone,
> >>>> during the ongoing KDE Frameworks 6 sprint we were just contemplating
> >>>> whether we can bump the required Qt dependency for Frameworks 5 to Qt
> >>>> 5.15.
> >>>> Reason being that Qt 5.15 includes a set of porting aids and
> >>>> forward-compatibility with Qt 6, such as version-less "Qt" rather than
> >>>> "Qt5" CMake target, various QStringView-related features, and so on.
> >>>> We would like to start working on KDE Frameworks 6 on Qt 6 but still
> >>>> keep Frameworks 5 supported with as little overhead as possible, i.e.
> >>>> not having a gazillion ifdefs or even dedicated branch, which we would
> >>>> likely need, should we have to continue supporting Qt 5.14 in the
> >>>> process.
> >>>> Are there any objections or concerns or potential release schedule
> >>>> conflicts if we did that?
> >> 
> >> While at it, can we also get your feedback on
> >> * Requiring C++17
> > 
> > Which for GCC means at least g++ 9 in practice due to std::filesystem?
> 
> I think we need to be more specific and say what is the minimum compiler
> version. Maybe we can set g++8 as the minimum and use C++17 language
> features while avoiding std::filesystem.
> 
> But only if someone actually cares about keeping gcc8 support :)

I'm pretty sure we can live without std::filesystem, given that we have QFile 
and KIO. I would actually find it confusing to see code that starts using a 
third subsystem for this, at least until proving that it's way better

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Requiring Qt 5.15 for KDE Frameworks 5?

2021-03-27 Thread David Faure
On samedi 27 mars 2021 12:51:37 CET Kai Uwe Broulik wrote:
> Hi everyone,
> 
> during the ongoing KDE Frameworks 6 sprint we were just contemplating
> whether we can bump the required Qt dependency for Frameworks 5 to Qt 5.15.
> 
> Reason being that Qt 5.15 includes a set of porting aids and
> forward-compatibility with Qt 6, such as version-less "Qt" rather than
> "Qt5" CMake target, various QStringView-related features, and so on.
> 
> We would like to start working on KDE Frameworks 6 on Qt 6 but still
> keep Frameworks 5 supported with as little overhead as possible, i.e.
> not having a gazillion ifdefs or even dedicated branch, which we would
> likely need, should we have to continue supporting Qt 5.14 in the process.
> 
> Are there any objections or concerns or potential release schedule
> conflicts if we did that?

While at it, can we also get your feedback on
* Requiring C++17
* Requiring CMake >= 3.16

Obviously this only matters for distributions that update KF5 every month.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D14967: Disable loading of translations for kformattest, which was not designed with translations

2021-02-18 Thread David Faure
dfaure added a comment.


  CI runs things in a sandbox, there are no translations installed that are 
accessible to kf5 tests.

REPOSITORY
  R244 KCoreAddons

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

To: habacker, dfaure, aacid
Cc: asturmlechner, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


Re: Should syntax-higlighting get 5.79.1 released with the control flow color fix?

2021-02-16 Thread David Faure
On lundi 15 février 2021 23:45:35 CET Christoph Cullmann wrote:
> On 2021-02-15 23:27, Albert Astals Cid wrote:
> > Hi all,
> > 
> > Should we do a new release of syntax-highlighting with
> > 341b6e8c64d1fa8df16fe9c65e185cea3c6a7901 ?
> > 
> > 5.79.0 missed it by minutes and given
> > 7a2260a9933cd9838e7dc8ae30c3def2173ba166 was not in any release
> > either, i think it'd make sense to get 5.79.1 out so we don't get
> > complains that we changed black to Orange and the complains that we
> > changed Orange to black next month.
> 
> I would have no issues with a .1,
> guess I am just to ignorant for color changes.

Done:
syntax-highlighting v5.79.1
c4bb26684bd2ec8054623929f3196c6233c5e157
b2825ebee4c527f96562d18abb553195809dcc32174a4b998c71850e24527990  
sources/syntax-highlighting-5.79.1.tar.xz

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Need xcb/xkb help for severe kglobalaccel_x11 issue

2021-02-06 Thread David Faure
Problem mostly fixed by 
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/339
but still seeing 15 notifications instead of 1 (already better than 145...).

Indeed a single call to
/usr/bin/setxkbmap -layout us,fr -option -option compose:caps
sends 12 XCB_XKB_NEW_KEYBOARD_NOTIFY events,
all with changed & XCB_XKB_NKN_DETAIL_KEYCODES, which makes kglobalaccel
ungrab+regrab all keys.

Should I add another compression timer in kglobalaccel, or do you think this is
fixable in setxkbmap?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: RFC: relative executables in desktop files

2021-01-31 Thread David Faure
On dimanche 10 mai 2020 19:17:01 CET Aleix Pol wrote:
> On Sun, Apr 26, 2020 at 1:36 PM David Faure  wrote:
> > During the review of https://phabricator.kde.org/D29170 the following
> > question surfaced again: should it be possible for a desktop file to
> > refer to an executable that is in the "current directory", for some
> > definition of that term. At least, outside of $PATH.
> > 
> > In my opinion, in a GUI program started graphically, the notion of
> > "current dir" (QDir::currentPath()) has no meaning. The user can't see it
> > and can't change it. When starting the program from the command line it
> > does serve a purpose for command line arguments, but IMHO not after that
> > (e.g. if you navigate to another dir in dolphin, QDir::currentPath()
> > still points to the directory you started dolphin from).
> > 
> > There is however another "current directory" that might make more sense
> > when starting a desktop file: the directory of the desktop file itself.
> > 
> > There are actual use cases for that, see this very old request on the XDG
> > mailing-list:
> > https://lists.freedesktop.org/archives/xdg/2011-April/011883.html
> > 
> > AFAICS this discussion has 3 possible outcomes:
> > 
> > * We do not support starting executables that are not in $PATH, end of
> > story. That was actually what I had in mind when writing the code
> > initially, any use of API that also looked in the current directory (like
> > QFileInfo::exists) was accidental. Unless I'm mistaken, this is how it's
> > been until now. It's also what the XDG spec [1] says.
> > 
> > * We support launching executables relative to the desktop file,
> > transparently. In the same directory, put a copy of dolphin called
> > dolphin2, and a copy of org.kde.dolphin.desktop modified to say
> > Exec=dolphin2, and clicking on the desktop file starts dolphin2. That's
> > what my current revision of D29170 does. I'm wondering if this is the
> > right thing to do though.
> > After all, on the command line "foo" doesn't start a local executable
> > called foo, only ./foo does that. Except for people who add "." to $PATH,
> > but that's generally not recommended (security, accidental use of wrong
> > binary).
> > 
> > * We could also adopt the above proposal from the xdg list, which is that
> > Exec=foo only looks in $PATH, while Exec=./foo only looks in the
> > directory of the desktop file.
> > 
> > (I'm purposefully excluding the 4th option, resolving relative to
> > QDir::currentPath() which as explained at the top, would be nonsense
> > IMHO)
> > 
> > Thoughts?
> 
> One thing to note, which is probably easy to support: at the moment in
> kwin we're relying on certain apps to be defined in absolute paths for
> some security measures.
> 
> Just supporting $PATH makes most sense to me, there's increasingly
> other ways to distribute software that abstract XDG out (e.g. snap,
> appimage and flatpak). Weird custom uses should become increasingly
> more rare over time.

Hi Aleix,
There's some interest in reviving this discussion, about the usefulness of 
relative paths (for the Exec field of desktop files) even in the case of 
AppImages. See 
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/71

I would be very interested in getting your feedback (you and anyone else of 
course) in that issue (not here please).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Need xcb/xkb help for severe kglobalaccel_x11 issue

2021-01-31 Thread David Faure
On dimanche 31 janvier 2021 00:30:14 CET Fabian Vogt wrote:
> I suspect that something else is triggering keyboard layout reloads or
> similar in a loop. The keyboard kded module listens for new keyboards and
> mouse events and configures them, which is likely to be called on resume
> when devices get reenumerated. You could try to disable that before
> suspend/resume.

Well spotted. After
qdbus org.kde.kded5 /kded unloadModule keyboard
and suspend/resume, I got only one call to KGlobalAccelImpl::x11MappingNotify

This is amazing. Suddenly it manages to reconnect to wifi instantly, too,
and my global shortcuts work instantly.
Previously, kded kept everyone so busy that everything crawled for about a 
minute, and wifi timed out...
 
> If I run "xmodmap .Xmodmap" here with "xev" open, I get quite a high count
> of mapping change events, presumably for every assignment in the file. If
> the kded calls xmodmap with many assignments, that would be enough to
> explain the issue. Maybe xmodmap could be optimized to upload everything at
> once, like setxkbmap.

I debugged what happens in plasma-desktop/kcms/keyboard
and when resuming from suspend, XInputEventNotifier::processOtherEvents()
emits newKeyboardDevice() many many times.
Each time, the slot KeyboardDaemon::configureKeyboard() does all this

KeyboardConfig::load configuring layouts true configuring options true
X11Helper::getGroupNames Fetched keyboard model from X server: "pc101"
XkbHelper::runConfigLayoutCommand Executed successfully in  137 ms 
"/usr/bin/setxkbmap -layout us,fr -option -option compose:caps"
XkbHelper::runConfigLayoutCommandand with xmodmap 137 ms
X11Helper::getGroupNames Fetched layout groups from X server:   layouts: 
("us", "fr")   variants: ("", "")
KeyboardLayoutActionCollection::loadLayoutShortcuts Skipping empty shortcut for 
"us"
KeyboardLayoutActionCollection::loadLayoutShortcuts Skipping empty shortcut for 
"fr"
KeyboardLayoutActionCollection::loadLayoutShortcuts Cleaning component 
shortcuts on load true

Going back up, the reason why processOtherEvents() thinks there's a new device 
is this:

XInputEventNotifier::getNewDeviceEventType New device id: 15
XInputEventNotifier::getNewDeviceEventType id: 2 name: Virtual core pointer 
used as: 0
XInputEventNotifier::getNewDeviceEventType id: 3 name: Virtual core keyboard 
used as: 1
XInputEventNotifier::getNewDeviceEventType id: 4 name: Virtual core XTEST 
pointer used as: 4
XInputEventNotifier::getNewDeviceEventType id: 5 name: Virtual core XTEST 
keyboard used as: 3
XInputEventNotifier::getNewDeviceEventType id: 6 name: Power Button used as: 3
XInputEventNotifier::getNewDeviceEventType id: 7 name: Video Bus used as: 3
XInputEventNotifier::getNewDeviceEventType id: 8 name: Sleep Button used as: 3
XInputEventNotifier::getNewDeviceEventType id: 9 name: Logitech Craft used as: 4
XInputEventNotifier::getNewDeviceEventType id: 10 name: Logitech MX Master 2S 
used as: 4
XInputEventNotifier::getNewDeviceEventType id: 11 name: Logitech MX Master used 
as: 4
XInputEventNotifier::getNewDeviceEventType id: 12 name: Integrated Camera: 
Integrated C used as: 3
XInputEventNotifier::getNewDeviceEventType id: 13 name: Integrated Camera: 
Integrated I used as: 3
XInputEventNotifier::getNewDeviceEventType id: 14 name: AT Translated Set 2 
keyboard used as: 3
XInputEventNotifier::getNewDeviceEventType id: 15 name: SynPS/2 Synaptics 
TouchPad used as: 4
XInputEventNotifier::getNewDeviceEventType new pointer device, id: 15 name: 
SynPS/2 Synaptics TouchPad used as: 

Before that, it got notified of new device 6, 7, 8, and so on.
It's like X is re-enabling the devices one after the other, and we react to 
each one immediately.

This misdetects the device types though:
   new keyboard device, id: 13 name: Integrated Camera: Integrated I used as: 3
No, my webcam doesn't have keys...

And for some reason, even mouse devices trigger keyboard processing, see the 
arghh comment:

bool XInputEventNotifier::processOtherEvents(xcb_generic_event_t* event)
{
int newDeviceType = getNewDeviceEventType(event);
if( newDeviceType == DEVICE_KEYBOARD ) {
emit(newKeyboardDevice());
}
else if( newDeviceType == DEVICE_POINTER ) {
emit(newPointerDevice());
emit(newKeyboardDevice());  // arghhh, looks like X resets xkb map even 
when only pointer device is connected
}
return true;
}

> I actually had the issue that calling xmodmap here basically froze the whole
> session for a while, which was probably caused by that behaviour.
> Agreed. If those events are caused by something we can't fix, then this
> might turn out to be the best option though.

Now I'm thinking maybe the compression should happen in the keyboard module... ?
That wouldn't fix the xmodmap issue though.
Maybe we're seeing a N devices * M keys multiplication issue, i.e. it would be 
good to compress at both levels.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Need xcb/xkb help for severe kglobalaccel_x11 issue

2021-01-30 Thread David Faure
On dimanche 31 janvier 2021 00:39:38 CET Albert Astals Cid wrote:
> El dissabte, 30 de gener de 2021, a les 18:32:32 CET, David Faure va 
escriure:
> > For years, I've noticed that when resuming a laptop from sleep,
> > kglobalaccel and X11 use 100% CPU for a few minutes, making everything
> > crawl for a while.
> Does this happen on a short sleep too or needs a long sleep?

Short sleep does it too.
Close laptop, wait a few seconds for light to blink, open laptop, 145 calls to 
KGlobalAccelImpl::x11MappingNotify (!)

> If happens with a short sleep, i can't reproduce it :/

Lucky you ;)

But that's interesting, maybe we can approach it from both sides to find what 
triggers it.

I moved out my small ~/.Xmodmap and restarted kglobalaccel5, no change. 
Do you want to try with the attached ~/.config/kxkbrc? (after backing up yours 
of course).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
[Layout]
DisplayNames=,
LayoutList=us,fr
LayoutLoopCount=-1
Model=pc101
Options=compose:caps
ResetOldOptions=true
ShowFlag=false
ShowLabel=true
ShowLayoutIndicator=true
ShowSingle=false
SwitchMode=Global
Use=true


Need xcb/xkb help for severe kglobalaccel_x11 issue

2021-01-30 Thread David Faure
For years, I've noticed that when resuming a laptop from sleep, kglobalaccel 
and X11 
use 100% CPU for a few minutes, making everything crawl for a while.

I finally debugged why: kglobalaccel grabs and ungrabs all global shortcuts 
many many times in a row.

KGlobalAccelImpl::nativeEventFilter event->response_type= 85 xkbEvent= 1 
calling x11MappingNotify()
KGlobalAccelImpl::x11MappingNotify Got XMappingNotify event
KGlobalAccelInterface::ungrabKeys 
KGlobalAccelInterface::grabKeys 
KGlobalAccelImpl::nativeEventFilter event->response_type= 85 xkbEvent= 1 
calling x11MappingNotify()
KGlobalAccelImpl::x11MappingNotify Got XMappingNotify event
KGlobalAccelInterface::ungrabKeys 
KGlobalAccelInterface::grabKeys 
and so on, and so on...

The reason why x11MappingNotify() does ungrabKeys+grabKeys is apparently "Maybe 
the X modifier map has been changed."
... which is not the case at all...

What's an XCB_XKB_MAP_NOTIFY anyway?  
http://manpages.ubuntu.com/manpages/xenial/en/man3/xcb_xkb_map_notify_event_t.3.html
is very much incomplete...

Is it event really such an event that we're getting?
The code says

} else if (m_xkb_first_event && responseType == m_xkb_first_event) {
const uint8_t xkbEvent = event->pad0;
switch (xkbEvent) {
case XCB_XKB_MAP_NOTIFY:
qDebug() << "event->response_type=" << event->response_type << 
"xkbEvent=" << xkbEvent << "calling x11MappingNotify()";
x11MappingNotify();
break;

What sense does it make that this code is checking pad0, which looks like some 
padding member? To avoid a downcast to a more specific event type maybe?

I'm not sure:
* if we're really getting a stream of XCB_XKB_MAP_NOTIFY events or if this code 
misunderstands that
* if so, why is X11 sending such a high number of those
* why the code reacts the same to XCB_XKB_MAP_NOTIFY and to XCB_MAPPING_NOTIFY, 
isn't one enough?

Without outside help I guess I would just compress those events using a timer, 
but that would be a "fix without really understanding the code", never good.

I just noticed https://phabricator.kde.org/D16434 so CC'ing Fabian :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE Frameworks 6 - Virtual Sprint setup

2021-01-30 Thread David Faure
On samedi 30 janvier 2021 14:30:59 CET Kevin Ottens wrote:
> Hello,
> 
> On Saturday, 30 January 2021 12:14:27 CET Volker Krause wrote:
> > Thanks for driving this, I'm in! European hours preferred, any weekend
> > starting from w6 should be possible.
> 
> Same here, not before week 10 or even better not before week 13.

I can do any weekend except week 9 (= March 6-7)
(and weeks 16 & 17 but hopefully we'll do it much before that).

European hours OK but American hours work for me too, I get up late and finish 
late in the evenings :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





T12173: KService: provide solution to migrate away from KServiceTypeTrader/KMimeTypeTrader for loading plugins and parts

2021-01-10 Thread David Faure
dfaure added a comment.


  Thanks Alex, you rock.

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

To: dfaure
Cc: alex, #frameworks, nicolasfella, dfaure, mart, davidre, GB_2, ahmadsamir, 
ngraham, kpiwowarski, usta, asturmlechner, jucato, cfeck, cgiboudeaux, 
cullmann, vkrause, cordlandwehr, knauss


Plasma Framework and Kirigami unittests

2021-01-02 Thread David Faure
Since commit f09b46bec639a97008f3471b4b9bf52648979d12 by Marco Martin
titled "Draft: Replace QString cache IDs with a struct-based version"
the CI says plasma-framework unittests don't pass anymore.


FAIL!  : ThemeTest::loadSvgIcon() 'm_svg->theme()->findInCache(cacheId, result, 
info.lastModified().toSecsSinceEpoch())' returned FALSE. ()
   Loc: [/home/jenkins/workspace/Frameworks/plasma-framework/kf5-qt5 
SUSEQt5.14/autotests/themetest.cpp(81)]

See 
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.14/job/plasma-framework/job/kf5-qt5%20SUSEQt5.14/40/testReport/projectroot/autotests/plasma_themetest/

Could someone from the plasma team please keep an eye on unittests so I don't 
have to be the unittest police?

Oh, and Kirigami has a broken unittest too:

FAIL!  : Kirigami::AvatarTests::test_bad_names() Uncaught exception: NameUtils 
is not defined
   Loc: [/home/jenkins/workspace/Frameworks/kirigami/kf5-qt5 
SUSEQt5.14/autotests/tst_avatar.qml(38)]

See 
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.14/job/kirigami/job/kf5-qt5%20SUSEQt5.14/65/testReport/junit/projectroot.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_SUSEQt514/autotests/tst_avatar_qml/
I think that one is for Carson Black, CC'ed.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D29303: Make KI18N_INSTALL() compatible to KDE_INSTALL_DIRS_NO_DEPRECATED

2020-12-26 Thread David Faure
dfaure added a comment.


  So this is basically the same as https://phabricator.kde.org/D29136 except 
that D29136  gives priority to the 
non-deprecated variable. Any reason against going with D29136 
 after all?

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker
Cc: dfaure, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: KDE review for KWeatherCore

2020-12-25 Thread David Faure
On lundi 21 décembre 2020 07:16:09 CET hanyoung wrote:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting weather data fetching code from KWeather. I think having a
> dedicated weather library can serve the following propose: - simplify the
> KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE

Very interesting. I've been missing such a library 4 years ago when I wrote
a QML app to display the weather on a RPi.
https://github.com/dfaure/qrpiweather

I remember looking at the plasma weather-engine but most of the data sources 
didn't have information about wind, and wind is very very important where I 
live (it's actually blowing up to 105 km/h at the very moment) :)

Feel free to grab any code from qrpiweather that might be useful, BTW.

The backend I ended up using was "Open Weather" (api.openweathermap.org).
But well, that was 4 years ago, things might have changed since :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





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

2020-12-17 Thread David Faure
On jeudi 17 décembre 2020 00:20:41 CET Friedrich W. H. Kossebau wrote:
> Hi,
> 
> Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure:
> > Just a data point on this discussion. Every time we raise the min Qt
> > version, we make life easier for KDE developers, and harder for others who
> > might be thinking of integrating a framework into their project.
> > 
> > Just today I tried using a KF5 library to extend a single plugin in an
> > existing webserver (which I don't control, and which is mostly written in
> > python) [1]. That server is entirely set up with a docker environment on
> > top of... debian buster, which has Qt 5.11.3.
> > Fail.
> > I'm going to have to apply a patch to the KF5 library as part of the
> > Dockerfile, to port it back to Qt 5.11. No way I can convince them to
> > change the base distribution, all I'll get as a reply is to port away
> > from QtCore.
> > 
> > Obviously the 5.11 ship has sailed by now, and I know we can't support old
> > versions forever, but this kind of experience makes me very wary of
> > raising
> > requirements too fast.
> 
> I am reading an objection to the proposed bump in these words, am I correct
> in doing that? 

Objection is a strong word. I am not blocking the proposed bump, I am merely
realizing that the balance between contributor convenience and 
user-convenience (where the user is a developer) is difficult to achieve, 
after this (anecdotal indeed) evidence.

(And yes I needed something very recent, but it wasn't actually a framework,
it was another Qt/KDE library, KOpeningHours. I thought it was still 
illustrative of what one might encounter when trying to use a KDE framework 
outside its usual box of "the rest of the KDE software".)

> Though please those who want to support Qt 5.13 for some more time, consider
> adding support for KDE CI then. It leaves a bad feeling in my stomach that
> KF 5.77+ seems effectively for Qt 5.13 with a sticker "Good Luck!" right
> now. I fear that lowers the image with (potential) KF consumers, it does at
> least with me for other projects.
> I (and possibly many other KF contributors) have no way to test against Qt
> 5.13, so might introduce regressions/break things in the future, which feels
> bad :/

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.

In general I might have asked for a more conservative approach; but currently
anything we do to help with preparing the Qt 6 migration is a good thing,
and having one less Qt version to support helps with that.

So, in those exceptional circumstances, I'm in favour, go for it.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Problem with ksycoca not being regenerated under flatpak

2020-12-12 Thread David Faure
Time flies, sorry for the delay.

On samedi 12 septembre 2020 19:44:45 CET Albert Astals Cid wrote:
> flatpak mounts all files as if created on January 1st 1970.

Isn't that a bug in itself? Why doesn't it preserve mtimes?

> This has the unfortunate effect that when we add new plugins to a flatpak
> (i.e. we just added markdown preview support in kate), they are not seen
> because ksycoca doesn't feel the need to regenerate itself (the sycoca file
> for flatpak is written "outside" flatpak container and thus has a newer
> date).
> 
> I remember talking about this probably a year ago at least with Aleix, but i
> guess we did not come up with any solution since it's still broken :D
> 
> I don't know much about sycoca, but can we make it so the cache always get
> regenerated on app launch when run under flatpak?

Is there no way to manually "touch" a directory after adding new files?

Otherwise, the hack you have in mind could be implemented as in the attached 
patch. Untested, except that it compiles.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
diff --git i/src/sycoca/ksycoca.cpp w/src/sycoca/ksycoca.cpp
index 665d8287d4..6f0159ef3f 100644
--- i/src/sycoca/ksycoca.cpp
+++ w/src/sycoca/ksycoca.cpp
@@ -228,6 +228,19 @@ bool KSycocaPrivate::openDatabase()
 
 bool result = true;
 if (!m_databasePath.isEmpty()) {
+// BEGIN flatpak hack
+static bool firstTime = true;
+if (firstTime) {
+firstTime = false;
+if (QFileInfo::exists(QStringLiteral("/.flatpak-info"))) {
+// We're running inside flatpak, which sets all times to 1970
+// So the first very time, don't use an existing database, recreate it
+qCDebug(SYCOCA) << "flatpak detected, ignoring" << m_databasePath;
+return false;
+}
+}
+// END flatpak hack
+
 qCDebug(SYCOCA) << "Opening ksycoca from" << m_databasePath;
 m_dbLastModified = QFileInfo(m_databasePath).lastModified();
 result = checkVersion();


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

2020-12-12 Thread David Faure
Just a data point on this discussion. Every time we raise the min Qt version, 
we make life easier for KDE developers, and harder for others who might be 
thinking of integrating a framework into their project.

Just today I tried using a KF5 library to extend a single plugin in an 
existing webserver (which I don't control, and which is mostly written in 
python) [1]. That server is entirely set up with a docker environment on top 
of... debian buster, which has Qt 5.11.3.
Fail.
I'm going to have to apply a patch to the KF5 library as part of the 
Dockerfile, to port it back to Qt 5.11. No way I can convince them to change 
the base distribution, all I'll get as a reply is to port away from QtCore.

Obviously the 5.11 ship has sailed by now, and I know we can't support old 
versions forever, but this kind of experience makes me very wary of raising 
requirements too fast.


[1] https://github.com/osm-fr/osmose-backend/issues/555 for the curious


PS: I agree with moving the dates for bumping the min req to just after a KF5 
release, this makes complete sense, feel free to make that adjustment.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





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

2020-12-06 Thread David Faure
On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote:
>  * MidnightBSD
>  * openBSD
> The BSDs are a bit more unfortunate.

Thanks for the information, Albert.

Apparently this means bumping the requirement to Qt 5.14 would break OpenBSD.

How can we reach OpenBSD KDE people?
CC'ing kde-free...@kde.org, I know it's not the same, but maybe you guys know? 
;)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D22764: Stabilize test KFileWidgetTest::testDropFile

2020-11-30 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> meven wrote in kfilewidgettest.cpp:481
> Let me know if I should relay you.

I thought I did that in commit eb18397fe525d2e4bd9 ?

REPOSITORY
  R241 KIO

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

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


Re: Merge tags in master branch?

2020-11-28 Thread David Faure
On lundi 23 novembre 2020 16:11:02 CET Bhushan Shah wrote:
> Hello,
> 
> So I have one question regarding the how we do the framework versioning.
> Namely the tags,
> 
> So currently some packages have a versioned tags on their master branch,
> 
> i.e
> 
> karchive:
> 
> ➜ git describe
> v5.76.0-1-g7304c28
> 
> While in case of some frameworks where translations needs to be taken
> from svn, it is something super weird like,
> 
> kdesu:
> 
> ➜ git describe
> v5.2.0-234-gb7ba89f
> 
> Some packagers who package -git versions in their unstable repos check
> the git describe to figure out what is current revision of the package
> and having "wrong" version there bugs out weirdly.

I know I'm doing something unusual with tags in KDE Frameworks
(tags that are not part of a branch), but I'm surprised anyone would rely on 
`git describe` anyway, I've seen it being a bit unreliable/unexpected in the 
past (in non KDE repositories).

> Do anyone have any opinion on "merging" latest git tag in master branch?
> and potentially doing that for next releases as well?

Merging the tag into master would work, I guess.
One downside for KF5 developers is that the translated docbook files then have 
to be built. That's many screenfuls of things like
[ 21%] Generating po/sr@latin/docs/kioslave5/webdav/index.cache.bz2
which is just "noise" to developers, at least those who read the cmake output 
like I do ;-). And it might slow down compilation, I guess.
You can check out v5.76.0 in kio to see what it looks like.

Pushing translations every day as suggested by Harald creates the risk of a 
bad translation file breaking compilation. I remember catching that quite a 
few times when I started doing KF5 releases. But it hasn't happened for a long 
while so maybe there's now a git hook or something, to prevent that from 
happening?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D17816: Support for xattrs on kio copy/move

2020-11-18 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> arrowd wrote in ConfigureChecks.cmake:12
> There are other parts of code that are guarded with `HAVE_POSIX_ACL`s, and 
> these aren't enabled ATM for FreeBSD. So, the change is needed and I'm 
> willing to implement it.
> 
> I plan to move `set(HAVE_POSIX_ACL ...)` part into `FindACL.cmake` and use 
> this module everywhere. Does that sound OK?

Yep.

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

To: arrowd, dfaure, chinmoyr, bruns, #frameworks, tmarshall, usta, cochise
Cc: usta, scheirle, tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, 
funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, 
nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh


XDG_STATE_HOME

2020-11-07 Thread David Faure
... is finally a thing, after I got merge powers in the xdg gitlab :-)
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/4

I suggest we start using it in KF6:
https://invent.kde.org/frameworks/kconfig/-/merge_requests/33

What it is:

$XDG_STATE_HOME contains state data that should persist between
(application) restarts, but that is not important or portable enough to the 
user that it should be stored in $XDG_DATA_HOME. It may contain:
 * actions history (logs, history, recently used files, …)
 * current state of the application that can be reused on a restart (view, 
layout, open files, undo history, …)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D17816: Support for xattrs on kio copy/move

2020-10-30 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> arrowd wrote in ConfigureChecks.cmake:12
> > 1. enable the ACL stuff on systems with extattr, see the little bit of code 
> > in kpropertiesdialog.cpp
> 
> By that you mean that I should edit the CMake module to define 
> `HAVE_POSIX_ACL` when extattr headers are found?
> 
> Or should I change checks in kpropertiesdialog.cpp from `HAVE_POSIX_ACL` to 
> `HAVE_*ATTR_H`?

I'm talking about the implementation of fileSystemSupportsACL in 
kpropertiesdialog.cpp, which uses getxattr.
But now that I take another look at it, I see that it's already implemented on 
FreeBSD, without the use of extattr, it uses statfs instead.
So I think I was wrong, this part is fine.

I guess the only thing that's a bit weird is that kio_file's attr code 
(unrelated to ACLs) relies on FindACL linking to the right lib (on Linux). It 
would be cleaner if the attr stuff was separate. But no big deal I guess.

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

To: arrowd, dfaure, chinmoyr, bruns, #frameworks, tmarshall, usta, cochise
Cc: usta, scheirle, tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, 
funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, 
nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh


D17816: Support for xattrs on kio copy/move

2020-10-29 Thread David Faure
dfaure accepted this revision.
dfaure added inline comments.

INLINE COMMENTS

> arrowd wrote in ConfigureChecks.cmake:12
> > Has this been tested on a system with sys/extattr.h?
> 
> I was working on this revision on such system all the time. FreeBSD contains 
> extattr bits in its `libc`, so no extra libraries are required.
> 
> So, what should be done here, then? Just move `HAVE_SYS_EXTATTR_H` check to 
> `FindACL.cmake` module?

Ah, I see, OK. No extra lib needed makes it simple.

The FindACL.cmake stuff is a bit of a mess now, with the need for extended 
attributes outside the ACL related code.
Maybe this could be split up into "find extended attribute stuff" and "find ACL 
stuff", the latter relying on the former.
But this merge request has been pending for long enough, let's do buildsystem 
refactoring as part of it.

Let's leave this part as is for now.

If you feel like it, I suggest followup commits to 1) enable the ACL stuff on 
systems with extattr, see the little bit of code in kpropertiesdialog.cpp, and 
2) separate the cmake stuff for ACLs from the cmake stuff for extended 
attributes.

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

To: arrowd, dfaure, chinmoyr, bruns, #frameworks, tmarshall, usta, cochise
Cc: usta, scheirle, tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, 
funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, 
nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh


D17816: Support for xattrs on kio copy/move

2020-10-28 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> ConfigureChecks.cmake:12
>  check_include_files(limits.h  HAVE_LIMITS_H)
> +check_include_files(sys/xattr.h   HAVE_SYS_XATTR_H)
> +check_include_files("sys/types.h;sys/extattr.h" HAVE_SYS_EXTATTR_H)

This is already done by `cmake/FindACL.cmake`, why not add the other one 
(extattr.h) to that file as well?

The CMakeLists.txt in this directory calls `find_package(ACL)` so it'll be used.

Even though this isn't technically about ACLs, I'm guessing it all links 
*because* FindACL.cmake links to libattr, right?
And then this might also mean that the condition in FindACL.cmake needs to be 
updated, it currently *requires* HAVE_SYS_XATTR_H instead of allowing both 
variants.

But then I guess this means kpropertiesdialog.cpp needs to be ported to the 
sys/extattr.h API.

Has this been tested on a system with sys/extattr.h? I'm wondering if what will 
happen is: FindACL didn't find sys/attr.h so it doesn't link to libattr, and 
then the new code here fails to link. Or am I missing something?

> file_unix.cpp:535
> +
> +bool FileProtocol::copyXattrs(const int src_fd, const int dest_fd)
> +{

This whole method should be in `#if HAVE_SYS_XATTR_H || HAVE_SYS_EXTATTR_H`.

Otherwise, on systems with neither defined, a lot of compiler warnings will 
happen, like "keyLen isn't initialized" on line 591.

You can leave the method in the .h without #if (those defines aren't known 
there).
Here you can either #if the method itself (declared and not defined and not 
used, is OK, although some might say, a bit unclean)
or #if the whole method *contents*, but then in the #else you need 
`Q_UNUSED(src_fd); Q_UNUSED(dest_fd);` to avoid compiler warnings about unused 
parameters.

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

To: arrowd, dfaure, chinmoyr, bruns, #frameworks, tmarshall, usta, cochise
Cc: usta, scheirle, tmarshall, arrowd, cfeck, bruns, phidrho, dhaumann, 
funkybomber, abika, pino, davidedmundson, ngraham, atha.kane, spoorun, 
nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh


Re: Dropping the moderation by default flag

2020-10-23 Thread David Faure
On jeudi 15 octobre 2020 16:13:52 CEST Ahmad Samir wrote:
> 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. :)

Done.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

2020-10-18 Thread David Faure
On mardi 6 octobre 2020 11:59:34 CEST Ben Cooksley wrote:
> Hi all,
> 
> This evening i've completed updates to the Windows CI system, bringing it
> from the previous Qt 5.14 setup it was using up to the more recent Qt 5.15.
> As part of this various other libraries will have also been updated.
> 
> This update was prompted by an unannounced dependency change within Breeze
> Icons. As a reminder to all developers, it is imperative that any change to
> your dependencies on a non-KDE project be announced two weeks or more in
> advance.
> 
> Unfortunately due to regressions within Breeze Icons, it is not possible
> for the Dependency Builds to complete at this time, meaning Windows CI
> functionality will be generally unavailable until this is corrected.
> 
> The failure log can be found at
> https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%
> 20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console

That looks like the usual java timeout

I re-ran the exact same job and it passed.

Can you re-enable normal CI service for Windows?
I noticed e.g. that KIO tests were not run anymore...

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D22764: Stabilize test KFileWidgetTest::testDropFile

2020-10-18 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> kfilewidgettest.cpp:481
> +KDirLister *dirLister = fileWidget.dirOperator()->dirLister();
> +QSignalSpy spy(dirLister, SIGNAL(completed(const QUrl &_url)));
> +

For the record, this is broken, it should have been `completed(QUrl)`. 
Specifying argument names is incorrect in SIGNAL() and SLOT() macros.

It makes the wait() below fail every time, but after 5s, so the 100ms became 5s 
:-)

I'm working on fixing this.

REPOSITORY
  R241 KIO

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

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


breeze-icons tests broken

2020-10-11 Thread David Faure
This commit:

commit 8fce580335ef86f19df2238f00270820ac74c9f4
Author: Guo Yunhe 
Date:   Mon Oct 5 11:54:29 2020 +0300

Symlink kup.svg to preferences-system-backup.svg

diff --git a/icons-dark/preferences/32/yast-snapper.svg b/icons/apps/32/kup.svg
similarity index 100%
copy from icons-dark/preferences/32/yast-snapper.svg
copy to icons/apps/32/kup.svg

... seems to have triggered this failure :

https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/breeze-icons/job/kf5-qt5%20SUSEQt5.12/422/testReport/projectroot/autotests/scalable/

Is there a similar symlink missing in the scalable directory maybe?

Please everyone, keep an eye on your own project (either via the mails sent to 
kde-frameworks-devel,
or by visiting build.kde.org), so I don't have to be the unittest police.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

2020-09-12 Thread David Faure
dfaure added a comment.


  In D29299#676447 , @pino wrote:
  
  > In D29299#676446 , @dfaure wrote:
  >
  > > In D29299#676445 , @pino wrote:
  > >
  > > >
  > >
  > >
  > > One of the primary goals of KF5 is to be useable by other applications 
not written by the KDE community (I actually know quite a few).
  > >  As such, it's not hard to imagine a cmake-based application that uses Qt 
and GNUInstallDirs [with qmake going away this will happen more and more], and 
one day it wants to use one of the frameworks. At that point, it shouldn't be 
forced to switch to ECMInstallDirs. Therefore I definitely see value in keeping 
the two things separate, as long as we keep making things easy for what is the 
most common case for us: using both.
  >
  >
  > Sigh. I know this, I never, ever, ever, and let me say it again, **never**, 
forgot about this.
  
  
  OK sorry for stating the obvious then.
  When you wrote "ki18n_install() is basically used by KF sources that use ECM 
already" it seemed to me that this was looking at KDE community code only; it's 
hard to make such a broad statement if including also external code. If you 
agree that being able to use ki18n without ECM is better, then indeed we all 
agree.
  
  > Sure. But it is not what I referred to when I spoke about "broken code".
  
  I have to apologize again, then, because I don't understand what is the 
"broken code" we're talking about then.
  
  > Yes, sorry, you are not Friedrich. OTOH, it would be nice to not be painted 
as "the one that wants to break things without second thoughts". Can we please 
agree on this?
  
  We do agree on this. I don't think I was painting you that way at all. I'm 
merely trying to understand both sides of the argument and find a solution that 
works for everyone.
  
  >> Also, your patch basically includes D29136 
 in the case of no DESTINATION parameter 
specified, hence my suggestion is:
  >> 
  >> - edit D29136  to do the fallback 
using the same logic introduced here: this way marble is already fixed with no 
other changes, and ki18n_install will work also with 
KDE_INSTALL_DIRS_NO_DEPRECATED (e.g. for release-service packages)
  
  Would this be what is done in D29303 ? (I 
just learned about this third option...)

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: dfaure, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

2020-09-12 Thread David Faure
dfaure added a comment.


  In D29299#676445 , @pino wrote:
  
  > I asked for actual **valid** use cases when using the new variables first 
would break, and I still got none. There is a limit to how much you can keep 
broken code working... assuming such broken code exists. I don't think there is 
any of this such situation, as `ki18n_install()` is basically used by KF 
sources that use ECM already, with marble being the only exception (and even 
that, marble won't break).
  
  
  As you know, there are KF5-based applications outside the realm of what we 
can see in LXR.
  One of the primary goals of KF5 is to be useable by other applications not 
written by the KDE community (I actually know quite a few).
  As such, it's not hard to imagine a cmake-based application that uses Qt and 
GNUInstallDirs [with qmake going away this will happen more and more], and one 
day it wants to use one of the frameworks. At that point, it shouldn't be 
forced to switch to ECMInstallDirs. Therefore I definitely see value in keeping 
the two things separate, as long as we keep making things easy for what is the 
most common case for us: using both.
  
  This is why I'm requesting that the integration with ECM is called 
integration and not "backwards compat fallback".
  
  You say you don't want to support broken code. I agree. Would you agree that 
the situation I'm describing here is NOT broken code?
  
  > Oh, and just to make it clear: none of my comments implies that I don't 
care about ECM, nor about any users of it, nor that I "like" to purposefully 
break cmake scripts.
  
  I didn't say any of this, and you're replying to me here, not to Friedrich. 
I'm trying to bring this whole thing to a solution, so let's move aside all 
such accusations and concentrate on what might be helpful to resolve the 
technical issue.

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: dfaure, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29136: Use non-deprecated KDEInstallDir

2020-09-12 Thread David Faure
dfaure added a comment.


  (to remove some confusion: the previous comment had the wrong link and should 
have said "Abandoned in favour of https://phabricator.kde.org/D29299; -- but 
now it's reopened anyway, as an alternative to D29299 
)

REPOSITORY
  R249 KI18n

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

To: heikobecker
Cc: dfaure, kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D29299: Make KI18N_INSTALL() not rely on only LOCALE_INSTALL_DIR

2020-09-12 Thread David Faure
dfaure added a comment.


  @pino Other than the fact that you think D29136 
 is "good enough", do you have any concrete 
objection to this version?
  
  My own objection would simply be that "backward-compatible fallback" is a bit 
too strongly worded; it reads like "this smells bad and might go away one day". 
  How about we rather call this ECM integration, to make it clear that as long 
as you're using ECM, we do not expect every caller of ki18n_install to pass the 
destination manually?

INLINE COMMENTS

> KF5I18nMacros.cmake.in:83
>  #
> +# ``DESTINATION`` specifies the installation directory where the files are 
> installed to (since 5.70).
> +# For backward-compatibility, if this argument is not passed, the 
> installation

(to be updated to 5.75 now)

> KF5I18nMacros.cmake.in:97
>  #
> -# KI18N_INSTALL(po) does the following:
> +# KI18N_INSTALL(po DESITNATION ${KDE_INSTALL_LOCALEDIR}) does the following:
>  # - Compiles kfoo.po into kfoo.mo and installs it in

typo: s/DESITNATION/DESTINATION/

REPOSITORY
  R249 KI18n

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

To: kossebau, ilic, heikobecker, #frameworks, aacid, ltoscano
Cc: dfaure, pino, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


General information for KDE Frameworks developers

2020-09-09 Thread David Faure
Here are some notes from the KF6 BoF at Akademy, as well as general 
information that I realized might not be known to all the relevant developers.

* There's a nice board with many tasks related to preparing KDE Frameworks for 
KF6. https://phabricator.kde.org/project/board/310/
All the tasks in the "Backlog" column, are tasks that can be done TODAY 
already, they don't depend on Qt6 or the possibility to break API/ABI in KDE 
Frameworks. Help is very much needed and welcome!

* We'll have an online meeting at some point to go through the board and add 
tags for priorities and "junior jobs".

* I strongly recommend subscribing to kde-frameworks-devel. If you got scared 
in the past by the amount of "merge requests" emails coming in, this is no 
longer the case with gitlab.

* Instead, I recommend subscribing in gitlab to the projects you care about.
For instance you go to https://invent.kde.org/frameworks/kio and click on the 
bell icon on the right of the large "KIO" header.

* If you want to keep an eye on *all* Frameworks merge requests, as used to 
happen on k-f-d, you can visit 
https://invent.kde.org/groups/frameworks/-/merge_requests (however I don't see 
a way to get notified by email).

* We decided on a two months deadline for the unittests that have always 
failed on FreeBSD and Windows to be whitelisted with QEXPECT_FAIL macros,
and turned into bug reports. This way we can start from a clean state in CI, 
react on regressions more easily, and even set up gitlab to check that MRs 
don't introduce regressions on any platform. It'll also help reducing the 
noise on k-f-d.
If you use either of those platforms, please give a hand with fixing those 
issues for real.
Reminder: to see failing tests, go to
https://build.kde.org/job/Frameworks/view/Everything/
then click on the platform you're interesting in, and then click on the "S" 
column twice. The yellow will propagate to the top.

Happy hacking!

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D28745: Skip caching thumbnails on encrypted filesystems

2020-08-29 Thread David Faure
dfaure accepted this revision.

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, 
waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, 
cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, 
navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov


D28745: Skip caching thumbnails on encrypted filesystems

2020-08-27 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> thumbnail.cpp:741
> +bool allowCache;
> +allowCache = sharesFilesystemWithThumbRoot(filePath);
> +if (!allowCache) {

join with previous line (this isn't C) ;)

> thumbnail.h:95
> +#ifndef Q_OS_WIN
> +static const dev_t deviceIdUnset = std::numeric_limits::max();
> +dev_t m_thumbnailDirDeviceId = deviceIdUnset;

Suggestion: name it s_deviceIdUnset (s for static, to match m for member).

This makes things more readable when looking at the .cpp file (looks like a 
local variable otherwise).

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, 
waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, 
cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, 
navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov


D28745: Skip caching thumbnails on encrypted filesystems

2020-08-22 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> marcingu wrote in thumbnail.cpp:776
> How about I set it to -1 at start and check for that instead? I checked 
> definitions and it looks like dev_st is unsigned, but it shouldn't be a 
> problem.

-1 isn't exactly a great value for an unsigned int :-)

Or rather, it's not great enough (in the "greater than" sense) :-)

But yeah, 0x is a good "not set yet" value for a dev_t, to be safe 
against the possibility of 0.

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, 
waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, 
cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, 
navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov


Re: kwayland's testRemoteAccess still flaky

2020-08-22 Thread David Faure
On lundi 3 août 2020 11:17:45 CEST David Edmundson wrote:
> Urgh, let me just remove that test.
> 
> No-one will even use that protocol soon anyway.

Ping? It's still there it seems.

https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.15/job/kwayland/job/kf5-qt5%20SUSEQt5.15/14/

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE CI: Frameworks » ktexteditor » kf5-qt5 SUSEQt5.15 - Build # 4 - Still Unstable!

2020-08-21 Thread David Faure
93% (4798/5140)
> > 49% (1812/3680)
> > 
> > autotests.src.vimode
> > 100% (9/9)
> > 100% (9/9)
> > 99% (5528/5570)
> > 58% (984/1708)
> > 
> > src.buffer
> > 88% (15/17)
> > 88% (15/17)
> > 89% (1677/1892)
> > 74% (1078/1464)
> > 
> > src.completion
> > 100% (11/11)
> > 100% (11/11)
> > 57% (1788/3134)
> > 42% (1009/2425)
> > 
> > src.completion.expandingtree
> > 100% (3/3)
> > 100% (3/3)
> > 40% (182/457)
> > 21% (73/340)
> > 
> > src.dialogs
> > 0% (0/4)
> > 0% (0/4)
> > 0% (0/864)
> > 0% (0/184)
> > 
> > src.document
> > 100% (4/4)
> > 100% (4/4)
> > 61% (1936/3179)
> > 48% (1407/2945)
> > 
> > src.export
> > 0% (0/4)
> > 0% (0/4)
> > 0% (0/121)
> > 0% (0/156)
> > 
> > src.include.ktexteditor
> > 78% (14/18)
> > 78% (14/18)
> > 83% (189/227)
> > 55% (125/226)
> > 
> > src.inputmode
> > 100% (8/8)
> > 100% (8/8)
> > 63% (192/304)
> > 51% (39/77)
> > 
> > src.mode
> > 88% (7/8)
> > 88% (7/8)
> > 36% (378/1051)
> > 16% (146/891)
> > 
> > src.part
> > 0% (0/1)
> > 0% (0/1)
> > 0% (0/7)
> > 100% (0/0)
> > 
> > src.printing
> > 0% (0/4)
> > 0% (0/4)
> > 0% (0/862)
> > 0% (0/278)
> > 
> > src.render
> > 100% (8/8)
> > 100% (8/8)
> > 77% (950/1227)
> > 67% (610/914)
> > 
> > src.schema
> > 22% (2/9)
> > 22% (2/9)
> > 1% (19/1472)
> > 1% (6/625)
> > 
> > src.script
> > 94% (16/17)
> > 94% (16/17)
> > 67% (699/1040)
> > 53% (212/403)
> > 
> > src.search
> > 100% (7/7)
> > 100% (7/7)
> > 74% (/1503)
> > 63% (590/932)
> > 
> > src.spellcheck
> > 50% (4/8)
> > 50% (4/8)
> > 7% (82/1207)
> > 3% (19/696)
> > 
> > src.swapfile
> > 50% (1/2)
> > 50% (1/2)
> > 32% (119/374)
> > 32% (64/203)
> > 
> > src.syntax
> > 88% (7/8)
> > 88% (7/8)
> > 64% (488/761)
> > 36% (206/576)
> > 
> > src.undo
> > 100% (5/5)
> > 100% (5/5)
> > 88% (652/741)
> > 73% (276/378)
> > 
> > src.utils
> > 95% (36/38)
> > 95% (36/38)
> > 63% (2406/3814)
> > 45% (1009/2256)
> > 
> > src.variableeditor
> > 0% (0/5)
> > 0% (0/5)
> > 0% (0/579)
> > 0% (0/108)
> > 
> > src.view
> >     88% (15/17)
> > 88% (15/17)
> > 57% (3794/6612)
> > 43% (1663/3884)
> > 
> > src.vimode
> > 100% (30/30)
> > 100% (30/30)
> > 81% (1899/2333)
> > 61% (979/1599)
> > 
> > src.vimode.config
> > 0% (0/1)
> > 0% (0/1)
> > 0% (0/120)
> > 0% (0/76)
> > 
> > src.vimode.emulatedcommandbar
> > 100% (13/13)
> > 100% (13/13)
> > 98% (897/917)
> > 90% (588/652)
> > 
> > src.vimode.modes
> > 100% (10/10)
> > 100% (10/10)
> > 87% (3266/3761)
> > 79% (1884/2374)
> > 
> > Links:
> > --
> > [1]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/abi-compatibility-results.yaml [2]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/acc/KF5TextEditor-5.72.0.xml [3]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/compat_reports/KF5TextEditor_compat_report.html [4]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/logs/KF5TextEditor/5.72.0/log.txt


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D28745: Skip caching thumbnails on encrypted filesystems

2020-08-21 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> marcingu wrote in thumbnail.cpp:776
> If st_dev cannot be 0 on successful call of lstat, I don't think there's need 
> to change anything. m_thumbnailDirDeviceId will remain zero only if lstat 
> returns error and as long it's zero sharesFilesystemWithThumbRoot will return 
> false.

I agree with your second sentence. I never said otherwise. It will work, *if* 
indeed we are both right that st_dev would never be 0 when stat() succeeds.
My suggestion is that we make sure our assumption is correct -- at least, that 
we are told if it ever happens to be incorrect, by adding 
assert(baseStat.st_dev != 0) after the first lstat succeeds, and 
assert(fileStat.st_dev != 0) after the second lstat succeeds.

> marcingu wrote in thumbnail.h:93
> On Windows this check is assumed false. So in case encrypted file shares 
> filesystem with thumbnails directory, it can take longer as those won't be 
> cached, but it will work.

Which check? This is a member variable, and I'm not sure the dev_t type will be 
known at all on Windows.
But if you're not sure either, let's wait until CI tells us.

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, 
waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, 
cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, 
navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov


D28745: Skip caching thumbnails on encrypted filesystems

2020-08-19 Thread David Faure
dfaure requested changes to this revision.
dfaure added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> marcingu wrote in thumbnail.cpp:776
> No. The m_thumbnailDirDeviceId is set to 0 and only changed if lstat executes 
> properly. Then it takes value of st_dev. I don't know if st_dev can be 0 
> though and I couldn't find this information in manual either. If it can, we 
> should change it.

I don't see how stat would succeed and st_dev would be 0, but I could be wrong. 
Maybe assert that it's not 0, at least?

> thumbnail.cpp:779
> +if (lstat(QFile::encodeName(m_thumbBasePath).data(), ) == 
> -1) {
> +qCWarning(KIO_THUMBNAIL_LOG) << "Cannot read information about 
> filesystem";
> +return false;

print out the path in the warning (same on line 786)

> thumbnail.cpp:785
> +struct stat fileStat;
> +if(lstat(QFile::encodeName(path).data(), ) == -1) {
> +qCWarning(KIO_THUMBNAIL_LOG) << "Cannot read information about 
> filesystem";

missing space after `if`

s/data/constData/

> thumbnail.h:93
>  qint64 m_maxFileSize;
> +dev_t m_thumbnailDirDeviceId = 0;
>  };

This will break compilation on Windows, I assume?

On Unix, is the corresponding include present in this file? The lack of context 
makes reviewing difficult indeed. Any chance to move this to gitlab? (see 
invent.kde.org)

REPOSITORY
  R320 KIO Extras

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

To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns, dfaure
Cc: dfaure, thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, 
waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, 
cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, 
navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov


Re: KIO on Android Failure

2020-08-19 Thread David Faure
On mardi 18 août 2020 13:52:50 CEST Ben Cooksley wrote:
> Hi all,
> 
> At some point recently functionality was added to KIO which broke the
> build on Android.

Is there any reason why Android doesn't appear at
https://build.kde.org/job/Frameworks/job/kio/
?

This is the reason why I didn't notice this problem.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D26448: Add KRecentFilesMenu to replace KRecentFileAction

2020-08-13 Thread David Faure
dfaure accepted this revision.
dfaure added a comment.


  Thanks :-)

BRANCH
  recentfilemenu

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D26448: Add KRecentFilesMenu to replace KRecentFileAction

2020-08-13 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> krecentfilesmenu.cpp:74
> +{
> +action = new QAction(titleWithSensibleWidth(qobject_cast *>(menu->parent(;
> +QObject::connect(action, ::triggered, action, [this, menu]() 
> {

QMenu is a QWidget. Why not just pass `menu` as argument?
It would use the menu's font which is more correct than the parent widget's 
font (the menu font could be set by a stylesheet or by 
`QApplication::setFont(font, "QMenu")`.

Also `menu` is never null, which simplifies the code in the method being called.

BRANCH
  recentfilemenu

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


Re: Dropping the moderation by default flag

2020-08-11 Thread David Faure
On mardi 11 août 2020 01:02:47 CEST Albert Astals Cid wrote:
> El dimecres, 22 de juliol de 2020, a les 17:47:26 CEST, Volker Krause va 
escriure:
> > On Tuesday, 21 July 2020 21:16:00 CEST 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?
> > 
> > +1. That setup on core-devel was already around in the early 2000s, so
> > probably a response to some events from 20 years ago, I doubt we still
> > need
> > that today.
> 
> So i was going to do it, but I've just realized that I can't, I only have
> the moderator password, not the owner password.
> 
> Please owner[s], can you disable this?
> 
> I *think* it's the "By default, should new list member postings be
> moderated?" in "Privacy options..." -> "Sender filters".

Done.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D26448: Add KRecentFilesMenu to replace KRecentFileAction

2020-08-08 Thread David Faure
dfaure accepted this revision.
dfaure added a comment.
This revision is now accepted and ready to land.


  A unittest would be useful too, especially if we then refactor the loading to 
use KIO jobs.
  
  But after 6 months, let's land this and keep working on it. Are you 
interested in writing the unittest and/or porting to KIO jobs, or do you need 
some help?

INLINE COMMENTS

> krecentfilesmenu.cpp:45
> +}
> +const QFontMetrics fontMetrics = QFontMetrics(QFont());
> +

Can be simplified to

  const QFontMetrics fontMetrics(QFont());

But this uses the application font, not this widget's font. The right thing to 
do would be to pass a QWidget* and use w->fontMetrics() here.

BRANCH
  recentfilemenu

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


kirigami unittests broken

2020-08-06 Thread David Faure
Hi Arjen,

Nice commit series in kirigami, [1] is an impressive list!

However it seems it broke tst_actiontoolbar, please see:
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/kirigami/job/kf5-qt5%20SUSEQt5.12/562/testReport/projectroot.home.jenkins.workspace.Frameworks.kirigami.kf5-qt5_SUSEQt512/autotests/tst_actiontoolbar_qml/

[1] 
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/kirigami/job/kf5-qt5%20SUSEQt5.12/557/
-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE CI: Frameworks » kcoreaddons » kf5-qt5 FreeBSDQt5.15 - Build # 33 - Fixed!

2020-08-06 Thread David Faure
On jeudi 6 août 2020 10:48:19 CEST CI System wrote:
>   BUILD SUCCESS
> Build
> URL   https://build.kde.org/job/Frameworks/job/kcoreaddons/job/kf5-qt5%20Free

\o/

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D26448: Add KRecentFilesMenu to replace KRecentFileAction

2020-08-02 Thread David Faure
dfaure added inline comments.

INLINE COMMENTS

> nicolasfella wrote in krecentfilesmenu.cpp:150
> I'm wondering how to best make this async without selling my soul to the 
> mulitthreading devil. QtConcurrent::filtered looks interesting, but depending 
> on QtConcurrent wouldn't be feasible, would it?

Depending on QtConcurrent is just fine. However QtConcurrent::filtered is for 
CPU-intensive operations, not for I/O operations. 1) you don't want to put 
blocking runnables in the global thread pool [can be solved by assigning to a 
different threadpool], 2) I don't think you really want to parallelize 16 calls 
to QFile::exists, for the case of a local physical harddisk? Not sure it would 
really harm (we're not reading 16 files, at least), but for sure the overhead 
of dispatching runnables to 16 threads would make it slower... One solution 
here might be just a dedicated thread iterating over the list.

However: note that the usual KIO way to do file operations async isn't 
multithreading, it's rather KIO jobs.
This would move the "5 minutes waiting for an NFS server" horror case into a 
kioslave rather than a thread, both achieve the desired outcome which is to not 
block the GUI thread.

Keeping the order of the entries is going to be interesting. I guess we need a 
temporary data structure which stores "exists | does not exist" for each entry, 
and once all jobs are done, we go through that and fill the menu. Note that 
remote URLs should just be assumed to exist, we don't want to actually check 
(slow; might prompt for password; might error on different networks; etc.).

Unlike Kai-Uwe, I think this should be a separate merge request though, it's 
all quite orthogonal to your work. As long as you confirm that filling the menu 
"later" has no negative impact on the API (i.e. the user of the class cannot 
assume that the menu is filled in immediately).

REPOSITORY
  R236 KWidgetsAddons

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

To: nicolasfella, #frameworks, dfaure
Cc: broulik, elvisangelaccio, cfeck, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


kwayland's testRemoteAccess still flaky

2020-08-01 Thread David Faure
https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/kwayland/job/kf5-qt5%20SUSEQt5.12/149/testReport/junit/projectroot.autotests/client/kwayland_testRemoteAccess/

d_ed: looks like https://phabricator.kde.org/D28892 wasn't enough to make it 
fully stable, can you have another look?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: xml_mimetypes5 and kcoreaddons

2020-07-19 Thread David Faure
On mercredi 15 juillet 2020 12:24:34 CEST Harald Sitter wrote:
> On Wed, Jul 15, 2020 at 12:39 AM David Faure  wrote:
> > On mardi 14 juillet 2020 19:35:41 CEST Albert Astals Cid wrote:
> > > El dimarts, 14 de juliol de 2020, a les 15:14:38 CEST, Jonathan Riddell
> > > va
> > 
> > escriure:
> > > > We're playing with translations in neon packages and looking at
> > > > kcoreaddons
> > > > the tars have
> > > > xml_mimetypes5
> > > > But we can't see anything in the code which uses this.  Do these
> > > > translations get used?
> > > 
> > > Yes, the translations are used.
> > > 
> > > No, they don't need to be on the tarball.
> > > 
> > > The translations are used at scripty time to to fill
> > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/mimetype
> > > s/k
> > > de5.xml
> > > 
> > > Luigi recently did a change so the files ending in _xml_mimetypes.po
> > > don't
> > > get added to the release service tarballs.
> > > 
> > > This didn't work here because a) KF5 is using a different branch of
> > > release-tools b) the file doesn't follow the same naming pattern than
> > > the
> > > rest of xml mimetype files we have.
> > > 
> > > If DavidF is fine adapting his scripts to not release files ending in
> > > _xml_mimetypes.po (i.e. him or someone else patches the scripts) i
> > > volunteer to do the small patch for src/mimetypes/XmlMessages.sh to
> > > rename
> > > it.
> > 
> > Fine with me, but don't we have more cases of the same kind, with
> > different
> > names? Any case of translations being "integrated" into some file leads to
> > this. Desktop files, mimetype XML, is there really nothing else?
> 
> It's a bit more "fluid" than one would hope. Looking at
> update_translations the following patterns exist:
> 
> - created by XmlMessages.sh unfortunately arbitrary named files but
> largely using the standard suffix Albert mentioned (the only other
> violation I can find with lxr is kpat)
> - created by StaticMessages.sh also arbitrary, only used for websites
> I think (?)
> - ._desktop_.po automatic - shouldn't be shipped
> - ._json_.po automatic - shouldn't be shipped
> - .appdata.po automatic - shouldn't be shipped
> - .metadata.po automatic - shouldn't be shipped

OK. make_rc_tag.sh already says

find -regextype egrep -regex '.*\.(_desktop_|_json_|appdata|metainfo)\.po' 
-delete

which matches the above, assuming you meant metainfo when writing metadata?

I just changed that regexp to add _xml_mimetypes.po, I hope this solves the 
issue.
https://invent.kde.org/sysadmin/release-tools/commit/ffee07853b586b80236791edd69afc9d9d5dfd8e

Ah, no, Albert still needs to "do the small patch for 
src/mimetypes/XmlMessages.sh to rename it", IIUC.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Frameworks support for Qt 5.12

2020-07-19 Thread David Faure
On mercredi 15 juillet 2020 18:06:40 CEST Nicolas Fella wrote:
> Hi,
> 
> I received a question on how long KF5 will continue to support Qt 5.12.
> 
> Given that 5.12 is an LTS release according to our policy it would be
> supported "until the next Qt release after the next Qt release", which
> would be 5.16, which will never exist.
> 
> Our policy states "With Qt6 this changes a little bit again. To avoid
> supporting 5.12 LTS and 5.15 LTS for ever, 5.15 LTS will be the minimum
> required version 18 months after its release.". This however does not
> answer what will happen with 5.12.
> 
> If I remember correctly our intention when formalizing this was to
> extrapolate the hypothetical releases and apply the existing rules to
> it. This would mean that by the time Qt 5.16 would be released (6 months
> after Qt 5.15) KF5 would drop support for Qt 5.12 and require 5.13.
> 
> Is my interpretation of this correct? If so the wiki page should be
> updated with this information.

Yes. Done:

* Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. on 
26 Nov 2020
* Qt 5.14 will be the minimum required version 12 months after Qt 5.15, i.e. 
on 26 May 2021
* Qt 5.15 LTS will be the minimum required version 18 months after its 
release, i.e. on 26 Nov 2021

https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: xml_mimetypes5 and kcoreaddons

2020-07-14 Thread David Faure
On mardi 14 juillet 2020 19:35:41 CEST Albert Astals Cid wrote:
> El dimarts, 14 de juliol de 2020, a les 15:14:38 CEST, Jonathan Riddell va 
escriure:
> > We're playing with translations in neon packages and looking at
> > kcoreaddons
> > the tars have
> > xml_mimetypes5
> > But we can't see anything in the code which uses this.  Do these
> > translations get used?
> 
> Yes, the translations are used.
> 
> No, they don't need to be on the tarball.
> 
> The translations are used at scripty time to to fill
> https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/mimetypes/k
> de5.xml
> 
> Luigi recently did a change so the files ending in _xml_mimetypes.po don't
> get added to the release service tarballs.
> 
> This didn't work here because a) KF5 is using a different branch of
> release-tools b) the file doesn't follow the same naming pattern than the
> rest of xml mimetype files we have.
> 
> If DavidF is fine adapting his scripts to not release files ending in
> _xml_mimetypes.po (i.e. him or someone else patches the scripts) i
> volunteer to do the small patch for src/mimetypes/XmlMessages.sh to rename
> it.

Fine with me, but don't we have more cases of the same kind, with different 
names? Any case of translations being "integrated" into some file leads to 
this. Desktop files, mimetype XML, is there really nothing else?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE CI: Frameworks » ktexteditor » kf5-qt5 SUSEQt5.15 - Build # 4 - Still Unstable!

2020-07-07 Thread David Faure
On mardi 7 juillet 2020 17:58:26 CEST Christoph Cullmann wrote:
> On 2020-07-07 12:16, David Faure wrote:
> > Yep :(
> > 
> > You'll tell Simon and/or QTBUG-*?
> 
> I will take a look if I can find some existing bug or open a new.
> 
> Simon left Qt, or?

Yes but I think that was already the case when he fixed the last one :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: KDE CI: Frameworks » ktexteditor » kf5-qt5 SUSEQt5.15 - Build # 4 - Still Unstable!

2020-07-07 Thread David Faure
% (0/184)
> > 
> > src.document
> > 100% (4/4)
> > 100% (4/4)
> > 61% (1936/3179)
> > 48% (1407/2945)
> > 
> > src.export
> > 0% (0/4)
> > 0% (0/4)
> > 0% (0/121)
> > 0% (0/156)
> > 
> > src.include.ktexteditor
> > 78% (14/18)
> > 78% (14/18)
> > 83% (189/227)
> > 55% (125/226)
> > 
> > src.inputmode
> > 100% (8/8)
> > 100% (8/8)
> > 63% (192/304)
> > 51% (39/77)
> > 
> > src.mode
> > 88% (7/8)
> > 88% (7/8)
> > 36% (378/1051)
> > 16% (146/891)
> > 
> > src.part
> > 0% (0/1)
> > 0% (0/1)
> > 0% (0/7)
> > 100% (0/0)
> > 
> > src.printing
> > 0% (0/4)
> > 0% (0/4)
> > 0% (0/862)
> > 0% (0/278)
> > 
> > src.render
> > 100% (8/8)
> > 100% (8/8)
> > 77% (950/1227)
> > 67% (610/914)
> > 
> > src.schema
> > 22% (2/9)
> > 22% (2/9)
> > 1% (19/1472)
> > 1% (6/625)
> > 
> > src.script
> > 94% (16/17)
> > 94% (16/17)
> > 67% (699/1040)
> > 53% (212/403)
> > 
> > src.search
> > 100% (7/7)
> > 100% (7/7)
> > 74% (/1503)
> > 63% (590/932)
> > 
> > src.spellcheck
> > 50% (4/8)
> > 50% (4/8)
> > 7% (82/1207)
> > 3% (19/696)
> > 
> > src.swapfile
> > 50% (1/2)
> > 50% (1/2)
> > 32% (119/374)
> > 32% (64/203)
> > 
> > src.syntax
> > 88% (7/8)
> > 88% (7/8)
> > 64% (488/761)
> > 36% (206/576)
> > 
> > src.undo
> > 100% (5/5)
> > 100% (5/5)
> > 88% (652/741)
> > 73% (276/378)
> > 
> > src.utils
> > 95% (36/38)
> > 95% (36/38)
> > 63% (2406/3814)
> > 45% (1009/2256)
> > 
> > src.variableeditor
> > 0% (0/5)
> > 0% (0/5)
> > 0% (0/579)
> > 0% (0/108)
> > 
> > src.view
> > 88% (15/17)
> >     88% (15/17)
> > 57% (3794/6612)
> > 43% (1663/3884)
> > 
> > src.vimode
> > 100% (30/30)
> > 100% (30/30)
> > 81% (1899/2333)
> > 61% (979/1599)
> > 
> > src.vimode.config
> > 0% (0/1)
> > 0% (0/1)
> > 0% (0/120)
> > 0% (0/76)
> > 
> > src.vimode.emulatedcommandbar
> > 100% (13/13)
> > 100% (13/13)
> > 98% (897/917)
> > 90% (588/652)
> > 
> > src.vimode.modes
> > 100% (10/10)
> > 100% (10/10)
> > 87% (3266/3761)
> > 79% (1884/2374)
> > 
> > Links:
> > --
> > [1]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/abi-compatibility-results.yaml [2]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/acc/KF5TextEditor-5.72.0.xml [3]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/compat_reports/KF5TextEditor_compat_report.html [4]
> > https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20SUSEQt5
> > .15/4/artifact/logs/KF5TextEditor/5.72.0/log.txt


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D14631: Adds a new RenameDialog to KIO with more options for batch renaming

2020-07-06 Thread David Faure
dfaure added a comment.


  Only if you can find a way to change BatchRenameJob in a binary and behaviour 
compatible way. And then it will be a dual-headed thing with two modes of 
operations, awful. All this sounds to me like much more trouble than writing a 
different job.

REPOSITORY
  R241 KIO

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

To: emateli, #frameworks, dfaure, mlaurent, meven, #dolphin
Cc: luco, nicopons, meven, chinmoyr, mlaurent, asensi, rkflx, dfaure, aacid, 
ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns


Re: ThumbSequenceCreator in KIO not working properly

2020-07-04 Thread David Faure
On samedi 4 juillet 2020 12:57:04 CEST David Lerch wrote:
> I have not been able to find out if DelegateAnimationHandler is even being
> used during thumbnail generation. 

It seems to be used by KFileItemDelegate (and nothing else) :
https://lxr.kde.org/ident?_i=DelegateAnimationHandler&_remember=1

KFileItemDelegate itself is use by KDirOperator
https://lxr.kde.org/ident?_i=KFileItemDelegate

Dolphin unfortunately has its own model/view stuff (e.g. for the animations 
where icons move around).

I suggest testing with the file dialog (which uses KDirOperator)
and asking the Dolphin people on kfm-devel about how Dolphin could be changed 
to use DelegateAnimationHandler, possibly?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





inotify on FreeBSD

2020-07-04 Thread David Faure
Hello Tobias,

your commit 59db8a5ea2241927 in kcoreaddons enabled inotify support on FreeBSD
3 years ago, but I wonder if it's a good idea? According to the FreeBSD CI [1],
inotify support on FreeBSD is either suboptimal or at least different from 
inotify support on Linux:
many tests fail, while they all pass on Linux.

I wonder if the other backends (QFSWatch, Stat) wouldn't be better suited on 
FreeBSD,
since those actually work fine according to the FreeBSD CI.

Unless someone is willing to debug what's happening with inotify on FreeBSD, 
how about we disable the inotify backend on FreeBSD?

[1] 
https://build.kde.org/job/Frameworks/view/Platform%20-%20FreeBSDQt5.15/job/kcoreaddons/job/kf5-qt5%20FreeBSDQt5.15/9/testReport/projectroot/autotests/kdirwatch_inotify_unittest/

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Shift for parts of the CI system to Qt 5.15

2020-06-21 Thread David Faure
On samedi 20 juin 2020 12:25:42 CEST Ben Cooksley wrote:
> - ktorrent (when linking with taglib)

Looks like the fix I made to fix ktorrent (failing to link with taglib) also 
fixed the FreeBSD issue you mention.

https://build.kde.org/job/Extragear/job/ktorrent/job/kf5-qt5%20FreeBSDQt5.15/

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Add loop device interface to Solid framework

2020-06-13 Thread David Faure
On dimanche 7 juin 2020 20:10:11 CEST Kwon-Young Choi wrote:
> Hello,
> 
> I have recently made a plugin for dolphin to mount and unmount iso
> files: https://invent.kde.org/sdk/dolphin-plugins/-/merge_requests/1
> 
> This plugin uses DBus calls to directly communicate with UDisks2 to
> attach and detach a loop device backed by an iso file.
> While writing the plugin, I used to Solid framework to do some hardware
> query and realized that there was no concept of loop device in Solid.
> I would like to know if there is interest to add a loop device interface
> to Solid and the ability to attach and detach such device?
> 
> I'm starting to understand the architecture of Solid and I think I would
> be able to add:
> 
> * an abstract Loop DeviceInterface
> * a backend Loop DeviceInterface backed by UDisks2
> * a frontend Loop DeviceInterface
> * the ability for the DeviceManager to create a Loop DeviceInterface
> (I'm not sure this is possible...)
> 
> However, I am not sure if this fit in the score of the Solid framework.

I wish there was a Solid maintainer to answer you...

However for such an architectural/scope question, maybe ervin will be willing 
to provide some input :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





D26342: Allow overriding to disable auto language detection

2020-06-13 Thread David Faure
dfaure added a comment.


  In D26342#675180 , @aacid wrote:
  
  > In D26342#675164 , @sdepiets 
wrote:
  >
  > > I don't think that's a regression, in the previous behavior you could try 
to set any language to proofread, it would always auto-detect "Bonjour" as 
French, thus the "Tools / Spelling / change language" had not effect if 
autodetect was enabled at system level (while autodetection should be an 
application or even case by case decision).
  >
  
  
  Autodetection *is* an application setting, it's in Settings / Spellchecker... 
/ [x] Enable autodetection of language
  
  >> It may not seem like an issue for simple cases, but actually for mixed 
contents (i.e. an email that is 50% French, 50% English) that would be detected 
as English, you would have no way at all to check the French text without 
disabling system-wide autodectection.
  
  In my experience a mixed email was perfectly handled, with each paragraph 
having a different language.
  See http://www.davidfaure.fr/2020/Screenshot_20200613_194827.png
  
  But I think you're talking about the spellchecking dialog (which I never use, 
except this month because of the need to find a workaround).
  My concern is for autodetection and background spellchecking. If a fix for 
the spellcheck dialog introduces a change of behaviour for the background 
spellchecking, that's a regression.
  
  >> Calling setAutoDetectLanguageDisabled(false) restores the previous behavior
  
  Changes in KF5 should NOT require applications to adapt in order to restore 
previous *working* behaviour.
  
  > The problem here is that David probably never set any language on purpose.
  
  Right.
  In fact, if I open the settings dialog, it has "français" checked in the top 
listview, and only that one.
  Meanwhile the Tools / Spelling dialog shows "American English (UnitedStates)" 
in the combobox.
  This particular issue happens even with this patch reverted. Something's 
rather broken.
  
  > you could argue that this is a deficiency of the UI, should have a checkbox 
for "enable spellchecking" and another for "enable spellchecking *exactly* in 
this language"
  
  Not sure I understand this.
  
  > And this is were we failed, we changed the default behaviour and that's 
probably not the greatest of the ideas in retrospect. Even if we could not see 
why anyone would set a language and would still want the auto language 
detection to be enabled, well it seems that at least David wanted because it's 
been the behaviour for ages :D
  
  *I* don't really set a language. Maybe KMail does though. @mlaurent might 
know more?

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig, aacid
Cc: dfaure, aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D26342: Allow overriding to disable auto language detection

2020-06-13 Thread David Faure
dfaure added a comment.


  This actually breaks language auto-detection for me in the KMail composer.
  
  Testcase:
  
  - New Mail
  - I type "Bonjour," in the body
  
  Before:
  It's detected as French and not underlined as a typo
  
  After:
  The language remains English, and the word is underlined as a typo
  
  Workaround:
  Tools / Spelling / change language from English to French
  
  Too bad I'm realizing this is the reason for the regression only today (day 
of 5.71 release) by looking at the KF-5.71 changelog :(

REPOSITORY
  R246 Sonnet

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

To: sdepiets, #frameworks, cullmann, mlaurent, mludwig, aacid
Cc: dfaure, aacid, mludwig, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


  1   2   3   4   5   6   7   8   9   10   >