Home_greyopenFATE - openSUSE feature tracking > #120115
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Common Virtual File System Support

Feature state

openSUSE-11.1
Rejected Information
openSUSE-11.2
Rejected Information
openSUSE-11.3
Rejected Information

Description

KDE and Gnome both use their own virtual file system layer to access protocols like SSH, WebDAV, FTP, or SMB (KIO slaves vs. gnome-vfs).
This functionality should be available from all major desktop applications on both desktops.

Different approaches could be taken:

  • Implement a lower-level VFS layer that can be used from all applications. This approach has obvious limits because all remote file systems
    would have to be "mounted" locally, which is not as flexible as accessing them via URLs.

  • Separate file loading and file storage from the application cores and use the desktop environments' native file dialogs. This approach has
    worked quite well for some applications (e.g. OpenOffice.org, Sodipodi), but may be a painsome process for others.

  • Use the useful parts from the non-KDE/non-Gnome applications and write new, native applications using those parts. This has been done with the
    Gecko rendering engine. Another example is gphoto2, which used to be a GTK application, but now is a library that is used in Gnome and KDE
    digital camera management frontends.

How could we reach that goal?
  • KDE and Gnome developers at Novell should cooperate to develop a guideline for 3rd party developers.

  • Where possible, tools should be provided to help developers with using the native dialogs.

Discussion


icons/user_comment.png J. W. wrote: (12 years ago)

FUSE and user space filesystems like fusesmb or fuse_kio can deliver this. We need to put some effort into this post Code 10.

icons/user_comment.png S. B. wrote: (10 years ago)

Michael, you did some evaluation wrt. KDE/GNOME using common stuff. Anything helpful to add?

icons/user_comment.png G. E. wrote: (10 years ago)

Given Novell and the communities recent investement in gvfs and the fact that KDE4 isn't using gvfs, I'm going to reject this one.

icons/user_comment.png M. M. wrote: (10 years ago)

Sure - this is a great direction to go in. Wrt. the different approaches - I want to use this as an opportunity to share code & reduce bug fixing / sustain costs: and of course to unify the ISV platform. I'm not that enthusiastic about FUSE from this angle: I would prefer a single implementation that can be compatibly wrapped by both existing KIO and GIO APIs.

In addition, I believe we need to unify the wallet / keyring pieces since network IO slaves are fairly useless without that.

icons/user_comment.png J. W. wrote: (10 years ago)

I'm not quite sure I understand why this request is closed for 11. The problem persists, and AFAICS my initial description is still valid, regardless of the technology switch to gvfs on the GNOME side.

In addition to that gvfs does not address the problem of making files available transparently to non-GNOME or even non-GUI apps (think vi), or does it?

Please either reject it for time reasons and move it to a later version or even better address it for 11, but we should not close and forget about it, as the pain is still there for any user of a desktop that runs at least one major application from the "other side" or from the pre-GUI times.

icons/user_comment.png M. M. wrote: (10 years ago)

Sure - I want to see this in sled11 too, and we have a plan to investigate this: lets not close it now.

icons/user_comment.png G. E. wrote: (10 years ago)

GVFS does make files available. At least you can tab-complete a path on a remote host when entering the path for scp for example.

icons/user_comment.png M. M. wrote: (10 years ago)

Gary: the advantage of switching to a common IO subsystem is that it would make both KDE & Gnome equal peers in terms of their device access:it would also reduce our costs wrt. long term maintainance, and make things far easier for ISVs to integrate with both desktops in one shot. The fact that GVFS works, or KIO works in a given place is not that relevant here :-)

icons/user_comment.png N. F. wrote: (8 years ago)

Just to mention it: Here is some experimental work, which tries to address this problem:

http://live.gnome.org/KioGioBridge

It's not that hard to run KIO on top of GIO/GVFS - but to make it neat, the dependencies of GVFS need to be approached as well. Particularly gconf and gnome-keyring. The latter could perhaps be tackled by making the KDE password manager GUI "dualistic" (allow to peek into both password managers - KWallet and Keyring daemon).

icons/user_comment.png W. S. wrote: (8 years ago)

I agree that this will be nice to have but it's out of scope for an SP.  By replacing a core part of the platform with an experimental compatibility layer we would be replacing reliable and painstakingly maintained upstream code with something new that will run into every API corner case and badly specified behaviour, something we have to maintain ourselves, and which has not had any testing in openSUSE.

IMO if we do this, we should do it right, upstream by proposing a common standard and taking it when it has matured there.

KWallet is being ported to a standardised gnome-keyring backend so this will be easier in future.

Last change: 4 years ago
Voting
Score: 14
  • Negative: 0
  • Neutral: 1
  • Positive: 14
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint