Slashdot Mirror
Gnome's Nice Little GUI Perks
asdren writes "
Steven Garrity has written a short
article highlighting some 'user interface niceties' found in Gnome
with regards to file renaming, screen captures, fonts and file zooming." Garrity points out that "... tiny details can have a significant impact on the user experience
on operating systems. Inconsistencies that seem insignificant when
considering individually, but together they degrade the overall polish and sense
of stability in the system," and points out a few places where Gnome manages to avoid such inconsistency.
A google cache link is available here.
*twitch*
Site seems to be down already, heres google to the rescue:
Google cache
But surely you did think it's a GUI, which is what the article is about.
Getting to Know Gnome
by steven [10:56 PM February 3, 2004]
For the last few months, I've been using Fedora, a Linux distribution, as my primary operating system along with the Gnome desktop environment. Linux as a desktop platform still has lots of weaknesses, but I'm generally pleased and am very much looking forward to the progress planned in the next year.
I've written plenty before about the tiny details that can have a significant impact on the user experience on operating systems. Windows XP is rife with little visual glitches and inconsistencies that seem insignificant when considering individually, but together they degrade the overall polish and sense of stability in the system. It's like seeing cracks, no matter how small, in a bridge you're walking on.
I've noticed a few little user interface niceties worth sharing:
Smart File Renaming
In Windows XP, one click selects a file, then a second click (and a short delay) renders the file name editable. In Mac OS X, any click on the file name renders the file name editable. In my experience, on both platforms, the file renaming functionality is triggered by accident far more often than it is intentionally.
Gnome, and the Nautilus file manager (the equivalent of Windows Explorer or Mac OS Finder) allows you to rename files only by right-clickling and choosing "Rename..." from the context-menu. While it may seem like the function is "hidden away" behind the context-menu, give that renaming files is a far less frequent tasks then double-clicking on them or moving them (click+drag), this is an appropriate trade-off. Accidentally triggered the file-renaming functionality in both Windows and Mac OS, I'm happy to report that the Gnome technique is much better.
Also, when you do rename a file, the file name, not including the file extension is selected by default. So, if I want to rename a file called Diary.doc to Journal.doc, I right-click the file, select "Rename...", and type the new name. The ".doc" file extension isn't select by default, so it goes unaffected. In the rare case that I do want to rename a file, including the extension, I can easily manually select the extension as well. To do the same task in Windows, you must re-select the first part of the file name, manually excluding the file extension (which takes a fair amount of manual dexterity with a mouse) to avoid removing the file extension (Mac OS gets extra points here for avoiding file extensions where it can).
Smart Screenshots
In Mac OS X, when you take a screenshot, a PDF file is placed on the desktop. PDF is an awkward choice for a file format for a screenshot and if the desktop is obscured by windows, as it often is, then there is little feedback of where your screenshot has gone (though, to their credit, the camera-shutter sound is the best audio feedback of a screenshot on any platform). In Windows, the screenshot is sent to the clipboard, and then must be pasted into an application for use. Again, there is no feedback as to where your screenshot has gone.
In Gnome, when you take a screenshot, you are greeted by a window with a preview of your screenshot with options to save it. You can also drag the preview from this window directly into an application (an image editing application, or into an email for an attachment). Nice.
Don't Tie My Hands
Using Windows Media Player, it is quite difficult to get a screenshot of a playing DVD. If you take a screenshot while a DVD is playing, you'll see a big empty black box where the movie should be. In order to overcome this issues, Totem, the movie player I'm using on Linux (which is a great, simple, media player - something that doesn't seem to exist on Windows) there is a tool built in to take screenshots of a playing movie. Under the "Edit" menu, select "Take Screenshot", and you'll be presented with a window much like
A symbolic link in windows is known as a "shortcut" You can create one in Konqueror by dragging a icon from one window into another and then selecting "Link here". No command line needed.
The KDE and Gnome guys have gone long ways to eliminating the use for the command line, so your complaint about java is obsolete. It just works in most distros. Just install the java rpm from the package manager in your distro.
In Windows XP, one click selects a file, then a second click (and a short delay) renders the file name editable. In Mac OS X, any click on the file name renders the file name editable. In my experience, on both platforms, the file renaming functionality is triggered by accident far more often than it is intentionally. Gnome, and the Nautilus file manager (the equivalent of Windows Explorer or Mac OS Finder) allows you to rename files only by right-clickling and choosing "Rename..." from the context-menu. While it may seem like the function is "hidden away" behind the context-menu, give that renaming files is a far less frequent tasks then double-clicking on them or moving them (click+drag), this is an appropriate trade-off. Accidentally triggered the file-renaming functionality in both Windows and Mac OS, I'm happy to report that the Gnome technique is much better.
Wait, so just because the guy is clearly incompetent at using any form of pointer input device, the GUI is to blame?!? I use Mac OS X every day and I think it is far more efficient at renaming files, which I have to do regularly when downloading journal articles from the likes of Jstor.
In OS X, if you click on the filename then the rename option becomes available. If you click on the icon, then you select the file. Predictable behaviour in my opinion, and allows you move and select files just as quickly, but rename even quicker.
This guy is clearly looking for reasons to justify GNOME's eccentricities and poor design, and seems to be ignoring the immense research that Microsoft and Apple put into interface design.
Using Windows Media Player, it is quite difficult to get a screenshot of a playing DVD. If you take a screenshot while a DVD is playing, you'll see a big empty black box where the movie should be.
I'm no fan of WMP (I use BS Player or Windows Media Player Classic) but it's easy enough to get a screenshot from it, just turn down hardware acceleration.
"There is no time, sir, at which ties do not matter," Jeeves, (Jeeves and the Impending Doom)
"Never, never, never, put an option only in a contex menu. It is very bad design."
The "Rename" feature is also available from the "Edit" menu in the Nautilus menubar.
To which I retort: BS Player. And his points about screenshots could easily be combined, I'm not seeing much content in the article to be honest.
These things are called Labels. They've been in the classic Mac OS for more than a decade.
That and weird little things like not being able to use wildcards in the file open dialog boxes.
Yeah, that's real weird. In fact, I wonder why no-one's ever written a file manager that can select files based on regexes.
Oh wait, somebody already did.
Advances? You must mean "copying" from Windows.
"In Mac OS X, when you take a screenshot, a PDF file is placed on the desktop. PDFis an awkward choice for a file format for a screenshot and if the desktop is obscured"
As a open source developer who develops Cocoa apps on OSX, i regularly take screenshots of my apps and put them on sourceforge. Im not sure what OS this guy is using, i definetly take my screenshots as TIFF of Jpeg
The war with islam is a war on the beast
The war on terror is a war for peace
Good someone mentions this. The listview of Nautilus is pretty useless. You can't even drop a lasso over files. I was stunned when I first discovered this. I mean, that's what a filemanager is all about: Selecting files and doing stuff with it.
cu,
Lispy
Andy co-founded Eazel, and wrote much of Nautlius; all the UI touches mentioned feel like his handiwork.
One thing that most people completely ignore about OS X's file renaming is that even if the file is name is selected for editing you can still do pretty much anything with it. You can drag it (by its icon) anywhere, you can Command+Delete it, and so on.
About the only thing you can't do is cut/copy/paste because those actions are context sensitive and so operate on the text instead of the file. Of course, no respectable Mac user ever actually uses Cut/Copy/Paste on files.
In any case, compare the Mac OS X behavior with the windows behavior. You click once (on a files icon or text) to activate the file, THEN you can click on the text to rename it and better hope you didn't click too fast or else you open the file. When you do get into renaming mode if you try to drag the file anywhere it interprets the mouse down on the icon as "end rename" and totally eats it so now you have to release and click on it again. The bad thing about this is that it has apparently trained people to think that entering into rename mode "accidently" is a bad thing when on a Mac it really doesn't matter and the best course of action is to simply ignore the fact that the label text just highlighted because it really doesn't make any difference.
Right-click to rename is the lessser of two evils as far as I'm concerened. Double-clicking the name to rename a file (like Windows and classic MacOS) is a bit more intuitive, but the annoyance of triggering a rename instead of a file open because your mouse was 3 pixels off more than offsets the benefit.
"Right-click is for shortcuts but should never be the sole way of getting to a function."
Too many years using a one-button mouse....
"OS X has this one hands-down. Double-click a font and you get the whole repertoire, with a button that says 'Install Font' below it. It even asks you if you want to install for just this user, or all users."
Have you even tried Gnome, or are you just flaming based on the screenshots? Double-clicking a font file shows a full preview as well.
As for the browser, your hopes are too late. It's already been done. Epiphany is a simple interface with the useful features (like tabs) and none of the crap (like sidebars and themes) built on Mozilla's html renderer. It's quite nice. Of course, if your knowledge of the subject ran any deeper than looking at a few screenshots and posting a defensive rant about the superiority of MacOS, you would know that already.
0 1 - just my two bits
I do not understand why cut and paste cannot be corrected. If a program is closed, what was just copied from it disappears from the buffer.
a emon/index.html
This falls out from the way X was designed. I agree it's annoying. There is a fix now:
http://members.chello.nl/~h.lai/gnome-clipboard-d
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
1. You can easily create or install themes by clicking your way through or drag-n-drop, but there is no apparent way of REMOVING a theme.
Theme Details -> Go to Theme Folder [file manager opens ~/.themes], and delete what you don't want. Granted it's not as easy as selecting or editing themes, but normal people aren't going to be adding/deleting themes themselves anyway, so it's not important to make it idiot proof. Themes are available as packages and are installed/un-installed through the package manager.
2. You can't change the location a launcher or shortcut points to once you have created it. That's irritating if you just needed to move the file or rename one folder in a long path and don't want to go through the hassle of creating a new launcher, name it and select icon from a long list again.
That's not exactly what I would call "a glitch", it's an enhancement, but yes it would be nice to have.
3. You can drag-n-drop emblems onto icons from the sidebar, but you can't remove them in the same easy way. To do that you need to right-click the icon and go into a totally different dialogue.
Again... that is not a glitch, it's something that should be worked on. But it's hardly priority considering how often people use the emblem functionality.
4. View files as a list in Nautilus and there is no way you can right-click on the background to get the context menu in order to for example add a folder. You then have to do it through the top-of-window menu instead.
This is fixed in 2.5/2.6.
5. Listview in Nautilus again: you can't drag-n-drop a file from another window without dropping it onto an entry.
Ditto.
6. There is no way you can change the permissions or emblems of multiple selected files in one go from Nautilus. You have to address them one by one.
Huh? Yes you can, in the current stable version (2.4) and beyond: select the files you want to change the permissions/emblems of, right-click -> Properties, change the permissions/emblems to what you want. Done.
As someone who has done retail computer service since the early eighties, let me point out that MS-FUD is not an issue here. This is a real problem.
I have seen quite a few machines where windows wouldn't boot due to accidental file renaming, and quite a few from deliberate renaming through ignorance.
When the problem is pointed out, the response has pretty much the same: "Why does it let me do it, then?" or "Why is it so easy to do if it's wrong?"
I've also seen systems where children have done dramatic file renaming, because it's easily within their grasp.
Granted, this is not a huge problem, but it is consistant. More common is the bulk movement of system files via drag & drop.
From a technical standpoint, the double-click rename "feature" is actually a weak point in longterm system security/stability.
I heard about this on IRC and it worked! Go into Nautilus and load a directory in the list view. I think you hit Control F, however I don't remember the keybinding exactly. A small input box will appear at the bottom right of the window. Start typing and it will act as the autosearch in emacs/Mozilla. This works in any ListView in GNOME.
Gnome doesn't have this problem (and niether does KDE).
And neither does Windows XP if you set it up not to. This option (renaming a file by the given method) is only available if you set folder options to single-click-select, double-click-open. If you use mouse-over-select, single-click-open, then the right mouse button context menu is the only way to rename the file (ignoring the main file menu here).
I set every XP computer up this way, and advise people that a left click opens the file, a right click gives them a menu with options.
The fealing on the GTK list seems to be that there's a need for an entire new widget GtkFileChooser, and programs will eventually convert to this new API. IMHO, this is a very bad idea, as the oldstyle will never really go away any more than the win3.1 style has in the windows world. I think we ought to just add the new features and protect future APIs with preprocessor flags. Code for that might look like:
But that's for later. For now, the code that's up there works, and it might make your GTK-related life a lot more pleasantSig:Why copyright isn't a fundamental human right
Can't believe this got insightful moderations.
If you click on the icon, it highlights. That's it. If you click on the name, you can edit the name. There's more than one thing you can do, here, because the icon and the name are separate objects, when you think about it. (Ever renamed an icon? No, you rename the icon's name.)
If you click on the name and then decide you want to move it, you can still drag the icon to wherever you want it to go. Furthermore, if you highlight the icon and hit return, you can begin editing the name.
If you control/right-click on an icon name, you get the same contextual menu that you see when you do the same on the icon. And yes, if you click and HOLD on an icon name, you can drag the icon normally.
Let's recap:
1. Click on the name to rename.
2. Click on the icon to highlight.
3. Press return while the icon is highlighted to rename.
4. Click and hold on the icon or the name to drag the icon.
5. Control/right-click on either the icon or the icon name to see a contextual menu of frequently used commands related specifically to that item type.
This seems pretty goddamned good to me. You get complete functionality without a lot to think about. It's been this way for years, and we Mac users seem happy with it. How is right-clicking and selecting "Rename" any better than just clicking the frickin' icon name and typing away?
Mikey-San
Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
Better still, KDE has kio_fish, which allows you to access any ssh enabled server as a file server. Awesome stuff.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
-Don
The Nongraphical GUI
X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?
Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn't get all of those ugly fonts. It's a trade-off.
[...]
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cu
Take a look and feel free: http://www.PieMenu.com
On one hand we (meaning people that post on /.) praise Linux because of choice and then we praise the Gnome developers for deciding that their way is better?
If it was really a problem, making the required delay between clicks longer would probably solve the issue. That seems more reasonable than just arbitrarily deciding to remove or not implement the feature and call it an improvement.
which is why a right-click menu should NEVER be the only way of accessing functionality.
I agree, and it isn't the only way. All context-menu functionality is duplicated in the top-level menu. And you have hot keys. So for rename in Gnome, you have 3 options (that I know of):
1. right-click on file, rename
2. select file, Edit menu item->Rename
3. select file, hit F2
In my opinion, the mouse shouldn't be the only way to do things, there should always be a way to do it with the keyboard.
#!/
Maybe it's because PAN use Pango or whatever that library is called..
Gnome 2.x uses pango extensively through all the desktop, so I don't think it's that.
It is too bad you get confused. There really was no choice there.
Finally! A year of moderation! Ready for 2019?
I always use F2 to rename files in Windows. Little known shortcut key.
-]Phreak Out[-