SUMMARY If you open QFileDialog in KDE (which uses KFileWidget internally, I believe) via QFileDialog::getOpenFileName() it doesn't show UDisks drivers. If use QFileDialog::getOpenFileUrl(), it shows them. I did some research and discovered this is due to the fact that QFileDialog::getOpenFileName() does setSupportedSchemes({"file"}) (likely to show only local files) and KFileWidget shows UDisks drives only if supportedSchemes is empty because device bookmarks don't have an URL attached to them. See: https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesmodel.cpp#L680 https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesmodel.cpp#L699 https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesitem.cpp#L328 I'm not sure if this is intented behaviour, but some programs use QFileDialog::getOpenFileName() to open files (e.g. qBittorrent) and this is quite annoying. STEPS TO REPRODUCE 1. Open a QFileDialog using QFileDialog::getOpenFileName() or call setSupportedSchemes({"file"}) on it manually. OBSERVED RESULT No UDisks drives in a sidebar EXPECTED RESULT There should UDisks drivers in a sidebar, since they are local and thus should be shown by QFileDialog::getOpenFileName(). SOFTWARE/OS VERSIONS KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.1 Qt Version: 5.11.3 ADDITIONAL INFORMATION
I tried to reproduce with kdialog --getopenfilename ~ and there I get my drives in the sidebar. getopenfilename also filters for "file" scheme, as indicated by the lack of a Trash folder.
(In reply to Kai Uwe Broulik from comment #1) > I tried to reproduce with kdialog --getopenfilename ~ and there I get my > drives in the sidebar. getopenfilename also filters for "file" scheme, as > indicated by the lack of a Trash folder. What udisks2 version do you have? I can reproduce this with udisks2 2.8.1. When running kdialog --getopenfilename, only Home, Desktop, Downloads and Root are displayed in the sidebar. When I run kdialog --getopenurl, it shows Trash, Network and Devices (udisks2 drives) too.
Which URL do you end up with if you click on one of the devices? I don't see a way how the drives can end up with a non-file:// url but still work fine.
(In reply to Fabian Vogt from comment #3) > Which URL do you end up with if you click on one of the devices? > > I don't see a way how the drives can end up with a non-file:// url but still > work fine. Selecting file from drive returns correct URL. When KFilePlacesModel populates itself, it checks scheme against an URL from KBookmark (https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesmodel.cpp#L680) and creates KFilePlacesItem from a bookmark if scheme is supported. Solid devices' URLs are empty (https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesitem.cpp#L328, they have only UDI and isSystemItem items) so they are included in the list only if scheme is empty too. When user clicks on an item in a sidebar, an URL for that item is taken from KFilePlacesItem::data(UrlRole) (https://github.com/KDE/kio/blob/master/src/filewidgets/kfileplacesitem.cpp#L135). For devices it returns URL from Solid, not from internal KBookmark object, that's why an URL for files from devices are correct. I think that storage devices should be included in KFilePlacesModel if scheme is "file". I managed to do this by storing Solid::Device objects instead of their UDI's in KFilePlacesModel::Private::availableDevices and then check for device type when populating list, like this: https://gist.github.com/equeim/769c3747ac34b3baaeae596a6a366a8f But I have no experience with Solid and don't know if this is a correct solution.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
New information was provided with comment #4; setting status for inspection.