KIO issueshttps://invent.kde.org/frameworks/kio/-/issues2024-02-17T09:23:01Zhttps://invent.kde.org/frameworks/kio/-/issues/31New Places Panel2024-02-17T09:23:01ZKai Uwe BroulikNew Places PanelThe Places panel in KIO used notably in the file dialogs and Dolphin is lacking several features that are often requested.
With XDG Desktop Portals letting applications request the KDE file dialog, the pressure of developing a shared fo...The Places panel in KIO used notably in the file dialogs and Dolphin is lacking several features that are often requested.
With XDG Desktop Portals letting applications request the KDE file dialog, the pressure of developing a shared format (`user-places.xbel` is afaik only implemented by KDE?) is a lot lower, and we could think of going our own way catering for the use cases that _we_ deem important.
**Collapsible groups**
Groups can be hidden but only entirely through the context menu. It would be nice to have an expand/collapse button to easily do that like a tree view allows, with the ability to hide it entirely kept as a more obscured option. Using a `QTreeView` as a base might be worth exploring, with the groups as root nodes. This should also fix various usability issues (in e.g. selection and context menu) with the current pseudo groups that are technically part of the delegate below them. The places panel is doing a lot of custom painting already, so making a tree view look like not a tree sounds doable?
**Custom groups**
Allow adding arbitrary groups, particularly in conjunction with easily collapsible groups could unlock people adding various project-specific folders without the places panel becoming a cluttered mess.
**Re-arranging groups**
When we have custom groups, we should of course also allow re-arranging groups.
Additionally, it would be cool if we could assign “generated” places entries (network shares, removable media) to a group at will. They will be created in their respective group by default but could be moved to a different group, if wanted.
**Per-activity places**
The elephant in the room, showing places or entire groups based on the current activity.
**Plug-ins or DBus API**
There are various “external” sources that feed places into the places panel.
* Bluedevil adds Bluetooth devices
* KDE Connect adds KDE Connect paired devices
They currently edit the bookmarks file to add and remove devices as they come and go. This can be messsy and leads to excessive writes and potentially stale entries in the database.
Instead, there should be an API that lets components add dynamic/transient places entries with the places panel only responsible for remembering custom settings for an entry (forcefully hidden, group assignment, etc).
Once such an infrastructure is in place, additional logic that currently resides in the model could be moved elsewhere, such as displaying tags, baloosearch/history entries, removable storage, heck, even the trash full vs. empty state could be handled by some kded thing adding a trash entry dynamically.
This would also allow more producers of places entries, such as KIO Gdrive adding an entry for shared cloud storage automatically, or auto-discovered network shares. Or perhaps recently visited locations, etc.
On the subject of API, a way to add custom context menu entries (e.g. the “Partition Manager” entry for devices, or “Ring Phone” or “Send File” for KDE Connect devices) would be lovely. There’s also https://csorianognome.wordpress.com/2015/07/07/cloud-providers/ which we should investigate.
**Miscellaneous**
* Some form of KIO-Fuse integration? If the consumer doesn’t support the given protocol, it could transparently redirect to a KIO fuse mount.https://invent.kde.org/frameworks/kio/-/issues/28kio_http, HTTP status codes, KIO errors, and kdav2023-11-25T10:24:46ZNicolas Fellakio_http, HTTP status codes, KIO errors, and kdavIn kio_http we translate staus codes/errors we get from HTTP to KIO error codes. Sometimes they match conceptually, but often there is no natural mapping here. In addition we also expose the raw HTTP status code via metadata.
An issue w...In kio_http we translate staus codes/errors we get from HTTP to KIO error codes. Sometimes they match conceptually, but often there is no natural mapping here. In addition we also expose the raw HTTP status code via metadata.
An issue with this can be seen in the kdav autotests. davcollectionsmultifetchjobtest makes a call to a non-existant URL (triggering a HTTP 404).
In KF5 this gives ERR_DOES_NOT_EXIST, without setting the `responsecode` metadata. See https://invent.kde.org/frameworks/kio/-/blob/kf5/src/kioworkers/http/http.cpp?ref_type=heads#L4453
In KF6 this currently gives no KIO error, but sets the `responsecode` metadata. Arguably it should set some kind of error, but sending the responsecode seems reasonable.
kdav now trips over the present response code in https://invent.kde.org/frameworks/kdav/-/blob/master/src/common/davcollectionsfetchjob.cpp#L94 and does a `doCollectionsFetch`, which causes the test to hang. Removing the `if (davJob->latestResponseCode())` makes the test pass.
The question now is: Should we try to make KIO behave as it did in KF5, even if that behavior is arguably weird, or should we accept the behavior change and adapt kdav?https://invent.kde.org/frameworks/kio/-/issues/27KF6: Broken error codes in file_unix.cpp2024-01-28T21:21:30ZFabian VogtKF6: Broken error codes in file_unix.cppAfter the conversion of file_unix to make use of `WorkerResult`, it mixes up KIO error codes and errno:
https://invent.kde.org/frameworks/kio/-/blob/a6f7d3117f159f3e0a88ff08b5f69b9bc8612cf7/src/kioworkers/file/file_unix.cpp#L1421
Coinc...After the conversion of file_unix to make use of `WorkerResult`, it mixes up KIO error codes and errno:
https://invent.kde.org/frameworks/kio/-/blob/a6f7d3117f159f3e0a88ff08b5f69b9bc8612cf7/src/kioworkers/file/file_unix.cpp#L1421
Coincidentially `EPERM` is 1 and thus maps to `KIO::ERR_USER_CANCELED` which is returned directly for most operations (and just the wrong error), but in the `chown` case actually worse: There is a missing `return result;` and thus it return success by accident.
Fixing the chown issue in particular is trivial, but I think this is a bigger design issue with `execWithElevatedPrivilege`. Should `PrivilegeOperationReturnValue` be brought back?
Discovered while running the kio-fuse test suite with KF6 (https://invent.kde.org/system/kio-fuse/-/merge_requests/75):
```
FAIL! : FileOpsTest::testLocalFileOps() Compared values are not the same
Actual (chown(mirroredFile.fileName().toUtf8().data(), getuid(), 0)): 0
Expected (-1) : -1
Loc: [/home/abuild/rpmbuild/BUILD/kio-fuse-5.1.0git.20231024T201554~2e127bd/tests/fileopstest.cpp(265)]
FAIL! : FileOpsTest::testLocalDirOps() Compared values are not the same
Actual (chown(mirrorDir.path().toUtf8().data(), getuid(), 0)): 0
Expected (-1) : -1
Loc: [/home/abuild/rpmbuild/BUILD/kio-fuse-5.1.0git.20231024T201554~2e127bd/tests/fileopstest.cpp(370)]
```
CC @asaoutkin @mevenhttps://invent.kde.org/frameworks/kio/-/issues/26New "kuriikwsfiltereng_private" library added in https://invent.kde.org/frame...2023-10-17T01:29:57ZAdam WilliamsonNew "kuriikwsfiltereng_private" library added in https://invent.kde.org/frameworks/kio/-/merge_requests/1401 has no version or soversion, isn't really very privatehttps://invent.kde.org/frameworks/kio/-/merge_requests/1401 added a new shared library called `libkuriikwsfiltereng_private`. However, it was not given a VERSION or SOVERSION, so on install on Linux, you just get a file `/usr/lib64/libku...https://invent.kde.org/frameworks/kio/-/merge_requests/1401 added a new shared library called `libkuriikwsfiltereng_private`. However, it was not given a VERSION or SOVERSION, so on install on Linux, you just get a file `/usr/lib64/libkuriikwsfiltereng_private.so` (whereas you'd expect something like `/usr/lib64/libkuriikwsfiltereng_private.so.6`). Unversioned `.so`s are usually development libraries, so in Fedora, this got packaged in the `kf6-kio-devel` package (which is the logical place for unversioned `.so` files); the `kf6-kio-widgets` package got a dependency on the library (as it should), which means installing `kf6-kio-widgets` pulls in a bunch of development packages.
At the very least, I think, the library should have a `set_target_properties` block in `CMakeLists.txt` like every other library kio provides, like the one for e.g. KF6KIOGui:
set_target_properties(KF6KIOGui PROPERTIES
VERSION ${KIO_VERSION}
SOVERSION ${KIO_SOVERSION}
EXPORT_NAME KIOGui
)
I don't know if the `EXPORT_NAME` is necessary here, but I think the other two things should be set.
I am not really an expert Library Guy or C(++) coder, but this seems kinda fishy to me in other ways too. Just sticking "private" in the name of a library that is, in all other respects, a system shared library isn't...usually...how we do private libraries, is it? Shouldn't it be stuck off in the plugins dir like e.g. the filewidgets library, or something?https://invent.kde.org/frameworks/kio/-/issues/21Debug mode for new, non-distro installed applications2023-04-06T13:13:53ZSławomir LachDebug mode for new, non-distro installed applicationsWhen user tries to launch app first time, many thinks could happen wrong. The idea will address only to binaries/desktop files without executable bit set. Actually, when launch, warning dialog appears with asks to confirmation of open. N...When user tries to launch app first time, many thinks could happen wrong. The idea will address only to binaries/desktop files without executable bit set. Actually, when launch, warning dialog appears with asks to confirmation of open. Next time, it would not display, because app has executable bit. Idea is to:
1. Launch in special mode, when dialog appear
2. Redirect stderr to file
3. Ask if everything goes good, when app stop working - remove executable bit if user decided there was some errors
4. Allow user to shown file with data sent to stderr, when app stop working
What this special mode does? It will, for example, launch app with special variables to do more debugging. For example, we can pass LD_BIND_NOW=1, pass G_DEBUG=1, execute printenv before running and pass output to stderr, enables mangoo hud to test framerates in game, generate link to bugzilla to open/search for ticket related to current program (based on information from desktop file or hash of executable), etc. Possibilities are many. Reason is to help people find out, what goes wrong and if something goes wrong.https://invent.kde.org/frameworks/kio/-/issues/16Permissions dialog for X11 apps?2022-10-19T17:38:37ZSławomir LachPermissions dialog for X11 apps?I am doing AutoSpawning-Konsole for console apps for now. It is related to KIO work. Because, I detect if app is X11, Wayland or Console, maybe I could add additional features.
I open this issue, because I have very small knowledge abou...I am doing AutoSpawning-Konsole for console apps for now. It is related to KIO work. Because, I detect if app is X11, Wayland or Console, maybe I could add additional features.
I open this issue, because I have very small knowledge about Wayland. Wayland enforces to use portals to obtain privilege. On X11, apps do not have to do this. As I guess, many outdated, X11 apps could be broken (for example - applications recording desktop). It is possible to add permission tab for it - for example in properties?
I think, when my routines detect app is X11, it could show notification about that and allow to show dialog, allowing to configure permissions for it. But I do not known how many work it requires from XWayland team to made it working.
What do you think?https://invent.kde.org/frameworks/kio/-/issues/9KIO::Resume vs. MarkPartial2021-09-29T09:00:06ZHarald SitterKIO::Resume vs. MarkPartialI was refactoring some stuff in smb.so when I noticed peculiar behavior between the two resumption systems we have.
Most (perhaps even all) workers do the following:
- if MarkPartial is enabled then that is used. i.e. write to .part, p...I was refactoring some stuff in smb.so when I noticed peculiar behavior between the two resumption systems we have.
Most (perhaps even all) workers do the following:
- if MarkPartial is enabled then that is used. i.e. write to .part, potentially resuming from there as well
- else if KIO::Resume is set and the destination file exists then that is used. i.e. **append** to the destination file directly
This seems entirely wrong given what KIO::Resume is documented to do
```
/**
* When set, automatically append to the destination file if it exists already.
* WARNING: this is NOT the builtin support for offering the user to resume a previous
* partial download. The Resume option is much less used, it allows to append
* to an existing file.
* This is used by KIO::put(), KIO::file_copy(), KIO::file_move().
*/
```
which to me reads like this really should be KIO::Append and the actual behavior is one where I would e.g. ::put `part1.txt` and then ::put `part2.txt` with KIO::Resume to form `part1-and-2.txt` on the destination. And that surely needs to work regardless of the MarkPartial stuff (which the user can toggle at their leisure).
Currently that's not what happens though. It certainly isn't for ftp where the test even tests the wrong behavior https://invent.kde.org/frameworks/kio/-/blob/af28b4ab25c2faf92ed53d4443e3fc28f77299a0/autotests/ftptest.cpp#L130
The way we do it is that if KIO::Resume is set AND MarkPartial is true then we'd append to the .part file, not the destination file. So what happens is
- I put part1.txt -> part1.txt.part -> put completes -> mv part1.txt.part part1.txt -> the content is now only part1
- I put part2.txt with Resume -> part2.txt -> part1.txt.part -> put completes -> mv part1.txt.part part1.txt -> the content is now only part2
This leaves me with a bunch of questions:
- do we even need KIO::Resume? It is meeting a very niche use case that could be implemented differently, albeit with potential overhead (e.g. if the parts aren't local then ::get them, concatenate them locally, then put to destination in one go). Having it be a native feature seems fairly costly from a code clarity POV, I for one have trouble wrapping my head around the resumption implementations in file and ftp because of the extra complexity KIO::Resume adds. Plus, I'm not convinced I've found any "correct" users of this feature. Konversation might be for DCC transfers but that is quite possibly the full extent of users for the feature.
- if we need it, should we maybe deprecate its name and make it `KIO::Append` instead? so everyone stops using and implementing it incorrectly ;)
- what is the actual behavior it should have? because if it is appending then file, ftp, and smb appear to not be doing it right thing and need fixing
@dfaure @ahmadsamir