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

In T13631#240328, @alex wrote:

dolphin plugins that solely target developers

That also has mountiso and dropbox plugins, these are not just for developers

dolphin plugins that solely target developers

In T13631#240302, @ngraham wrote:

I don't try to nanny our users into accepting all those extra dependencies.

You're a Gentoo packager, right? My concern here is for users who want things to just work out of the box, not users of distros geared towards technical experts. That's a different problem space. :)

By far not everyone of our users is an expert, and I don't see the numbers to back this up as a huge problem yet. There sure has been the odd forum thread about missing stuff, but through our KDE Wiki it is common knowledge that users are supposed to use the plasma-meta package and that settles it real quick. Is it really beginners who randomly install the minimal plasma-desktop package (if they do, why?) rather than following the distro's Wiki, or is it the tinkerer who doesn't own up to hunting for features manually after going the minimal route? How many distros get it actually wrong, can it be improved by adding RUNTIME infos to cmake? Where are those bug reports you see coming from? Those are the questions before establishing this as a problem we need to fix by lumping repositories together. And that would change it for something like Arch where binary packages are not often being split, but not for others like Debian where the amount of binary packages may not even change except where they pull their sources from.

I agree with moving the runners, but it is also planned to introduce some new APIs so that the Kate/Konsole profiles runners can be replaced and are provided within the Kate/Konsole apps themselves. For the remaining runners it makes totally sense.

I don't try to nanny our users into accepting all those extra dependencies.

From me also a -1, mostly because of the dependency tree. Stuff like ffmpeg and Samba have a *huge* dependency tree.

In T13631#240269, @ngraham wrote:

I have seen many bug reports and user frustrations whose root cause was not having these packages installed--whether due to bad distro defaults or not knowing about them when using Arch or Debian. We can bug distros to have better defaults and write better documentation and such, but merging their functionality into other repos eliminates the whole class of bug altogether. That's a win IMO.

stuff in *-extras is not core functionality but provides additional features that one may or may not want to use

Distros can fail to pre-install them in their Plasma packaging, leading to users missing content and having a sub-optimal user experience

Sure, distros make mistakes too, but that kind of mistake is easy to address downstream

Users of DIY distros like Arch or Debian can fail to install them and wind up missing content and having a sub-optimal user experience

That's the price you needs to pay for using such a distro. You need to think about what to install. Following the logic of why some people prefer this kind of distro one can argue that some people do not install these extra packages on purpose.

Reduces the clarity of the software's status: Is this stuff core functionality or not? On the one hand, it's hosted on KDE infrastructure and tracked on KDE's Bugzilla. But on the other hand, it's possible to not install it

How is merging it clarifying anything? Right now the status is pretty clear IMO: stuff in *-extras is not core functionality but provides additional features that one may or may not want to use

On the flip side, I see no major advantages to having stuff split into these extra repos.

