[RFC] One ioslave to rule them all...

[James Richard Tyrer]

Kévin Ottens wrote:
> Hello list,
> 
> I'd need some opinions about the work I've done until now and about my current 
> plans about system:/. The basic idea behind this ioslave was to have one root 
> allowing desktop users to easily browse the relevant places in the system. I 
> want to push the idea further hence why I need to know if there are 
> suggestions or objections.
> 
> In order to have this possible I developed mainly three ioslaves:
> - media:/ which allows to deal with your partitions, removable media, cdroms, 
> etc.
> - remote:/ which allows to have "remote folders" and is possible to use thanks 
> to knetattach.
> - home:/ which displays home directories of the users being in the same groups 
> than the current user (because it's generally more relevant to share files 
> with them), and the current user home directory.
> 
> Currently system:/ points to media:/, trash:/, remote:/, settings:/ and home:/ 
> (which was committed yesterday). home:/ being the last part of my great evil 
> plan : hiding the real file hierarchy!
> 
> I'm now almost able to do it, in fact if I could even do it now. Some of you 
> may wonder "why hiding the unixian file hierarchy??? and push use of 
> system:/???". 
> The answer is simply that for a desktop user this unix file hierarchy is an 
> implementation detail.
> 
> So, the current status of what I've done is exactly this : if you start 
> browsing using system:/ you can stay in this virtual hierarchy and do all 
> your daily work using it (as a desktop user, not a sysadmin).
> 
> So the user could use only this, but some entry point to the unix filesystem 
> still remain, in particular the shortcuts to the home directory...
> 
> Where I'd like to go is the following : replace $HOME with home:/$USER 
> everywhere, this way the user will be "on the right track" by default (in the 
> system:/ hierarchy).
> 
> Of course this would raise some issues on interoperability mainly because 
> there's no consensus about the available VFS protocols between desktops. I 
> currently see two problems in this area (I'll use media:/ as example since 
> it's older and more known, but everything I'll present is true with home:/ as 
> well) :
> 
> 1) Opening a file in the system:/ (media:/) hierarchy.
> When opening a file with an application, the application is launched thanks to 
> its desktop file, and %u is replaced with the file URL (a media:/ URL for 
> example). It'll work flawlessly with most KDE applications since they support 
> KIO. But, some of them don't really support KIO completely (Kaffeine for 
> example because it uses xine which only support some protocols like http and 
> file). Moreover, non-KDE applications know nothing about media:/ URLs!
> 
> Then two things have been introduced:
> - KIO::NetAccess::mostLocalURL() which allows KDE applications to resolve an 
> URL to a file:/ URL if needed (and if possible).
> - X-KDE-Protocols key in desktop files, which allows to restrict the set of 
> supported protocols for an applications. Anything not present in this set is 
> automatically resolved to file:/ URLs if possible before launching the 
> application.
> 
> This way, we keep the compatibility with most applications, and KDE 
> applications are able to have more control on the process. I then consider 
> this issue as solved, the real solution would be of course to ensure that any 
> non-KDE application could deal with any KDE URL but that's definitely not 
> feasible currently, it would require a common VFS across all desktops, 
> something that we won't have before a long time IMO.
> 
> 2) Drag and Dropping a file from the system:/ (media:/) hierarchy.
> It's the same kind of issue than opening a file. The main difference being 
> that the application is already running, so the only counter-measure that can 
> apply is KIO::NetAccess::mostLocalURL(), then only KDE applications can 
> resolve the URLs to file:/ URLs... I've find no real way to make it work for 
> non-KDE applications. Suggestions are welcome!

One thing which the user doesn't need is: "Home".  It should be replaced 
with: "Documents" although I think that it could use a better name (I 
call mine "USR Home").  There is a lot of junk in the $HOME directory 
that a user doesn't need to access except when doing administration 
tasks and the fact that much if it is in 'hidden' files and directories 
doesn't really change that.

The user's default Working Directory (currently referred to as the 
"Documents path") should be a subdirectory of his $HOME folder.  The 
user might choose to have his "Documents path" be $HOME (this is the 
current default), but it should still not be referred to as $HOME since 
this will cause problems for users that don't use the default.

If you have your "Documents" directory contain ONLY directories, this 
would work quite well.  You don't want to have it function as: "My 
Documents" but rather as the base directory for various document 
folders.  So, it has a directory: "Documents" ("My Documents" ;-|) which 
is why I said that it needs a better name.

I would add: "Applications" since it is just the Menu.

I would keep: "Settings" since some users prefer it to the Control Center.

I also think that what is displayed in: "Storage Media" could use some 
work.  I have:

     A:
     B:
     CD-ROM
     Zip

Which are fine.

AND SEVENTEEN HD partitions!  Users don't need that.  Even I don't need 
that since I can't remember which is which without reading my" "fstab". 
  Since all of the HD partitions are supposed to be mounted in the file 
system, isn't it enough to have one HD icon for the "/" and one for 
$HOME?  Yes, $HOME is OK here since you do need it from time to time.

I don't see even a dozen icons as too many in "system:/" so there is 
room to add more if they are important.

I also think that the Home icon on the DeskTop should point to the 
directory selected in the "Documents path" setting and should be called 
something else.  Calling it "Documents" is OK but perhaps "Files" (My 
Files :-|) or something else would be better -- it is probably going to 
contain a subdirectory "Documents" as mine does.

> Now I'm pondering on what to do :
> a) Replacing $HOME with home:/$USER right now?
> b) Replacing $HOME with home:/$USER for KDE 4 only?
> c) Give up the whole idea?
> d) Something else?
> 
> Of course I tend to think I should apply a), but I would consider b) 
> acceptable whereas I really dislike c). Of course, I'm open to any 
> interesting "d)" proposal.
> 
> Any opinions? advices?

So in specific answer to your question, I would suggest "d".  I don't 
see that you need to have: "home:/" at all and you do need to have: 
"documents:/".  And, yes this should find the "Documents path" 
directories of the users in a group that was the group owner of the 
user's "Documents path" directory.

If the user leaves the current default for "Documents path" as $HOME, 
this doesn't make any difference at all, but if he changes it, then it 
makes a lot of difference.

-- 
JRT