Discussion moved to https://invent.kde.org/system/dolphin/-/issues/36.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 11 2024
Dec 8 2022
Nov 4 2022
We've decided instead to alert distros to pre-install these repos, rather than consolidate them and make them mandatory. See https://community.kde.org/Distributions/Packaging_Recommendations.
Jul 10 2022
I don't think volunteers can fix this problem. However, volunteers might be able to understand that there is a problem.
Jul 9 2022
In T12308#278016, @vkhatab wrote:For the love of god people
[...]
sorry if this sounds hostile - as a dedicated KDE user I mean well
Dolphin still doesn't look anything like this and even that cyan border is still there. While I understand the need to redesign a major app, all the other QT apps look just as bad or worse. A lot of this is down to the theme engine. There's been some kind of theme change recently but it hasn't made anything better - arguably worse by blending in the titlebar with the window chrome without making the whitespace in the chrome actually act like a titlebar. For the love of god people, please take the well thought out platforms as your point of reference - Windows 95, Mac OS, even Gnome ... anything. (sorry if this sounds hostile - as a dedicated KDE user I mean well).
May 17 2022
Feb 5 2022
In D20532#679477, @meven wrote:From Elvis (dolphin maintainer):
The original patch had problems too, but if someone wants to improve it feel free to work on it.
In the context it would be this diff here.
So it just depend on contribution.
There are been demand for this feature enough that Elvis, Nate or me would accept a patch as long as it is configurable.
In D20532#675987, @elvisangelaccio wrote:Here's a recap. I might accept the patch if:
- 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.
- 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.
Feb 4 2022
Aah, a pity that is has been abandoned. For Windows, there is an explorer addon called QTTabbar which has exactly this function (going up on double-click) and I never thought, that such a small thing could increase my workflow that drastically. It would have been very nice to see this in Dolphin. Anyhow, thanks for the effort.
Jan 23 2022
This is done now in Dolphin 22.04! See https://invent.kde.org/system/dolphin/-/merge_requests/309
Jan 6 2022
"http://phabricator.kde.org/T11663#212651" is my favourite, because which path is for which tab is obvious. Having the bar dynamically adjust is not intuitive, and if many tabs are present, is able to inhibit productivity if the user is duplicating multiple paths to their clipboard.
Nov 25 2021
Nov 24 2021
Oct 18 2021
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
Oct 13 2021
I have a first step : split to two loops use copy_file_range
Oct 5 2021
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
Oct 1 2021
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.
Sep 17 2021
but I'm strictly against doing it for kio/kio-extras
Are there any movements of merging dolphin/dolphin-plugins?
Jul 2 2021
May 31 2021
May 14 2021
No consensus; closing.
Apr 27 2021
Abandoned in favor of https://invent.kde.org/system/dolphin/-/merge_requests/203
In D29115#677664, @harogaston wrote:Finally merge request opened at https://invent.kde.org/system/dolphin/-/merge_requests/203
Finally merge request opened at https://invent.kde.org/system/dolphin/-/merge_requests/203
Apr 20 2021
Another possibility of integrating KIO directly into Windows would be through cfapi: https://docs.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine
Apr 19 2021
Apr 16 2021
In T9579#250279, @andriusr wrote:Another possibility I've still not checked would be integrating kio-fuse into Dokany's FUSE wrapper, I don't know how complex it'd be or even if it's stable, but in this way the KIOs could be shipped independently.
Apr 15 2021
I see, thank you very much for your hard work!
The issue was introduced recently I currently rebuild the cache to fix the issue, it should be gone in the next couple of days.
I hope this is the proper place to ask about this:
I downloaded the latest artifact and installed it.
Problem is, it always complains about expat.dll, see screenshot:
Tell me if any more info is required, or if this issue is not related to the program and instead lies in my Windows installation.
Apr 8 2021
I have opened https://invent.kde.org/system/dolphin/-/merge_requests/193 that rebased those changes.
Apr 7 2021
@elvisangelaccio what do you think we should do with this old but very nice 95% completed patch?
Mar 15 2021
fwiw I'm not even against merging dolphin and dolphin-plugins in particular, but I'm strictly against doing it for kio/kio-extras
I guess the path forward is to do a better job of specifying these relationships in CMake, then.
Mar 12 2021
It will make building harder due extra dependencies early in the build chain
In T13631#251183, @ngraham wrote:You want packaging changes, not source changes
That's kind of the problem; some distros don't do the right thing here, and contacting every distro is not really feasible. Yes, you can say, "well X distro does it right, people should just use X distro", but that's not a realistic perspective given that we encourage our software to be widely packaged. The perspective I'm coming from is that of trying to improve the user experience for all of our users, not just those who choose distros that are well-packaged. I see the fact that our software can be mis-packaged as a problem in the first place.
The only real way to stop that is to start embracing flatpaks and snaps.
Mar 10 2021
Distributions do split stuff as they feel like, even when we put everything into one source. e.g. on debian kdeplasma-addons is split into 7 binary packages, I am not sure why, meanwhile kio-extras is split in two (with thumbnailers and slaves being in the same .deb, mind you).
Being able to mispackage is a fact of life in free software. The only real way to stop that is to start embracing flatpaks and snaps.
You want packaging changes, not source changes
I don't think debian maintaners will do this, https://invent.kde.org/sdk/dolphin-plugins is separate repository, and i want dolphin-plugins be merged in dolphin, so all distros will benefit from this.
Mar 9 2021
@soredake - You are barking up the wrong tree. You want packaging changes, not source changes, i.e. install the plugins as soon as dolphin is installed. Talk to your distro maintainers to make this happen.
I don't see what wrong with merging dolphin-plugins into main dolphin, git integration is useful for devs, dropbox integration is useful for all, "mount iso" should be available by default too, like in windows/macos.
In T13631#250934, @soredake wrote:Hi, I've recently created this with proposal of merging dolphin-plugins to dolphin. What's the status of this?
Mar 8 2021
Pulling e.g. the thumbnailers into kio is a complete no-no. They have all kinds of third-party dependencies.
Mar 7 2021
Hi, I've recently created this with proposal of merging dolphin-plugins to dolphin. What's the status of this?
Feb 24 2021
Cool, thanks! Can you go to Add Action > Abandon?
Here's the new merge request: https://invent.kde.org/network/kio-extras/-/merge_requests/75
Feb 23 2021
OK great! Thanks for your patience through this very long process. :)
In D28745#677439, @ngraham wrote:Is this unblocked now that https://invent.kde.org/frameworks/solid/-/merge_requests/19 has been merged?
Is this unblocked now that https://invent.kde.org/frameworks/solid/-/merge_requests/19 has been merged?
Why would we need fuse on Windows?
Feb 22 2021
In T9579#250279, @andriusr wrote:Hi, I was an avid user of Dolphin on KDE4 times, I'd like to share some thoughts ...
My main use case was browsing remote (sftp) files and opening them in Kate. Since at that time all the KDE environment was shared (plug-ins, kio etc.) it was fantastic to work that way! So, first of all, for Dolphin and for other apps I think we should always ship them with a common set of KIOs. I understand that individual app installers are the new way since KF5, but maybe we could think about packaging some sets of apps as a bundle.
Hi, I was an avid user of Dolphin on KDE4 times, I'd like to share some thoughts ...
Feb 9 2021
Feb 4 2021
Feb 3 2021
Hi all!
Jan 18 2021
For reference, this is the task about improving single click which also contains the ideas for selection control: https://phabricator.kde.org/T9895
I just had another look at index and I have to say their solution is probably the better orientation guide than my mockups, as it is much more mature with some nice UX solutions (like the x for "clear selection"):
I assume you would want this panel to be off by default?
Why would you assume that ?
I assume you would want this panel to be off by default?
Jan 17 2021
use a panel instead
Jan 15 2021
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
Jan 14 2021
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?
Jan 13 2021
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?
Jan 11 2021
In D29115#677038, @elvisangelaccio wrote:In D29115#663669, @harogaston wrote:In D29115#662313, @elvisangelaccio wrote:You said it yourself: every setting needs a good amount of clutter code, which makes the overall codebase harder to test and harder to maintain. That's why we try to avoid adding a new setting every time we add a new feature.
We can reconsider if enough people complain about this new behavior not being optional.
So is that a let's go with it? I'm sorry I'm kinda lost as per what you want to do exactly (if anything at all), I don't have much of a say here. My opinion I already gave.
Sorry for the delay. Yes, please remove the option and make the new behavior the default.
You may also want to move this patch to gitlab: https://invent.kde.org
Jan 9 2021
(I kind of was but these plans always get postponed when I spot something I deem more important to work on. Right now it is in the "maybe eventually perhaps I might get to it" category. It would have been higher up if I had gotten more positive feedback but even then not within two month.)
Jan 8 2021
Alright! (I also was not entirely sure before whether you planned on implementing this)
Jan 7 2021
I don't think there is a point in voting because anyone can already voice their opinion here if they want to. The person implementing this will also spend more time on this than either of us did so they don't necessarily have to be confronted with final decisions anyway especially because sometimes new aspects or problems are discovered while working on it. I am fine with working on other things for now.
Jan 3 2021
I guess it comes down to personal weighting of the different aspects, then. Also thanks for mentioning some downsides, as I have not thought about some of them.
I basically thought that because these options would only show up on selection of items that it might be interesting to have them floating indicating the non-permanent state of them.
@meven has this been moved to commandeered and moved to Gitlab? I think you can safely do so if you haven't as the original author never replied.
Jan 1 2021
@cblack Thanks for mentioning that. No, it was not directly taken from it. In fact I never heard of index before and I just found it googling around, so linking a medium post for reference (guessing this is the one you meant): https://medium.com/@temisclopeolimac/index-overview-b2ddcb16534f. The images in that post show even some more interesting concepts for overlays, though.
Dec 29 2020
Dec 28 2020
Sorry for the delay.
Patch looks good beside the inline comment. @alexmi Can you fix it?
Merged with b339ac1b5f22efb57619c738eb39268c3e00948d
Given that nothing happened in 3 years and that kio-stash (sadly) is still not very popular, I'm going to merge this patch.
Closing since this is superseded now.
Closing.
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.
In D25651#580566, @meven wrote:In D25651#570894, @ngraham wrote:This doesn't seem to work for me. When I click on the new menu item, the view refreshes but the item I told it to forget it still visible in the ioslave.
Unfortunately the
In D25651#570894, @ngraham wrote:This doesn't seem to work for me. When I click on the new menu item, the view refreshes but the item I told it to forget it still visible in the ioslave.
I may be due to the asynchronous nature of KActivities::Stats calling dbus and sqlite.
I will see what I can do to improve on the situation.
In D29115#663669, @harogaston wrote:In D29115#662313, @elvisangelaccio wrote:You said it yourself: every setting needs a good amount of clutter code, which makes the overall codebase harder to test and harder to maintain. That's why we try to avoid adding a new setting every time we add a new feature.
We can reconsider if enough people complain about this new behavior not being optional.
So is that a let's go with it? I'm sorry I'm kinda lost as per what you want to do exactly (if anything at all), I don't have much of a say here. My opinion I already gave.
Dec 27 2020
This is the presentation used by Index and I wouldn't be surprised if this idea is directly taken from it.
Seems like it would be useful to show on devices with a touch screen.