Dolphin will be a useful program on Windows. We should package it and upload it to the KDE Community's account on the Microsoft Store.
Checklist:
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T9575 Publish more of KDE's applications in the Microsoft Store | ||
| Open | None | T9579 Publish Dolphin in the Microsoft Store |
We briefly talked about Dolphin on Windows at the Dolphin BoF today at Akademy. We agreed that Dolphin on Windows should get some more love, since there are users that are using it (from the binary factory). Getting it released "officially" is something we should be looking into.
I use Dolphin from the binary factory. I can test dolphin builds if needed.
what does you mean with icons in 44x44 and 150x150 size? I can do that task.
I think having 44x44 and 150x150 icons is just a matter of scaling the ones we have, they are a SVG anyways.
I think the hard part is that somebody needs to check if all things work ok for the binary factory builds and later care about the reported issues.
Just tried current 'exe' build and decided to share a little feedback here.
Looks very-very cool and promising!
The issues I found:
Other than that, works fery fast and great! I'm definetely going to stick with it, if all issues are solved some day.
screenshot 1:
screenshot 2:
screenshot 3:
screenshot 4:
- No option to set 'single click to open folders' on preferences.
- Any language other than English can't be set.
Those depend on plasma / KDE global settings.
I guess we would need to add a compatibility layer.
@jriddell I guess that's usual maybe we can copy/inspire code from other apps.
- Some files' previews are not loaded properly (screenshot 1), and some of files on click bring error "Failed to open the file".
We are kio-extras I guess that is providing image previews.
- The 'Show menu' button (on screenshot 2) doesn't work - clicking on it forces Dolphin to crash.
- Old Dolphin icon is displayed in the Start menu (screenshot 3).
Seems like random compatibility issues, to be expected.
- The glassy-looking grey free space indicator should look more modern and flat (screenshot 4).
Well in fact that the default look of this widget without breeze theming.
I would guess we should edit this component to be a plain QProgressBar allowing to follow the environment look'n feel (breeze would not be affected).
- 'Move to trash' deletes the file instead.
That's inconvenient !
I guess we would need to implement integration with windows trash ideally but I'd say let's start first by disable the 'Move to trash' feature.
- Haven't found option to enable Preview panel.
It 's called the Information Panel, and it currently is not supported on Windows, because it ties with some other components that are Unix only.
This would need some effort to fix.
Other than that, works fery fast and great! I'm definetely going to stick with it, if all issues are solved some day.
Great to here.
Great job testing.
Will be happy to give it a go next time I am on Windows.
I would like to help pushing this forward. Not sure I can really help with development tasks but at least we should work to get a package ready to be published (properly packaged, with installers generated by binary-factory at the format expected by Windows Store).
That way we can test and identify issues on proper packages ready to be published.
The 'Show menu' button (on screenshot 2) doesn't work - clicking on it forces Dolphin to crash.
Is already fixed.
Draggin and dropping files from 7z to dolphin fails as the prompt move/copy here doesn't lock the files and the tmp files are gone when the user decides.
Dialogs are in the wrong z order
We also need to add detection for virtual windows files to kio, tries to doewnload all files in onedrive/owncloud when the home dir is entered, to index them.
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.
And talking about KIOs, I think I can take a look into making a KIO for "Known Folders", but I need some insight on how it should behave, e.g.: should we use the list from IKnownFolderManager::GetFolderIds in the kio's root, and use kioname:/{GUID} for everything else? (similar to the "applications" kio)
An OneDrive KIO shouldn't be much different than the GDrive one, but these use WebEngine for user authentication, not sure if this would be a problem for packaging.
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.
Besides the need to ship applications multiple times, Kate for example is a single instance application, as each install is independent and runs its own dbus etc your suggestion won't work.
And talking about KIOs, I think I can take a look into making a KIO for "Known Folders", but I need some insight on how it should behave, e.g.: should we use the list from IKnownFolderManager::GetFolderIds in the kio's root, and use kioname:/{GUID} for everything else? (similar to the "applications" kio)
An OneDrive KIO shouldn't be much different than the GDrive one, but these use WebEngine for user authentication, not sure if this would be a problem for packaging.
We don't need a one drive kio we need to teach kio to not download cloud files to index them.
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.
Why would we need fuse on Windows?
Why would we need fuse on Windows?
Kio-fuse on linux mounts kio as fuse paths (e.g.: it mounts applications:/ into /run/user/1000/kio-fuse-kXlBEl/applications. By integrating it into the fuse api in dokany we theoretically could similarly expose a kioslave as a network mount (e.g: \\kio_applications\) or as drive letter, so even non-kde apps could benefit from it. I'll take a look at it to check if it is really doable, though.
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:
The issue was introduced recently I currently rebuild the cache to fix the issue, it should be gone in the next couple of days.
See https://invent.kde.org/system/kio-fuse/-/issues/12
A brief look makes me feel like there's a good wrapper for the high-level FUSE API, but KIO FUSE uses the low-level API.
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
@vonreth do you know in which specific moment kio tries to download the OneDrive files? It seems that the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS flag returned from GetFileAttributes should be able to tell those files apart.