For a framework like KIO I made my point above. A similar point can be made for Plasma too. Plasma is used as a base for various embedded products (Plasma Mobile, Mycroft, Plasma Bigscreen, kiosk deployments. I've also seen kwin used as a standalone window manager in commercial products). For these kinds of projects it is beneficial to be able to deploy a core-only version of our product since stuff like installation size does matter.

In T13631#240230, @ngraham wrote:

I remember hearing about a proposal to move ApplicationLauncherJob into KService to bypass just that issue.

That's T13590.

Alternatively, do you see a better place to merge kio-etras?

No, but I don't see a pressing need to merge it anywhere either

In T13631#240200, @nicolasfella wrote:

-1 on merging kio-extras into kio. For frameworks we need to keep an eye on the dependency tree and kio-extras has quite a number of additional dependencies (phonon, samba, libssh, mtp, kdsoap etc) and the features that kio-extras provides are usually. I don't want my app to depend on all of that just to be able to use ApplicationLauncherJob et al

increases work for KDE's release team and distro packagers to have more packages to tar, package, update, manage, etc

-1 on merging kio-extras into kio. For frameworks we need to keep an eye on the dependency tree and kio-extras has quite a number of additional dependencies (phonon, samba, libssh, mtp, kdsoap etc) and the features that kio-extras provides are usually. I don't want my app to depend on all of that just to be able to use ApplicationLauncherJob et al

In T13595#240102, @ognarb wrote:

I would suggest using 3 or 4 long paragraphs instead of a bullet point list. A simple listing of the features is not very attractive and for example instead of saying that there is a tab support you could say: "Dolphin contains many productivity features that will make your life easier in many situations. The multiple tabs and split view features will help you navigate multiple folders at the same time and easily drag and drop files and folders between the open tabs to move them."

I would suggest using 3 or 4 long paragraphs instead of a bullet point list. A simple listing of the features is not very attractive and for example instead of saying that there is a tab support you could say: "Dolphin contains many productivity features that will make your life easier in many situations. The multiple tabs and split view features will help you navigate multiple folders at the same time and easily drag and drop files and folders between the open tabs to move them."

In T13595#240095, @xyquadrat wrote:

The additional features I have mentioned in T13595#239528 are probably more advanced, but I would still consider including them since your casual user will not see the Appstream description at all. Mostly users who are looking for a better file manager will encounter the text we are working on, and this user group is probably more knowledgeable than the average.

Use Dolphin to view, open and save your local and remote files.

The additional features I have mentioned in T13595#239528 are probably more advanced, but I would still consider including them since your casual user will not see the Appstream description at all. Mostly users who are looking for a better file manager will encounter the text we are working on, and this user group is probably more knowledgeable than the average.

Opinions? +1/-1 ?

As for the description, the current one is:

Personally I liked Paul's suggestion (at least for the appstream summary) as it's fully neutral and descriptive, and I could shorten it like so:

!PING.
I need help from someone with good understanding of Solid to continue.

I think you may be approaching this from the wrong angle. Instead of starting with the web page, I think you should start with what is the essence of the product and build up from there.

In T13595#239954, @valorie wrote:

Find, preview, rename, move, copy -- all things I do with Dolphin almost daily.

Beautiful, powerful and flexible are how I would describe Dolphin, just like real dolphins.

Details like naming Baloo should not be in a description for users IMO.

Words like "featureful" and "extensible" make my brain shut down.

Oh, now that I noticed: it's about the description, not the summary. (Though I will send a commit for the summary too)
I haven't actually started working on the descriptions, mostly summaries.

Find, preview, rename, move, copy -- all things I do with Dolphin almost daily.

+1 or -1 on any of those two? Opinions on how to improve those?
I'll be sending a commit for that soon (a few hours)

Yes, I can think of something for the appstream summary.
Currently, it's "File Manager", the same as the .desktop GenericName. GenericName is fine since it's what's shown in the menu and the XDG specs recommend it to be concise, but the appstream summary is a good venue for promotion and can be longer (like one line) as it's shown in Discover.

In T13595#239806, @ngraham wrote:

Improving https://kde.org/applications/en/dolphin is really all about improving Dolphin's AppStream metadata, which is a pleasantly small and impactful task since that metadata gets consumed and displayed in lots of locations.

Were you thinking we could additionally have a https://dolphin.kde.org/, like for example https://konsole.kde.org/? That would be the place for richer content.

https://dolphin.kde.org/ would be nice but very low-priority. I know there is already plenty of work on the table for the websites people ;)

Improving https://kde.org/applications/en/dolphin is really all about improving Dolphin's AppStream metadata, which is a pleasantly small and impactful task since that metadata gets consumed and displayed in lots of locations.

In T13595#239527, @angelacunha wrote:

This video is very beautiful, could be use the terms and ideas for this page

Features:

Navigation (or breadcrumb) bar for URLs, allowing you to quickly navigate through the hierarchy of files and folders.

Most people probably don't think of URLs when browsing through files. Also, is that a special feature? As far as I know basically every file manager has a similar navigation bar.

Supports several different kinds of view styles and properties and allows you to configure the view exactly how you want it.

Maybe add examples (icons, detailed list) for "view styles"

Split view, allowing you to easily copy or move files between locations.
Additional information and shortcuts are available as dock-able panels, allowing you to move them around freely and display exactly what you want.
Multiple tab support

"Tabs support" instead, since there have to be multiple tabs by definition for this to be useful.

Informational dialogues are displayed in an unobtrusive way.

Is that a feature that differentiates Dolphin from other file managers? In my opinion this could be dropped.

Undo/redo support

Rather minor.

Transparent network access through the KIO system.

Reword as "Easily access remote file shares as if they were local through the powerful KIO system" or similar ("network access" is quite abstract)

This video is very beautiful, could be use the terms and ideas for this page

In D29526#676402, @meven wrote:

In D29526#676386, @bruns wrote:

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

Yes and that's up to thumbnail creators to decide. To take advantage of this, we would need to introduce some ThumbnailCreator type that would say whether or not generated thumbnail might be influenced by DPR (i.e) text. That would necessitate change the ThumbnailCreator API.

In D29526#676386, @bruns wrote:

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

This has been done!

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

I just sent a specification evolution to cover this use case : https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/35

In D28370#676352, @elvisangelaccio wrote:

This caused issues so I reverted it for now.

https://bugs.kde.org/show_bug.cgi?id=425757
https://bugs.kde.org/show_bug.cgi?id=426196

Superseded by D11816

This caused issues so I reverted it for now.

In D28745#676321, @bruns wrote:

In D28745#676320, @marcingu wrote:

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

I tested it once more and it returns true when it should, as expected. What makes you think it doesn't?

Even worse, its almost random:

udi = '/org/kde/fstab///pebbles/foo:/mnt'
  parent = '/org/kde/fstab'  (string)
  vendor = 'pebbles'  (string)
  product = 'foo:/mnt'  (string)
  description = 'foo:/mnt on pebbles'  (string)
  icon = 'network-server'  (string)
  StorageAccess.accessible = false  (bool)
  StorageAccess.filePath = '/mnt'  (string)
  StorageAccess.ignored = false  (bool)
  NetworkShare.type = 'Cifs'  (0x2)  (enum)
  NetworkShare.url = 'smb://pebbles/foo:/mnt'  (string)

if (device.is<Solid::StorageVolume>()) -> false, though it should be cached

udi = '/org/freedesktop/UDisks2/block_devices/dm_2d2'
  parent = '/'  (string)
  vendor = ''  (string)
  product = ''  (string)
  description = '100,0 GiB Hard Drive'  (string)
  icon = 'drive-harddisk-root'  (string)
  Block.major = 254  (0xfe)  (int)
  Block.minor = 2  (0x2)  (int)
  Block.device = '/dev/dm-2'  (string)
  StorageAccess.accessible = true  (bool)
  StorageAccess.filePath = '/'  (string)
  StorageAccess.ignored = true  (bool)
  StorageVolume.ignored = false  (bool)
  StorageVolume.usage = 'FileSystem'  (0x2)  (enum)
  StorageVolume.fsType = 'btrfs'  (string)
  StorageVolume.label = ''  (string)
  StorageVolume.uuid = '5832ebfa-bf02-40d2-bdc7-90403b207b62'  (string)
  StorageVolume.size = 107374182400  (0x1900000000)  (qulonglong)

This is an LUKS encrypted volume so should not be cached ...

BTW, have you checked if the thumbnails are still generated for non-removable but encrypted filesystems? My whole system is encrypted (except for /boot), so it would be a performance loss if no thumbnails were ever cached.

In D28745#676320, @marcingu wrote:

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

I tested it once more and it returns true when it should, as expected. What makes you think it doesn't?

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

In D28745#676303, @bruns wrote:

Second, I have asked for a full context diff, or even better moving this to invent.kde.org, but @marcingu keeps ignoring this.

@marcingu - have you even verified this works? - I am quite sure it does not, neither for fuse.encfs, fuse.cryfs (as used by Vaults), nor for any LUKS encrypted devices.

@bruns and @meven?

Renaming "deviceIdUnset" to "s_deviceIdUnset"

Moving allowCache check, so it's done only if thumbnail was created.

Setting canonical path as value of hadFirstThumbnail

Removing unnecessary includes

Using special value instead of 0 as unset m_thumbnailDirDeviceId.
Changing ifdef checks for Q_OS_WIN for consistency.
Moving ifdev check into sharesFilesystemWithThumbRoot, to reduce number of preprocessor directives.

Skipping usage of POSIX functions and types on Windows

Adding path to error logs

@dfaure, what do you think here?

Using solid for getting Device

Re-opening since there's WIP patch that does just this, and it seems sensible overall. See D26067

https://invent.kde.org/system/dolphin/-/merge_requests/40

Yes please! :)

Should I make a merge request on gitlab?

@fbg13, would you be interested in continuing?

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

@elvisangelaccio could we reconsider this? There seems to be quite bit of user demand.

Feel free to ship it.

In D29178#675789, @elvisangelaccio wrote:

@feverfew Does it look good now for you?

In D21312#675714, @Zren wrote:

I have created a Merge Request on GitLab with a a couple new commits.

https://invent.kde.org/system/dolphin/-/merge_requests/31

• It will only show on devices. It no longer show under mounted folders like Root in the user's favorite places.
• Adurol on Freenode pointed out that the KIO FilePicker now uses KIO::FileSystemFreeSpaceJob, so I've refactored the patch to use that API.

@feverfew Does it look good now for you?

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

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