Just tried latest build on Windows.
Looks very-very cool and promising!
Thu, Sep 17
dolphin plugins that solely target developers
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.
Wed, Sep 16
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.
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.
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
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
Tue, Sep 15
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."
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:
Mon, Sep 14
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 website, I think you should start with what is the essence of the product and build up from there.
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.
Sun, Sep 13
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.
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 ;)
Sat, Sep 12
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.
Thu, Sep 10
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.
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
Wed, Sep 9
Tue, Sep 8
Mon, Sep 7
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
Sun, Sep 6
Sat, Sep 5
Superseded by D11816
This caused issues so I reverted it for now.