> On Wednesday, July 6, 2005 1:20 am, Manuel Amador wrote:
> > Why the hell are we moving away from standard UNIX paths, and inventing
> > another arcane proprietary path/resource location system?

> Because the UNIX filesystem is incomprehensible to the average user. No
> casual user is ever going to understand the idea of a single root
> directory, or the concept of "mounting" filesystems. Unfortunately,
> Windows-style drive letters and synchronous access (that actually works)
> are probably not going to be introduced on UNIX anytime soon, and so there
> is no way to solve this except abstracting it away.

I completely agree. The average user has no idea what mounting is and nor =

should they. I love the concept of kioslaves because they pull away from t=
he =

UNIX filesystem for the GUI. I love the UNIX filesystem for the command li=
ne =

where all of us here are comfortable. But the GUI offers to take away the =

technical aspects of the behind-the-scenes workings of the operating system =

so that the average person (my grandmother for an example) can sit down in =

front of the computer and make use of it. This requires that we rid the GU=
I =

of /proc /sys /boot and other confusing directories. A perfect example of =

why this is a good thing is OS X. Why can anyone sit in front of a Mac and =

use it? Because when they click on 'Hard Disk' they don't see =

the /sys /proc /bin and other folders. In the GUI, they are hidden. You c=
an =

still access them from the command line if you need to though. When my wif=
e =

inserts a CD she doesn't want and shouldn't need to know where the hell it =

is. All she should know is, if I click on the icon that popped up on kicke=
r =

or my desktop, I will be taken to the CD. Or if she clicks on the Media =

Storage icon on the side bar of open file dialogs. Forgive me for being =

bold, but I think we need to talk about who we are designing KDE for. =

Developers (technical users) or Users (non-technical users).

> The organization of the UNIX filesystem is not really much of an issue,
> because users generally only care about browsing files in their home
> directory. That is why the Home Folder entries were introduced in the
> Konqueror sidepane and in the file selection dialog. I would support home=

> if it made sense. Unfortunately, to access my home directory, I would have
> to type home:/luke instead of /home/luke, not much of an improvement.
> Simply home:/ would make sense.

I don't think that a home:/ kioslave is necessary. What I've chosen to do =

with my KDE box is to remove as many traces of the / directory as I can for =

my users. I can access anything I need from the command line. And perhaps =

some GUI apps can browse the entire filesystem (KDevelop). I mean, what do =

users need to know about outside of their home directories? If any mounts =

are needed, the GUI should handle it for them. May it be a camera, network =

browsing, jump drive, or CD. That way the system is completely hidden from =

them and confusion over the filesystem is virtually eliminated. Don't forg=
et =

that the Windows way of doing things is confusing too. So many users I wor=
k =

with on a daily basis have no clue how find a file when starting from C:\ =
.. =

Not to mention the fact that D:\ doesn't make sense. Our way of doing thin=
gs =

is much better. When a CD is inserted, an identifiable icon appears in =

various places for quick and easy access and is named a name that makes =

sense, not D:\ . If the GUI eliminates the unnecessary parts of the file =

system and handles everything outside of their home directory then the =

desktop system becomes usable for everyone. =

> UNIX will never be a feasible desktop OS until mounting is completely
> hidden and transparent to the user. =

I think you can guess that I agree completely.

> My biggest problem with media:/ is as =

> follows: A devices should be automatically mounted whenever the user tries
> to access it (media:/ has done this) and AUTOMATICALLY UNMOUNTED WHENEVER
> THE USER IS DONE ACCESSING IT (media:/ has not done this). =

I agree for one reason. Many distros don't handle multi-user environments =

properly. For instance mine, SuSE 9.3 does not have the fstab file correct =

for desktop systems. I had to modify it and add 'users' to it so that if I =

inserted a CD and left it there, my wife can still eject it and put somethi=
ng =

else in. This would be a way of getting around a foolish distribution. =

> There should =

> then be no overlay on device icons indicated whether they are mounted or
> unmounted, because user's don't know about mounting. =

Again, I agree.

> 3) the floppy drive must always appear in media:/ on PC systems, even when
> no disk is present, because there is no way to tell if there is one
> present. Thus, CD-ROMs and other non-hot-pluggable devices should always
> appear in media:/ as well for consistency.

I disagree. The CD-ROM devices should not always be there. An inserted CD =

should appear as if from nowhere to cut down on what the user has to know =

about where things are. If it appears in multiple places, then there's no =

confusion. It's just up to us to make sure that media:/ is integrated well=
.. =

A floppy on the other hand, I have two points about. =

1) Who uses floppies anymore? I know I haven't had a floppy drive for year=
s =

now. Why? Because they're obsolete. Way obsolete. Desktops don't hardly =

even come with floppy drives anymore. =

2)For older systems with floppy drives, the floppy drive should not appear =
in =

media:/ at all unless it is mounted. How you access it is from a floppy:/ =

kioslave. I think we have one? Upon KDE install, if the system has a flop=
py =

drive installed then links to floppy:/ will be placed on the desktop, kicke=
r =

and file dialog navigation bar. And of course these links will appear if =

hald reports that a usb floppy drive has been inserted. =


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

e <<