Daniel Llewellyn schreef op 09-10-2016 21:17:
On 09/10/16 19:53, Xen wrote:
I am pretty sure that any application that does not support GVFS
will not see those mounts so easily. You will have to symlink them
and that defeats the purpose of the system in a certain sense.
There is no default system that everyone can use
Well, thank you for your comments.
You're quite right that the two incumbents don't recognise each
other's mounting mechanisms. With the gvfs system I do successfully
use the command-line to access the mounted filesystem, which suggests
that KDE applications should be able to access also. I believe the
problem you encountered is due to the daemon that gvfs-mount talks-to
isn't running (is it called gvfsd?), which you _might_ be able to
manually invoke in your KDE session, but I'm not sure on that - there
might be other dependencies that need to be running (dbus-services and
the like..?).
I personally believe KDE should easily be able to but I have this
feeling that they don't want to use anything from the gnome camp...
Actually gvfsd was running.
I believe that there are more systems from Gnome that I would consider
superior but at the same time GTK seems to be not very good at all. And
I have some experience because I have coded a bit of GTK (2). I have
heard more of this from other developers. On the other hand Cinnamon
looks amazing and KDE just doesn't look all that good in its controls
and the like, certainly not with Breeze.
So naturally Ubuntu (Unity) would also normally look better than KDE, I
feel. KDE is just the most of a fully featured system that I know and
feels more like a stable 'broad' environment that I can use. KDE feels
more solid (even when it might not be).
As a feature request that you could try to get implemented by the
gnome guys you could suggest to their issue-tracker that gvfs support
KIO-slaves. Also would be worth suggesting to the KDE guys the
inverse, for KIO to support gvfs-mounts.
But KIO itself does not provide any mount points so that would not
readily solve a thing unless they called gvfs-mounts to provide that,
yes.
But I don't think they ever will.....
I sense the best overall solution would be to unify the daemon-side of
both KIO and gvfs into a single daemon that both desktops back-onto,
but I wonder about how much pushback or otherwise such a unified
effort might encounter from both camps, and others. I bags the name
GKVFIOS and GKVFIO (hybrid nomenclature between GVFS and KIO :-p).
;-). That might be some intermediate daemon that will just provide a new
API that both can agree to ;-).
It has to be a joint effort and not one having to use the other. And I
still wonder whether they will like it and whether it is really a good
effort to make. I feel a systemd approach is really a superior choice
here if it can be had.
If you can have some system that will simply save mounts as SystemD
services, you already have an example and a solution, although the user
interface might not be so good (as it is with gvfs-mount and the other
bin-utils, supposedly).
Personally I think SystemD is lower level and in that sense more
dependable and more broad...ly available. It might not do the same
things but... at least it is something both parties could use.
However filing feature requests is nonsensical unless the feature
request is fully featured which means developing the idea prior to
filing the feature request which comes down to developing the feature to
begin with. You can't just say "Hey, I want that, can you make it?" and
then assume everything will be alright, you know?
You have to play an active role in these things or it won't come to be
and I seriously cannot understand how anyone can see these emails as not
playing an active role in this thing.
Besides if you filed a random open-ended feature request it might turn
out to be exactly what you don't want when they make it, if they make
anything, if "they" actually exist and it is not you.
Is all I am saying.
Regards, and thanks for the help.
Kudos, Bart.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
