minimal kcm Ui wallpaper MR: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3395

Backend work started at https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3122

In T13590#295618, @dfaure wrote:

The first 4 should move to KService too, IMHO.

KRecentDocument is the main problem.

In Plasma Sprint 2023 we agreed we want to achieve this (https://invent.kde.org/plasma/plasma-desktop/-/issues/89)

In D14895#683521, @alanjds wrote:

In D14895#683516, @meven wrote:

Feel free to send a MR, and include more context please.

Sorry my ignorance. What "MR" stands for, in this context?

Feel free to send a MR, and include more context please.

In T14538#287784, @alex wrote:

As far I can tell, its only user is KFileWidget which has never a "m_fileclass" set which is necessary for its feature to work.

that is not true, please see the code in KFileWidgets:
QUrl KFileWidget::getStartUrl(const QUrl &startDir, QString &recentDirClass, QString &fileName)
Here we get the value by reference and assign it within the function.

KRecentDirs seem like an old features that can be removed.
As far I can tell, its only user is KFileWidget which has never a "m_fileclass" set which is necessary for its feature to work.

KAbstractFileItemActionPlugin and KFileItemActions should be considered as well then.

In T15158#269177, @vkrause wrote:

I can reproduce what Ahmad sees here (self-compiled Qt 6.3).

With the following changes it passes the D-Bus part and gets stuck, ie. I can also reproduce what David sees.

diff --git a/src/gui/systemd/dbustypes.h b/src/gui/systemd/dbustypes.h
index 81bc1a070..4cabc620e 100644
--- a/src/gui/systemd/dbustypes.h
+++ b/src/gui/systemd/dbustypes.h
@@ -34,7 +34,7 @@ inline const QDBusArgument &operator>>(const QDBusArgument &argument, QVariantMu
     return argument;
 }

-using ExecCommand = struct {
+struct ExecCommand {
     QString path;
     QStringList argv;
     bool ignoreFailure;
@@ -59,7 +59,7 @@ inline const QDBusArgument &operator>>(const QDBusArgument &argument, ExecComman
     return argument;
 }

-using TransientAux = struct {
+struct TransientAux {
     QString name;
     QVariantMultiMap properties;
 };

https://invent.kde.org/frameworks/kio/-/merge_requests/1099

Doing in earlier is possible and will reduce the amount of work done in one go when folding SlaveBase into WorkerBase.
This is the most advanced worker, it makes sense to pay extra care to it.

https://invent.kde.org/frameworks/kio/-/merge_requests/1099

rg "plasma.components 2"
applet/contents/ui/PopupDialog.qml
9:import org.kde.plasma.components 2.0 as PlasmaComponents // for Highlight

In D20532#675987, @elvisangelaccio wrote:

Here's a recap. I might accept the patch if:

1. The double-click triggers a single action. Could be "Go Up" like requested in the past or could be "Select All" like suggested on reddit. We should carefully choose which action to use.
2. The double-click does not trigger the action if the user misclicks an item, because that would be very annoying. An easy solution could be to only enable the feature in single-click mode. Proper solution would be to check whether the double-click happens near an item, for some definition of near.

In D20532#647548, @emvaized wrote:

@elvisangelaccio
Please make it happen. This feature is very useful - especially middle button click on empty space, which can be assigned to "Paste file" function, as mentioned above.

In T12214#270507, @dfaure wrote:

I made some more progress with this, adding a WorkerFactory base class and making kio_file's plugin QObject implement that, to create FileProtocol instances in-process.

Something I just realized: one thing we'll lose when using threads instead of processes is the ability to completely kill a running slave. Threads can't and mustn't be killed/terminated, so I guess the best thing we'll be able to do, when killing a job, is to disconnect from the worker object and let it finish its course. For some cases where it'll be worth it, like aborting large downloads/copies, we should of course then add an atomic bool, and check it in the main while loop. In separate-process mode, that bool will just never be set to true.

In T15023#266399, @alex wrote:

Not sure about this belonging to the KF6 board, libexiv2 is not a framework and the deprecation is not from KF, but the Qt side of things.

https://lxr.kde.org/ident?v=stable-kf5-qt5&_i=KDiskFreeSpaceInfo&_remember=1 is a lot thinner now, no KIO or plasma-workspace apart from kdiskfreespaceinfo itself thanks to @ahmadsamir

In T11540#265010, @alex wrote:

@meven Why did you close the task? It is marked as done/announced already

In T12155#239277, @fabiank wrote:

That won't happen for Qt 6.0, as nobody had the time to do the necessary work in QIcon/QIconEngine, but maybe it can be done before 6.2.

Found some hints how to help the kernel manage its buffers and page cache efficiently when writing
http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html
http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01953.html

I have a first step : split to two loops use copy_file_range

Would be great to continue this.

The io_uring cp example is a good reference to make use of the API.
https://github.com/axboe/liburing/blob/master/examples/io_uring-cp.c

copy https://github.com/coreutils/coreutils/blob/master/src/copy.c#L301 use https://man7.org/linux/man-pages/man2/copy_file_range.2.html or https://github.com/coreutils/gnulib/blob/master/lib/full-write.h
Did not know about copy_file_range, it was introduced in kernel 4.5 and improved/reworked in 5.3 apparently.
It is simply newer than sendfile (but older than io_uring), it seems to be just almost a drop-in replacement for sendfile with reflink aka COW support for supporting fs built-in.
That should be the next area for investigation, it is way simpler than our current reflink support, but it is Linux only.

If you don't want to maintain an option in the UI - cause the amount of people using it - why not just add it to the config file. I would say, that the default does not really matter. Both solutions are working somehow, and most people won't notice the difference.

Quoting https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1026#note_296711

Lessons learned:

In T14839#262824, @Guilhermems wrote:

In T14839#262757, @meven wrote:

Other kcms could be reviewed/improved as well, in particular, Kwin, plasma-nm, plasma-pa, baloo

We already have new keywords for all settings present in SS (it's in the shared Google document on the task), the problem is that we're not familiar with the KDE repositories. Do you know where the .desktop files for those KCMs you mentioned would be?

Edit: I found the right projects on GitLab. I'll see what I can do.

Other kcms could be reviewed/improved as well, in particular, Kwin, plasma-nm, plasma-pa, baloo

In T14840#262669, @ngraham wrote:

On second thought, probably not worth the trouble. We can always re-evaluate what lives where for Plasma 6.

See https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/58 to deprecated those marking them TODO KF6 delete

In T12480#259150, @alex wrote:

@meven So far those methods have not been deprecated, is this intentional?

In D29115#677664, @harogaston wrote:

Finally merge request opened at https://invent.kde.org/system/dolphin/-/merge_requests/203

I have opened https://invent.kde.org/system/dolphin/-/merge_requests/193 that rebased those changes.

In T12214#248188, @cfeck wrote:

Would this mean that if Dolphin crashed during file operations, the operation could no longer be completed, and leave partial files?

Btw For KF6 I was hoping to replace our KRecentDocument implementation with one implementing the freedesktop "~/.local/share/recently-used.xbel" for increased compat with GTK (and lighter KActivitiesStat daemon).

https://invent.kde.org/frameworks/kio/-/merge_requests/381/diffs

also available in Qt we now have QStorageInfo

A bit related https://phabricator.kde.org/T12285 move KTextWidgets to KIOExtras

@davidedmundson I guess you meant https://lists.freedesktop.org/archives/wayland-devel/2016-February/027209.html

I assume you would want this panel to be off by default?

Not a fan of this, my opinion would be to use a panel instead, what older versions of dolphin did.
This is reported as bug https://bugs.kde.org/show_bug.cgi?id=411500

In D21937#677041, @elvisangelaccio wrote:

In D21937#497112, @meven wrote:

In D21937#496989, @elvisangelaccio wrote:

Sorry, I missed this one. I'd say let's postpone to 19.12...

No worries

Also we might want to discuss it a bit more, folder moving :

A limitation of the current patch is when a folder is moved, the settings are lost.
I can imagine two potential solution :

• a "bazooka" solution : use inotify and consort to have the settings follow the files.
• a simple solution : use inode id as path in destinationDir for local files. That way if a folder is moved its settings follow. Although it won't survive network moves.

A third solution would be to store the view settings in an extended attribute on the folder itself. That wouldn't survive copying to or from filesystems that don't support xattrs though.

Not sure what to do here, honestly.

• bazooka solution: sounds dangerous. And what if inotify is not available?

This is not the way to do it. I think the proper way will be to implement the feature in the kioworker recentlyused similarly to TrashProtocol::special.

In D29525#677057, @elvisangelaccio wrote:

Superseded by https://invent.kde.org/system/dolphin/-/merge_requests/147

@meven Can you abandon this one?

@dfaure should be consulted for this.

I remember @dfaure explored this idea at KIO bof in akademy 2019.

I'd rather have a proper panel as the information panel, folder panel, folder panel...
So that user can hide it, or move it, and for general consistency/ having a proper alignment with minimal overflow.

With the xdg spec now covering this use case https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/40
I have reworked this into https://invent.kde.org/frameworks/kio/-/merge_requests/266

Specification work is so slow I am hesitant to bypass it for now and work on code, even if it means resync with spec later.
https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/35

There no blockers anymore, providing there no conflict, we could land this as-is after a rebase.

In D23866#557830, @svuorela wrote:

In D23866#553108, @mlaurent wrote:

Ping ? What is the status ?:)

I'll be happy if someone else takes over. I'm still a bit hung up on other stuff. Don't expect much from me on this before christmas.
/Sune

ping @nicolasfella

I quite like the idea.

In D22846#676700, @bam wrote:

Does it mean we now have to manually synchronize DBus API here in .xml and on KWin side?

@papoteur
Do you realize your email is already pretty-much public on bugzilla and it contains your name ?

I think this can be abandonned after https://invent.kde.org/system/dolphin/-/merge_requests/89 landed.

In D27181#676686, @papoteur wrote:

In D27181#676685, @meven wrote:

I am not sure we can use a nickname as author because of licensing.

Why not?
Copyright protects the rights of the author. On one side, patrimonial rights allow to give him money, but with open source licence, the author says that he waives to them.

In D27181#676663, @papoteur wrote:

Hello all,
Is there someone to commit this change?
Papoteur

In T13590#239321, @dfaure wrote:

The main problem I see is the KRecentDocuments integration.

In T9579#240811, @emvaized wrote:

Just tried current 'exe' build and decided to share a little feedback here.

Looks very-very cool and promising!
The issues I found:

Moved to https://invent.kde.org/frameworks/kio/-/merge_requests/174

In D29282#676586, @czeidler wrote:

I am the author of D29550 which adds supports for a post capture selection option for already taken screenshots. D29550 is currently blocked by this patch.

After giving it a good thought, I see the following general problems with the existing rectangular region capture mode:

1. It doesn't work when trying to capture open menus. At least on X11, menus close when doing the capture.
2. By supporting different screen scales, the QuickEditor code becomes very complex. I wouldn't feel comfortable applying a patch while keeping all the screen scaling in mind. I would have to invest quite some time to get a deep understanding of the scaling problem and even then I doubt I could make changes without introducing any new issues, which brings me to the next point.
3. Testing, how do we test any changes? With X11, Wayland, scaling factors, monitor positions and X QuickEditor features there seem to be too many combinations to test properly. Especially, I don't see a reliable and easy way to automate these kind of tests.
4. All the hard bits of translating real screen position to window positions which is already done by the display server needs to be redone in QuickEditor (more or less). Not really a problem but also not a nice thing to do.
   
   For this reason I suggest the following approach: a) Compose the screen capture(s) into a single pixmap as it is done already. b) Drop support for rectangular region capture mode in favour of the post selection mode in D29550 which operates on this pixmap.
   
   This has the advantage that a) and b) are completely decoupled. How the pixmap is composed can easily be changed and screen scales can be applied as desired. QuickEditor stays relatively simple and straightforward to modify.

Replaced by https://invent.kde.org/graphics/spectacle/-/merge_requests/29

In D29526#676386, @bruns wrote:

For all but text the DPR is completely irrelevant, large@1 is identical to normal@2.

@alex should be interested in this.