Linked by Thom Holwerda on Mon 22nd Aug 2005 09:16 UTC, submitted by Rahul
GTK+ "The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy."
Thread beginning with comment 21803
To view parent comment, click here.
To read all comments associated with this story, please click here.
by unoengborg on Tue 23rd Aug 2005 12:10 UTC in reply to "RE[7]: GNOME vs KDE"
Member since:

So my answer to your insistence on hiding access to the underlying file system boils down to a series of questions:

a) have our menu systems matured to the point that we no longer need to execute files directly from the file system ?

What's missing is a menu editor, but that is going to be addressed by GNOME 2.12. BTW, If you want GUI menuediting tool for current GNOME versions you could install Simple Menu Editor for GNOME (SMEG).

Even without full menuediting capabilities in standard GNOME you can always create application starters that you can put in the panel or on the desktop.

I admit that the mechanism for creating application starters is a bit braindead at the moment. When browsing for a command to execute the filedialog should have shortcuts to the places in your filesystem that is in your path (hidden or not).

The line where you enter the command name should also be able to do command line completion with completion targets selected from the set of all executable files in your path.

b) are we providing GUI administration and configuration of system services sufficently that we no longer routinely need access to the command line and routinely need to edit configuration files ?

What I'm suggesting is not to make /etc et al inaccessible to the users and the sysadmin, what I'm suggesting is to make them hidden just like if they were UNIX dot files. This means that a sysadmin that frequently need to configure legacy programs that have no good GUI config tool, could easily create a shortcut to /etc or whatever hidden place he often needs to visit, just like he could with any normal UNIX hidden dot directory.

c) are our applications intelligent enough to respect the invisibile boundaries of our home directories ?

In most cases, ordinary users have not permissions to do much outside of their home directory. This have been the case since UNIX saw the light of day. Programs that doesn't respect this should considered broken and fixed.

IMO we are rapidly progressing on each of these questions-once we are able to unequivocally answer yes to each of these questions there should be extremely little resistance to hiding access to the file system and its associated complexity from users....

I would say that time is now. I have hidden /bin, /boot, /dev, /etc, /lib, /lost+found, /opt, /proc, /root, /sbin, /selinux, /srv, /tftpboot /usr and it have been very few occations if any where I have had to turn on "Show hidden files" to se them. Over the last month I have tried to count when that happens. So far that count is still at zero.

Unfortunately the current .hidden mechanism in Gnome doesn't hide the hidden folders in file dialogs. This is unfortunate as this is where this hide feature would have been most useful as it would have prevented the need for scrolling in many cases. This is something I hope they address in gtk+ 3.0, even if they should decide not to hide /etc et al by default.

Other improvements that could be make the file hiding mechanism in Gnome is to make it user sensitive. That way folders could be hidden on a need to know basis. E.g. a sysadmin or a developer may opt to see /etc if they want without having it disturb other userss that have no need for it.

BTW, there is one more directory that really needs to be hidden by default, and that is the Desktop folder.

Not that one more folder in the users home directories is that annoying. The problem is instead that of consitency.

In the GNOME spatial way of looking at things files and folders should only be visible in one place. By having the contents of that folder show up both on the actual visible desktop and in the Desktop folder users may be led to believe that they have two copies of the the files residing in the desktop.

If the user removes what he think is a duplicate he looses the file. To make things worse, the Desktop is not referred to as "Desktop" in the Places meny of internationalized versions of Gnome. This gives the non english speaking user even less clue that he should not delete "Desktop" in his home directory.

MHO the only visible files in the home directory should be files and folders created by the user himself.

BTW: The next version of KDE elegantly addresses the myth that all user activity takes place in the home folder and that the user never needs see the work of their collegues. It introduces a homes:/ location where users that shares their home folder is listed by their real name. This is a really good example of how UNIX-think have been avoided.

I wish Gnome could follow.

Reply Parent Score: 1

by Best on Tue 23rd Aug 2005 16:50 in reply to "RE[8]: GNOME vs KDE"
Best Member since:

Isn't this basically what I've been saying? An ordinary user will likely never have to go into the file system location. The way the abstraction of the underlying system is handled everything is available through autogenerated entries provided in the places menu and the items contained therein. The user IS going outside of their home, but its seamless for them, and they likely never realize it. I don't see what hiding everything does except make it harder to get under the hood when you want to. You talk about KDE's new shares system, didn't I already mention that Gnome already does this?

By the way, Gnome hides hidden files in the file open/save dialogs by default. Unhiding them is a menu option. I'm not sure what dialog you're talking about.

Personally I feel that gnome should by default use the home as desktop option. But many people don't keep their home directory clean enough for this to be feasable.

You might not have a bad idea about hiding files that aren't specifically created by the user, but this would have to be a fdo project, as it isn't just gnome that makes a Desktop folder, or that makes a unhidden folder for itself in home. (GNUstep for one), and these would all have to be auto-added to the .hidden file for it to work.

Reply Parent Score: 1