[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Against the system:/, media:/ and home:/ namespaces
From:       Kévin_Ottens <ervin () ipsquad ! net>
Date:       2005-07-06 7:56:35
Message-ID: 200507060956.39598.ervin () ipsquad ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le Mercredi 6 Juillet 2005 03:20, Manuel Amador a écrit :
> I have installed KDE 3.4 on Fedora Core 3 and the media:/ Kioslave is
> broken.  No files are showed after mounting a volume (while navigating
> to /media/mountpoint does show the files, which indeed proves the mount
> operation succeeded), and repeated attempts to refresh tell me that the
> ioslave died unexpectedly.  Fixing that would be okay, I guess, and I
> could use the ioslave properly.  Never mind that the mount status has
> never worked properly on my FC3 deployment (disks mount status shown
> directly on media:/ never change, whether I mount the disk manually or
> through the media:/ screen).

This kind of issue has been reported against Fedora. I couldn't reproduce 
them. Moreover media:/ is proven to works correctly (or at least not so 
broken :-) on several distros. I'm really worried by this Fedora case, but 
I'm more and more thinking that's a packaging issue... :-/

> Also, if I come through system:/ to media:/ there is no way to go up.
> Naturally if I follow the user model of what I am doing, I would expect
> the Up button to take me to system:/ but no, it does not take me there.

Yes, that's one of the things I used to hate in the devices:/ age. For 
system:/ I've been forced to implement it this way because of time 
constraints, but fo 3.5 It'll use forwarding so this issue will disappear 
(it's not here anymore in SVN trunk).

> Why the hell are we moving away from standard UNIX paths, and inventing
> another arcane proprietary path/resource location system?

As Thiago said, we're not moving away, we're just providing another view on 
the filesystem.
I could even add that this way we're able to implements some nifty thing today 
impossible to implement on the underlying platform. For example media:/ is 
able to query audiocd:/ when you insert an audiocd... you could hardly do 
this using a regular mountpoint (and please don't point me to cdfs which 
doesn't have all the features of audiocd:/ and is Linux specific).

> It is important that the real UNIX path be used!  I constantly select
> text from the location bar to paste on terminals, chat windows,
> documents and the like.  The paths Konqueror is now using simply will
> not let me interoperate with non-KDE applications.  Drag and drop among
> Konqueror/Nautilus has stopped working.  I can no longer drag stuff to
> XMMS.  Dammit, I have to type in duplicate now!

Fixed in SVN trunk. I can drag to any non-KDE application without problem, the 
URLs are converted in this case.

> Yes, I have heard we are trying to hide the UNIX path in order to make
> it easier for the regular user.  Is this motivation solid enough grounds
> to go in that direction?

Yes, I have desktop users not comfortable with the UNIX hierarchy displaying 
them loads of unnecessary directories. They are confused most of the time 
when they need to find their way throught it. /var, /usr, /etc are just 
implementation details for them.

> Is the way you are doing it the right way?

Since I won't change the hierarchy used in the underlying system, which serves 
well its purpose IMHO (it's just not well suited when you're doing desktop 
tasks) the natural way to go is to provided a specialized view on it, that's 
exactly what system:/ is doing (with some extras like the use of audiocd:/ I 
mentioned earlier).

> Have you weighed the pros and cons properly first?

The case was simple, since we're just providing a specialized view, it's not 
intrusive in the system, and we can make it interoperable.

> Should not other UI simplifications and improvements be considered first?

I thought of this before introducing those forwarding ioslaves (media:/ and 
now system:/). To make it right you'd need lots of dirty tricks (since this 
way you'd have to introduce really special cases), working on the ioslave 
level was the obvious choice then. Moreover by working only on the UI level 
you wouldn't be able to implement some of the features currently available in 
media:/.

> What is wrong with the simple venerable UNIX path?

Once again, it's an implementation detail. Most of the entries there are 
useless when you're working in a graphical desktop environment to achieve 
desktop tasks.

> You are actually complicating the end user because the entire rest of
> the system will simply not work with the current path/namespace scheme
> KDE is using.  You are missing the forest for the trees.

Well, this is plain wrong, since the rest of the system now work with media:/ 
and system:/ URLs as appropriate. But the problem is not new, the rest of the 
system doesn't work with fish:/ for example for ages now. In the case of 
local files we can solve it, and that's what we've done.

> To me, this reeks of NIH.  And it will, mark my words, bring tons of
> interoperability issues between KDE-based applications and non-KDE based
> applications (which, let me remind you guys, are the overwhelming
> majority of applications).  That alone is going to force us (a KDE
> desktop-based startup) to move back to GNOME.

Well, I worked in the past weeks to solve this kind of issues. Feel free to 
test trunk and report your experience on this. I only have one or two tiny 
patches not committed yet for two desktop files (namely the xmms desktop 
file). Drag and Drop should work for any application. Launching a file should 
work in most cases (except xmms, but the patch for the desktop file is 
pending).

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Attachment #5 (application/pgp-signature)]

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<


[prev in list] [next in list] [prev in thread] [next in thread]