Linux.com reviews GNOME 2.14, and concludes: “GNOME 2.14 continues the steady improvement visible in the last few releases. It is an incremental upgrade, consisting largely of tweaks and the filling in of gaps in functionality. If few of these changes are major by themselves, the overall result is welcome. Perhaps the best way of looking at the release is not as an end in itself, but as a milestone on the road to desktop usability in free operation systems. From this perspective, GNOME 2.14 is a sign that much of the journey is already over – and that the remaining distance is less than many observers think.”
I agree with reaching ‘milestone.’ I mainly use Konq because it’s more flashy but I do use allot of Gnome/GTK apps and the usability has really improved to the point of great ergonomics. The saving/loading/formats/folder/options just blow WinXP out of the water. With the 3d desktop finally we are also able to get rid of any screen flicker AT ALL and control every pixel on the screen without SVG; which is really nice all around for consistency on the eyes.
It seems like they improved their notification framework so it is at least on par or better then WinXP. The search is great although I am more of a C/C++ fan so I wonder what those implements will look like. Just for portability sake. Java maybe too.
Over the years there has been allot of confusion between 2d and 3d because of the introduction of graphics cards. Mainly it’s been because 2d libraries were not worked on that well but now even the enlightenment desktop has intigrated ‘3d’ features into 2d so you don’t need a graphics card etc. it’s just a marketing term.
So after everything is ‘done’ what’s next? Probably just tweaking I guess plus apps will always morph and evolve. I hope not too much though since everything is getting to be so great.
So after everything is ‘done’ what’s next? Probably just tweaking I guess plus apps will always morph and evolve. I hope not too much though since everything is getting to be so great.
What I would like to see next, is better administration tools for system administrators and less Unix fixation for ordinary users. To ordinary users Gnome should be an interface to get work done, not an interface to Unix.
Today most of the administration tools in Gnome are focused on how to admin one machine, not a network of machines. Just look at the user management tool, almost every Linux/Unix system available have been able to use some kind of catalog service such as NIS, LDAP or even relational databases. Still Gnome only support local passwd and group files. Sabayonne, the excelent profile configuration tool, suffers from similar problems.
Things like ACLs is now supported by most Unix system is very useful in large organization with complex group structure, so it should be integrated in the standard Gnome permissions dialog, not on some extra tab in the file properties dialog marked ACL.
Another thing, is that Gnome assumes that system administration tasks are performed by root and only by root. The things in the “System->Administration” menu all requires the root password. Why not use sudo. That way you can have many administrators in your organization. Ubuntu allready does this, but in my oppinion this should be part of standard Gnome behavior.
Speaking of sudo, it would be nice with some GUI tool to handle that, and once again such tool should be able to use LDAP to get and store its settings. Even better would be if that sudo tool was integrated with the useradmin tool, perhaps along with tools to manage things like quota.
On the user side of things, Gnome need to focus on things in the world of the user much more than things in the world of Unix.
Five minutes ago I got a phone call from a collegue lets call him John Smith. In the coffie breaks or in small meetings I address him as John, if the meeting is a bit bigger I address him as John Smith, in an even bigger setting I might present him as John Smith from the human resource department. Now, the most important thing, in everyday life I never ever adress him by his unix username jsmith03.
So if John calls me and tells me that he needs access to som of my folders and I agree to share it, I will need to know his username. Why should I need to know that? In a well designed interface I should be able to use the same name as I use in every day life. There will of course be situations where that name is ambigous and I will actually need to know it but in most cases I would not. This is an example of how developers must start to think in terminology taken from the real world domain rather than from the domain of Unix.
Another thing is all the Unix stuff like /etc, /proc, /lib, /usr, /boot, /sys, /bin, /sbin, /dev, /var makes little sense to other people than developers and sysadmins, so they should be hidden files. That way ordiary user will find things that they need for their work much quicker. An ordinary user would probably need /media /home /Programs where /Programs would be some kind of virtual folder with the same contents as the Gnome program menu. Today its allready possible to hide directories in nautilus using an .hidden file but unfortunately that .hidden file is not handled by file dialogs. This is unfortunate becaulse the need is much bigger in file dialogs than in Nautilus windows. Having many entries in a file dialog forces the user to scroll and as he does that the speed of finding what he want goes down dramatically.
By dragging an rpm (if you have a rpm based distro) file to my suggested /Programs folder that rpm should be installed, and all dependencys should be solved over the net if possible. Again sudo should be used to determin if the user was allowed to install things.
If the user drags a program with no GUI into the folder, a pop up should appear directing the user to some more advanced package management tool. (e.g. something like a slightly simplyfied version of synaptic)
I agree with some of your notions… such as system administration tools.
However I STRONGLY disagree with your opinions on hiding Unix stuff. Hiding files, folders etc. leads to MORE confusion in my opinion. The one thing I ablolutely can’t stand in Windows is the dumming down of the interface by hiding file extensions, folders and the like. I deal with a lot of end users who get very frustrated because things are hidden from them.
I would suggest that hiding operating system elements from the user should not be a Gnome or KDE thing. But more of a distro issue. I don’t want Unix hidden from me. I use Linux because it doesn’t hide things from me. If I didn’t want those things, I would just use Windows which is already nice and dumbed down for those who need it.
Hiding these files are not about dumbing down the interface. It’s about saving time.
In a file dialog you can select one file in a split second if you only have a handful of files to chose from. When you have seven or so files, you start to read the names. As a result your selection process is slowed down signifcantly. If you have so many files to chose from that you need to scroll, to see all of them, you will start to internalize the list of files in your mind, that takes time. You will also have to move the mouse to scroll, that too takes time.
If you need to see the files in /etc et. al. on a regular basis, you most likely fall into the category system administrator or developer. As such you should have no problem of selecting “Show hidden files” in Nautilus. You would also most likely have the knowledge to edit your .hidden files to your liking.
Most users don’t seam to get confused because they don’t normally see the 90 or so dotfiles they probably have in their home directory, so I doubt confused users would be a major problem. Hiding files like this also seam to work well on MacOS-X.
I agree with you, that what files should be hidden, typically could be a distro thing.
However, supporting the .hidden mechanism in file dialogs as well as in filemanager windows should be in standard Gnome and available regardless of distro. That way everybody could have as much hiding they feel comfortable with.
You are assuming however, that the user actually wants to select files from his root directory, which shouldn’t really be necessary. There are some exceptions, like the users directory. But the interface could provide a different mechanism to see the home folder of another user for example. So the problem could just as well be tackled from the opposite direction, and then you can keep the entire root directory visible in case the user _does_ need to access it for some bad reason.
Hiding these files are not about dumbing down the interface. It’s about saving time
So use the wildcards to narrow the list of files, or use Ctrl+L and type the name of your file, end of story.
You have every tools you need on Gnome to do this fast, no need for what you propose here.
In a file dialog you can select one file in a split second if you only have a handful of files to chose from. When you have seven or so files, you start to read the names
You got to be kidding. What you say does not make sense. In root directory, you should basically only have directories, but how do you select the ones to remove ?
If you have so many files to chose from that you need to scroll, to see all of them, you will start to internalize the list of files in your mind, that takes time. You will also have to move the mouse to scroll, that too takes time
So use the shell, or use the globing capability !! You’re talking about a problem with GUI there.
Removing directories is confusing nonsense. What if I want to go in these directories ?
If you need to see the files in /etc et. al. on a regular basis, you most likely fall into the category system administrator or developer. As such you should have no problem of selecting “Show hidden files” in Nautilus. You would also most likely have the knowledge to edit your .hidden files to your liking
But most of all, you would know how to use command line or Ctrl+L to get fast to the file you want in the Gnome file chooser.
All of your examples are easily solved in the current Gnome without any nonsense like hiding files that should not. You should not even use Gnome as root BTW.
However, supporting the .hidden mechanism in file dialogs as well as in filemanager windows should be in standard Gnome and available regardless of distro. That way everybody could have as much hiding they feel comfortable with
Well, then say that from the start, don’t put some stupid examples that are no issue : you want a technically perfect solution, even if it’s no use.
Well, I can’t blame you, if the file chooser does not support hidden files, it’s a bug.
Just my 2 cents, but hiding or not hiding stuff should be up to the user, surely? That gives them the power to set up their machine in a way they feel comfortable with. Of course there may be situations in which an admin does not want them to see hidden files, but in the main it’s a personal thing and not really a question of “dumbing down”.
I’m not sure this should be a distro specific thing. The trouble with that is that different distros may well come up with different approaches. A really clear, easy to find control panel set into Gnome or KDE (rather than in a specific program, like Nautilus) would be easier to handle for many folks. It could hang off a master config file in /etc, for example, so addressable by an admin with vim, with user-set tweaks in their home directories.
I’m not sure this should be a distro specific thing. The trouble with that is that different distros may well come up with different approaches.
There allready is a standard way to hide files in Gnome that works on all distros. You create a file called .hidden containing the names of the item you want to hide. So if you create a .hidden file in / containing:
etc
dev
these two directories will be treated as dotfiles in Nautilus.
The problem with the current state of things in Gnome is that the files are not hidden in the file dialogs.
The best way to configure it would probably be to add a checkbox “hidden” to the file property dialog. To hide a file you would then just right click on a file and chose properties and check “hidden” and the file would be unvisible. To make it unvisible just do “Show hidden files and then right click on the file and uncheck the hidden property.
What I meant should be distro specific was what files that should be listed in /.hidden. It would of course be nice if KDE recognized .hidden files as well. That way both Gnome, KDE, and MacOS-X would handle this in the same way.
But why should I have to add a file to the root folder to hide stuff? I should never have to do this.
The one thing I ablolutely can’t stand in Windows is the dumming down of the interface by hiding file extensions, folders and the like.
I don’t like the default behavior of window much either, but the nice thing about it is that I do have the ability to change it. I can tell windows to not hide the extensions and system files. If Gnome would do that then we could probably make a lot more people happy then just one way or the other.
I have to agree with virtually everything above. To address one specific point:
Things like ACLs is now supported by most Unix system is very useful in large organization with complex group structure, so it should be integrated in the standard Gnome permissions dialog, not on some extra tab in the file properties dialog marked ACL.
I seem to recall a post from one of the Nautilus devs on Planet Gnome detailing a new permissions tab for Nautilus which would support ACLs. It obviously didn’t make it into 2.14, but hopefully we’ll see it in 2.16
What I would like to see next, is better administration tools for system administrators and less Unix fixation for ordinary users. To ordinary users Gnome should be an interface to get work done, not an interface to Unix.
True, what I would also like to see is an underlying abstraction layer which elevates the whole desktop above the operating system, and rather than being based on linking back to the lower levels, it links back to a HAL, which provides a unified low level API, no matter which platform.
The problem there is now, to get GNOME and associated parts working on other operating system, there is either some minor patches in the case of FreeBSD or some major engineering feats in the case of GNOME on Solaris.
Take Totem, for instance, it links back to linux/cdrom.h (plus other Linux’isms), which mean that the application is literally glued to the Linux operating system rather than having a situation where by that kind of functionality can be provided via an abstraction layer – the programmer links to the AL, then lets the AL do all the dirty work of translating it down at the operating system level.
You are right about the need for a /Programs or /Applications like directory – keep all the low level stuff in /bin and the like, but the higher level, desktop applications should be shunted off into /Applications in self contained .app like directories – rather than having the various parts of that particular application sprawled from one end of the hard disk to another; dump all the parts which make up that particular application, put it in one location.
In the open source community… describing how things *should* work is equivalent to volunteering yourself to write it. As Linus says, “Show me the code”.
What I would like to see next, is better administration tools for system administrators and less Unix fixation for ordinary users. To ordinary users Gnome should be an interface to get work done, not an interface to Unix
I don’t understand. An example of a tool that shows ‘Unix fixation’ , which is an interface to Unix ?
Today most of the administration tools in Gnome are focused on how to admin one machine, not a network of machines
That’s because Gnome is a desktop, not a corporate desktop management tool.
For example, Novell provides tools to do what you want to do.
Next thing, you will complain that distros put users in passwd instead of putting them in a LDAP directory.
Just look at the user management tool, almost every Linux/Unix system available have been able to use some kind of catalog service such as NIS, LDAP or even relational databases. Still Gnome only support local passwd and group files
That’s a lie. I always used LDAP for storing my users and Gnome works without problems on my setup.
So either you’re wrong, or the problem is not a Gnome problem.
Sabayonne, the excelent profile configuration tool, suffers from similar problems
I did not use Sabayon yet, but I seem to recall it using pam when compiling. If it doesn problem solved. If not, well, it can be fixed, the tool is still young.
Things like ACLs is now supported by most Unix system is very useful in large organization with complex group structure, so it should be integrated in the standard Gnome permissions dialog, not on some extra tab in the file properties dialog marked ACL
I will not discuss design with you, but in FOSS, when someone spout the word “should” and that it applies to everyone, he better come up with some code or mockup to back it up. Yes it’s work, it shows that the person actually believe in what he says.
Another thing, is that Gnome assumes that system administration tasks are performed by root and only by root. The things in the “System->Administration” menu all requires the root password. Why not use sudo. That way you can have many administrators in your organization. Ubuntu allready does this, but in my oppinion this should be part of standard Gnome behavior
This is an enhancement to propose in gnome-system-tools then (I think that’s the package name). No need for sudo though, other packages use gksu and its libs to provide graphical su and sudo functionality.
Speaking of sudo, it would be nice with some GUI tool to handle that, and once again such tool should be able to use LDAP to get and store its settings. Even better would be if that sudo tool was integrated with the useradmin tool, perhaps along with tools to manage things like quota
Amazing that when people suggest things like that, it’s already done. Guess what, gksu already provides that GUI with a new widget (libgksuui) and a library (libgksu).
LDAP is taken care of by pam, and gnome-screensaver uses gdm and a gnome command line user admin tool, to provide fast-user-switching and other goodies.
So a Gnome admin tool can take advantage of these tools without problem.
No managing of quota though (I don’t use quotas, perhaps it’s integrated in Gnome already though).
Now, the most important thing, in everyday life I never ever adress him by his unix username jsmith03
Yet again, the most important thing is that a computer is not your life.
You will live through your name not being the same on the computer, I’m sure.
Anyway I could come up with a tool to get his computer name from his real name, assuming his real name was entered in Unix identification system.
Perhaps even ‘getent passwd “John Smith”‘ could do the job. Note than when well configured with PAM, getent on Linux will show me every users, in passwd, LDAP, Mysql, …
So if John calls me and tells me that he needs access to som of my folders and I agree to share it, I will need to know his username. Why should I need to know that? In a well designed interface I should be able to use the same name as I use in every day life
Nonsense. This has nothing to do with design, but with policy in your organisation. And even then, what you say is very dangerous.
Because there is a thing known as security you know. A username has to be unique by default, not your real name. You can bypass the uniqueness of username, but then, that’s your fault, you broke security on purpose.
Now, please, why people always feel the need to say things are how they are without a good reason or because of laziness ?
Why these people never research why things are like they are ? And propose stupid things that will break every good sense put into an OS ?
There will of course be situations where that name is ambigous and I will actually need to know it but in most cases I would not. This is an example of how developers must start to think in terminology taken from the real world domain rather than from the domain of Unix
Fortunately this has nothing to do with Gnome, and devs that had CS courses won’t listen to you …
There’s a reason your guy has the name jsmith03 you know … I mean, the 03 was not put there because it was leet.
Another thing is all the Unix stuff like /etc, /proc, /lib, /usr, /boot, /sys, /bin, /sbin, /dev, /var makes little sense to other people than developers and sysadmins, so they should be hidden files
No they should not, because “other people” will never see them unless they want to. By default, you are never put in /, so you won’t see them in Gnome.
That way ordiary user will find things that they need for their work much quicker
No they won’t. They are already put in Home or Desktop by default, so it won’t be any quicker if you hide these files or if you don’t.
An ordinary user would probably need /media /home /Programs where /Programs would be some kind of virtual folder with the same contents as the Gnome program menu
These already exists (except Programs which is the menu Applications) and are taken care of by Gnome framework. Next.
BTW do you actually use Gnome ?
Today its allready possible to hide directories in nautilus using an .hidden file but unfortunately that .hidden file is not handled by file dialogs
Is this really a bug ?
This is unfortunate becaulse the need is much bigger in file dialogs than in Nautilus windows. Having many entries in a file dialog forces the user to scroll and as he does that the speed of finding what he want goes down dramatically
You have a good rationale, except that there is Ctrl+L and I think there is globing too in the file chooser, which would break your rationale right away if it’s a fact.
By dragging an rpm (if you have a rpm based distro) file to my suggested /Programs folder that rpm should be installed, and all dependencys should be solved over the net if possible. Again sudo should be used to determin if the user was allowed to install things
BS. I don’t have RPM, so this is distro specific, nothing to do with Gnome. You were the one who previously do not wanted Gnome to be Unix specific. You want Gnome to be RPM distro specific instead ?
If the user drags a program with no GUI into the folder, a pop up should appear directing the user to some more advanced package management tool. (e.g. something like a slightly simplyfied version of synaptic)
Nothing to do with Gnome either, distro specific again. I don’t use APT either.
The most distro specific packages in Gnome actually manage a bunch of distros.
Distros have all the APIs they want to implement what you talk about, as GnomeVFS extensions and/or Nautilus ones.
Actually, some distros (like Mandriva) already do that when double clicking the package file, no need to drag and drop anything. I never clicked on a .deb file, so I can’t speak for Ubuntu or Debian.
When I see a review of software whether an application or a desktop GUI it does help to provide readers with screenshots. Otherwise for those unfamiliar with Gnome for example will have difficulty understanding what is being discussed. After all screenshots do help explain a persons point.
Edited 2006-03-19 18:41
Here are some: http://art.gnome.org/screenshots/gnome214
I’m actually using Gnome 2.14 through Ubuntu Dapper Drake Flight 5. It’s really snappy compared to the last release, and I have to say it’s smoother in usability. My overall experience is interesting. It’s not exciting, it’s not allowing. It’s just polished, simple and everything appears to be done a lot more quickly than before.
My number one improvement? The mouse. Normally in GNU/Linux I find the mouse sluggish. Click, tiny pause, something happens. With Gnome 2.14 I click, and stuff happens. This is what I really really want. I’m happy.
On a related note, the Ubuntu Dapper Drake version of Gnone has a lovely new theme. I was showing it to a non-Linux person, and they said “it looks like a Mac” (it does not really, but I think the polish and overall colour-scheme reminded them of the design concept behind Mac). It’s impressive, and I believe it’ll make great inroads into bringing GNU/Linux to more desktops.
“On a related note, the Ubuntu Dapper Drake version of Gnone has a lovely new theme.”
Yes it’s good looking.I only changed the window to darkX-2s with gnome art manager (superb app!!).
After being a long time exclusively KDE user.Gnome is back on my horizon especially while the menus are snappier.
A friend of mine who’s very much a Windows-only person using my laptop thought it was a Mac too! Now thats with FC4 (Gnome 2.10)..
I can see how someone not so familiar with either might make that mistake.
Dare I say that 2006 must be the year of the linux desktop
For those who want to see some of the cool new features of gnome 2.14 without trying it out, here are links to screencasts of new stuff:
http://www.gnome.org/~alexl/sabayon-screencast.html
http://nigel.tao.googlepages.com/deskbar-2-14-screencast.html
http://tw.apinc.org/weblog/2006/02/26/a-closer-look-to-gedit-214
excellent links! thank you very much for this post. +57billion mod points because it’s informative
I’m more of a KDE guy myself, but there is no doubt that this release contains some very nice improvements. Personally, I actually find it more confusing to not have a lot of options like in KDE, but nevertheless I’m starting to like Gnome more and more the longer I use it.
Is beagle intergration with nautilus, it’s just awesome and deskbar has Beagle live as well. Never has is been so easy to find files by just typing the first part of it’s name.
I used jhbuild to build 2.14 on Slackware and it’s FAST and nippy. it’s a real shame they dropped the Clearlooks-cairo theme because it’s nice, just means using gtk-engines 2.6.4 to get cario based themes working.
Edited 2006-03-19 20:20
While I think they have come a long way, I think one of the main things gnome developers need to work on next is the bug prevention capabilities. To be a bit more accurate they need to focus on fully automating systems that can be run on the code based regularly that measure and bring to light the performance of the system.
The little things that may other wise go unnoticed while more highly visible issues are dealt with when recognized, are what I fear will end up slowing Gnome (development & progress) down. It’s like the danger to ones life due to thousands of small bee stings, I think things like developing tools that automate the process of performance tuning and performance checking will be in effect the Smoke and Screen that keep those bees(bugs) away.
I am very happy to hear and see the boosts in performance and feel it is a good trend to continue. It has been mentioned [1] in the community but I think it needs further exploration and attention. It did seem to get heard as the current efforts indicate. The developers that have been doing the work on performance are obviously making good progress I just think if the took a step back and collected their various methods, developing some sort of system(framework, integrated build/testing system) they could end up helping themselves find more issues, fix more issues and ultimately deal with less recurrent issues.
[1]http://gnomerocksmyworld.blogspot.com/2006/01/things-about-gnome-th…
Some of you are complaning about Gnome missing this and that while in fact all you want is an application that does something. Yes linux does not have great networking applications to alow you to add user access to a file or folder through gui and the gui networking tools are some what lacking features but it’s hardly Gnome’s fault. Gnome is the destop environment and as it should never try to do every task possible.
Also I really have to give it to the dev team for increasing the temp of inovation and actually going back and fixing problems that have been long overdue for a bugfix ( something at which the Firefox team really sucks ). It is nice to see that Gnome finally started running fast like it should have been. Start up time has been reduced and a lot of other small things are fixed as well. Over all I think this is a great release and it deffinitely going in the right direction. Maybe Novell was the best thing that ever happened to Gnome … anyway keep up the good work and maybe it’s time to start working on gnome 3 …
I just installed Gnome 2.14 on my Arch box and I can attest to the fact that it *is* faster. It starts up faster and everything seems to launch faster. It is a big improvement.