Import plasma-workspace kioslaves
AbandonedPublic

Authored by elvisangelaccio on Nov 28 2016, 4:03 PM.

Details

Reviewers
dfaure
Group Reviewers
Frameworks
Plasma
Summary

As discussed on plasma-devel, this patch imports the kioslaves from plasma-workspace (remote://, application:// and desktop://) in kio. At least remote:// is used also by Dolphin, so the idea is that this move will make possible to remove plasma-workspace as runtime dependency for whoever is using those slaves.

This patch just imports the kioslave folder (+ history [1]) from the root of plasma-wrokspace to the root of kio, but doesn't build it yet. I will do that in another commit (I'll also need to move the 3 slaves to src/ioslaves/).

[1] I used this script: https://gist.github.com/tsayen/f1c1c4d62d4fda77abf1586bd39f9b74

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
elvisangelaccio retitled this revision from to Import plasma-workspace kioslaves.
elvisangelaccio updated this object.
elvisangelaccio edited the test plan for this revision. (Show Details)
Restricted Application added a project: Plasma. · View Herald TranscriptNov 28 2016, 4:03 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript

Would it be possible to make the version in frameworks co-installable with plasma?

As long as the .protocol file still says protocol=desktop, dolphin and Plasma won't care what the .protocol filename is; the protocol file says which library to load, and KIO will just pick the first one that matches. At which point we can rename the .protocol and .so file to desktop5/remote5, without any issue.

People without Plasma load the version from frameworks, people with Plasma use the Plasma one until 5.9, when we just stop installing ours having already raised the frameworks dependency. It works in theory..

The only thing I'm not sure of is the kded modules and the other sort of unrelated .desktop files installed by the desktop kioslave.

Would it be possible to make the version in frameworks co-installable with plasma?

As long as the .protocol file still says protocol=desktop, dolphin and Plasma won't care what the .protocol filename is; the protocol file says which library to load, and KIO will just pick the first one that matches. At which point we can rename the .protocol and .so file to desktop5/remote5, without any issue.

People without Plasma load the version from frameworks, people with Plasma use the Plasma one until 5.9, when we just stop installing ours having already raised the frameworks dependency. It works in theory..

The only thing I'm not sure of is the kded modules and the other sort of unrelated .desktop files installed by the desktop kioslave.

Probably also the kde modules need renaming? Both p-w and kio installs them in <prefix>/qt/plugins/kf5/kded/

aacid added a subscriber: aacid.Nov 28 2016, 7:11 PM

These don't seem very "core" to me, maybe material for kio-extras ?

I'll let dfaure decide though :D

These don't seem very "core" to me, maybe material for kio-extras ?

Summarising the mailing list thread/bug report where this happened:

The reason this came up is because Dolphin effectively hard depends on them. Particularly remote:/
Dolphin in other environments currently gives a big error until you install plasma-workspace, which defeats the point of the split.

Being in kio-extras would sort of work for Dolphin, but it's a bit misleading as they're supposedly "extra". Extra implies it's an optional add on; whereas Dolphin apparently needs this.

Plasma-integration/plasma-workspace rely on them too, so we can't have them in kio-extras, as that puts an applications dependency on Plasma, which we also can't really have.

These don't seem very "core" to me, maybe material for kio-extras ?

Summarising the mailing list thread/bug report where this happened:

The reason this came up is because Dolphin effectively hard depends on them. Particularly remote:/
Dolphin in other environments currently gives a big error until you install plasma-workspace, which defeats the point of the split.

Maybe Dolphin needs to be patched not to assume remote:/ will always be available?

dfaure edited edge metadata.Nov 29 2016, 9:44 AM

remote:/ sounds very workspace-independent indeed, it sounds useful to have in kio.

But desktop:/ and applications:/ make no sense in other workspaces (I'm surprised we even still have applications:/, it's kind of a toy, isn't it?).

(ok applications:/ might make sense in gnome, but definitely not on Windows/OSX)

mart added a subscriber: mart.Nov 29 2016, 10:43 AM
In D3530#65867, @dfaure wrote:

But desktop:/ and applications:/ make no sense in other workspaces (I'm surprised we even still have applications:/, it's kind of a toy, isn't it?).

(ok applications:/ might make sense in gnome, but definitely not on Windows/OSX)

desktop:/ should be probably conditionally built only on Linux(but in there is quite core), while, may make sense to actually kill applications:/ altogether??

mart added a comment.Nov 30 2016, 11:27 AM
In D3530#65734, @aacid wrote:

Dolphin in other environments currently gives a big error until you install plasma-workspace, which defeats the point of the split.

Maybe Dolphin needs to be patched not to assume remote:/ will always be available?

tough remote is a functionality that makes sense regardless in which desktop you're in

In D3530#66090, @mart wrote:
In D3530#65734, @aacid wrote:

Dolphin in other environments currently gives a big error until you install plasma-workspace, which defeats the point of the split.

Maybe Dolphin needs to be patched not to assume remote:/ will always be available?

tough remote is a functionality that makes sense regardless in which desktop you're in

Agreed, and we should encourage packagers to provide that dependency, but on the source code level I think it makes sense to gracefully detect that one of your runtime dependencies is missing

dfaure added a comment.Dec 4 2016, 6:20 PM
In D3530#65873, @mart wrote:

desktop:/ should be probably conditionally built only on Linux(but in there is quite core), while, may make sense to actually kill applications:/ altogether??

I have no doubt it seems "core on linux" from a plasma point of view, but e.g. someone using KIO on embedded linux, or with a very basic desktop, would have no use for kio_desktop.

This makes me wonder, actually... is kio_desktop usable with non-plasma workspaces, like gnome? Or is the desktop dir itself non-standard and the handling of desktop files (quite common on the desktop) different?

BTW what is it that has a strong runtime dependency on kio_desktop? (sorry, I'm not on plasma-devel so I didn't follow the full discussion).

As I said, I have no problem with kio_remote moving to kio (apart from the broken coding style (mixing tabs and spaces)).

So it seems that moving desktop:// creates more problems than it solves. Maybe we should leave it in plasma? That would also solve the co-installability problem.

elvisangelaccio abandoned this revision.Feb 20 2017, 5:05 PM

I've decided to keep it simple and only move remote:/ for now. Please continue in D4690.