Building Nautilus: Behind The Scenes
mholve points to this LinuxPlanet feature titled "A Sneak Peek at Nautilus from Eazel." Despite that title, it's not just a collection of bulleted feature lists and screen shots. Instead, it's a nicely balanced, in-depth look at the thought process behind the creation of Nautilus as well as a description and critique of the current preview. The article raises some interesting points about the complications that Eazel has found in trying to make Nautilus distribution-neutral: "In the future, I think we're going to have to look for a way to abstract the package system much in the same way we've abstracted the file system," [Darin Adler, Eazel software engineering honcho] allows. In addition, he notes that the diversity found in other areas of Linux distributions presents a daily challenge: "We try to get weirdnesses out of our code as much as possible, when we discover we've accidentally done something distribution-specific, we try to 'unweird it.'"
Cheers
Everything is but a number spoken by itself.
One thing I've noticed is that most of the file managers nowadays go on and on about how good their graphical interface is, how well implemented drag-and-drop is and so on, but almsot none of them touch on how the keyboard can be utilised.
I understand that some people would prefer to use the mouse to do everything, in which case something like Nautilus would be ideal, but how about those of us who prefer the keyboard? Adding in a good set of keyboard mappings is quite easy to do, but sometimes its sorely neglected.
I almost never use gmc. When I want to work with the filesystem, I open up an xterm. When I work in Windows, however, I use Explorer all the time, and one of the reasons for this is that its very easy to do everything with the keyboard. I can select a set of files, Ctrl-x them, Alt-Tab to another window, and then Ctrl-v them into the new directory. To me this seems much faster than arranging the windows and then dragging the set of files to the other directory.
One reason why I don't like dragging and dropping with the mouse is that I find it a bit stressful on my hand after doing that for too long. If somebody has a physical disability that prevents them from using the mouse in such a way, can he/she still use Nautilus?
I think it's good that Easel chose to work with the Gnome framework, but the reasons given in the interview left out a lot. The real reasons are more like:
1. Kde already had a similar product, Konqueror, well under development at the time. Konqueror is now in release state or very near release and is quite stable, fast and fairly efficient with memory use. While Kde always welcomes more developers, I don't think they would have wanted developers working at cross purposes with Konqueror so near to completion.
2. Kde and Easel have different philosophies. Easel is a money-making project started by entrepeneurs hoping to capitalize from application delivery and commercial services using the Easel/Gnome framework. Both are free software, but Kde's purpose is simply to provide needed free software to unix users, not to make money from such software. Gnome, through Helix and other spinoffs, already had established itself as a free desktop environment for the purpose of such capitalization by developers and entrepeneurs close to the project. This more than anything mandated Gnome for Easel.
3. Gnome did not have a competetive file manager/browser in the eyes of most users. Personally I like gmc *a lot* but it does have its limitations. Therefore Gnome had a real need for Easel.
4. Of course the licensing issue with Kde was a factor, and the only reason given in the interview which was legitimate. Not that the Eazel principals thought that there was a problem with licensing (they didn't) but the uncertainty among others made Kde a less attractive choice at the time.
I'm a big Kde enthusiast - using Konqueror right now. However, the competition from Easel will help Kde. Of course I think Konqueror already provides most of what Easel promises, and much more, although in some areas Easel will be innovating first. Integrated web/network/local search comes to mind.
The main advantage of Kde 2 is efficiency and speed, both for the user and developer. For example, Kde 2 is performing beautifully in most ways with my now antiquated P200mmx 32 meg PC. When it doesn't I bitch at the Kde developers and lo and behold they fix it the next week. "Your Kde is in deep shit! Now fix it!"
Everything, or almost everything, in Kde 2 really is a component either with a thin wrapper to make it a separate app or embedded in another app. It works smoothly. I think Gnome will have a lot of trouble getting that working without tremendous bloat and slowdown and stability problems - when it is *really* used by the vast majority of apps like Kde is using components right now, not just by a few showpieces or to embed a memory monitor into the panel.
I hope Kde learns something from Easel about the importance of a "finder" to users. It should be fairly easy to integrate that into the existing Konqueror with compnents and the results can already be displayed and manipulated in a number of ways with Kde 2. (Konqueror already has multiple paned browser windows and the ability to embed different views or viewers in different panes if you want to, though I usually prefer one or two panes).
Finally, on the choice of languages, if CORBA and bonobo really are language neutral, then the preference of the Easel developers for C++ should have been respected. But these interfaces really are not so language neutral after all. So, I don't think it was so much a matter of Easel being "pressured" by Gnome founders to use C with Gtk+. It was a matter of their realization that C with Gtk+ would be more likely to work with the Gnome framework and that C++ would cause problems for them.
Sure, you can use languages like Python and Perl to glue components together, but the components themselves usually are written in C, or C++, depending on whether Gnome or Kde is being used. It is possible to use other languages for creating components but no so easy to use anything other than C with bonobo or C++ with Kparts. CORBA is certainly not the magic bullet though it has uses in some situations.
I do know from personal experience that application development in C++ with Qt is a lot more FUN and faster than using C with Gtk+. This is especially true for more complex apps. I can imagine the cursing and swearing at the Easel workshop where coders are trying to use a mixture of Gtk's gimped up object oriented C, corba IDL, and a constantly changing set of libraries requrired to support Gnome and Gtk.
Anyway, I am quite impressed with what I have seen of Easel. They have done much in a short time under trying circumstances as explained above. Congratulations to the Easel coders and designers!
I understand the sentiment, but there's a difference between "spartan" and "highly usable." I think Gnome, et al, are going off in the wrong direction. They're interfaces for the sake of being interfaces. Arguably, that's okay, because for many people Linux is the operating system that exists solely to be an operating system :)
So, yes, I'd rather see less cruft devoted to customizing interfaces and fiddling around with a desktop, and more focus on real tasks. But if you take away flashy GUIs from Linux, you don't necessarily end up with more. You end up with something slimmer, faster, and more reliable, but often awkward and misdirected. The next step is to design something that's geared toward what people need out of computers. Jef Raskin has done much work in this area. The OS in the Apple Newton is another good example; it's more radical than most people realize. Open Genera is another OS designed with real problem solving in mind. Unfortunately, we're not seeing much in this direction any more, as being like Windows is seen as much more important (kinda surprising from the subversive Linux crowd, I must say).
I'm just going to say what we are all thinking. Well half of us anyway...
Some people like stuff like Nautilus, evolution, Gnome panels, really loaded root window menus, etc... Others like about 4 items in thier root window menu, gno panels (and I mean gnone), run emacs (as file manager, editor, ftp client, eye-washing area, short-order cook, etc), and just think that click-heavy interfaces slow them down.
As someone who prefers lightweight interfaces (text) in a slimmed down windowing environment without gnome, etc. I can also appreciate the attraction of a richer interface experience. But since I am not into gnome, etc, I am not going to say anything for or against it other than to thank all the developers and testers out there for all their hard work.
I do have a question though. Most of us who have been using a system that is highly configurable and application rich (I don't want to say "Linux" because there are lots of others) settle into a rut after a while with respect to the tools we like and how we want to have them layed out---whether we like lazy focus or click-to-focus, auto-raise, emacs, vi, etc.
When I sit down at my friend's Linux machine it's a bit wierd. Nothing works exactly like it should and I don't know where to find anything :) then I sit down at a Solaris box and the same disorientation follows. I prefer this to being in a monotonous environment but I want to ask if Windows users experience this same mild disorientation when they use other boxes than the ones they are normally on (do other unix users or am I am freak)? I am pretty sure Mac users do (again due to it's high configurability).
--8<--
--8<--
What's this about the Gnome project strong-arming the developers into switching from C++ to C? Leaving aside my religious beliefs in OOP, that doesn't seem in keeping with "open source ideals" at all.
It probably had something to do with the fact that Nautilius was going to be considered a "core" GNOME package. Since GNOME itself is written in C, not C++, I think it's reasonable to want all the core GNOME packages to be written in the same language. Utilities, applications, and what-not can be written in Perl, Scheme, or whatever else has a language binding, but the core program(s) should be developed in the same language.
This has a number of benefits, not the least of which is that the package is easier to integrate into the rest of GNOME, since those working on the other core packages can still read and understand Nautilus. It's difficult to get used to a C-variant language (Java, C++, C#) coming off of C, and it's not an adjustment that takes a couple of hours.
--
It's good to see some really experianced UI developers doing something with Gnome. I really wonder if they will fix all the little things that don't work well in X, things like the wheel mouse, TAB stops, consistant hot heys, even window focus - much bigger issues too, like an consistant way to install programs. an easy way to configure all my hardware (which drivers for will always seem to be in beta). and most of all SPEED Gnome makes me think my computer is a year older then it is. hell i can't even play Quake III on it without crying.
I'm a little out of the scene, are these already working well? Last time i used X I was an enlightenment or blackbox junky. I always found KDE and Gnome to be cheap 1.0 like rip offs of Windows, the really big important things worked. but all the little details we're missing.
Truth be told, I'm not going to use and *nix for a desktop until i get a decent browser. Mozzila seems to be coming around nicely. maybe in a year of so. So for now i'm sticking to Win2k.
-Jon
this is my sig.
This is no different than the closed source model, except that the end user DOES have the option of fixing the bug him/herself, if they choose. But in my experience they tend to only do this when they absolutely need to (original author(s) don't respond, or are dead, or something).
Of course, there are nice people out there that will once in a while submit not only a bug report but the fix as well...But this is a hard thing to do, because finding the source of most bugs requires a pretty deep understanding of how the code is working, which can be very time consuming.
Well, the short version of all this is that while many eyes DO make all bugs shallow, those eyes have to have brains attached that are capable of understanding the code and also enough free time available (and the desire) to learn the internals of the buggy program.
I've stopped using GNOME a long time ago to replace it with just plain enlightenment. I've recently started using EFM, the enlightenment file manager. While EFM is still pretty slow and buggy (version 0.0.0), it has many features which make it unlike KDE and GNOME's filemanagers. For example, if you begin typing in a window, a transparent box will come up so you can see what you're typing, with this you can do all sorts of things, from selecitng files to running commands to opening web pages. If you were to type 'www.slashdot.org' it will open a new NS window of it, typing 'make' will launch an Eterm running make in the current directory. EFM fits my needs better than any of the other linux FMs that I've seen, annd I can't wait for it to get more stable. Though nautilus has many interesting features which EFM doesn't, they're probably aimed at different audiences anyway, EFM is more 'graphical shell' than filemanager. Nautilus may be good for people who want an embedded web browser/mp3 player/etc. in their filemanager, but I think that we can all benefit from their work, regardless of weather we are interested in the filemanager itself.
Shine on, you crazy diamond.
Nautilus is certainly a fine tool, and a very good copy of Microsoft's IE-integrated file manager. But even the best copies of a bad interface are still bad interfaces. There is no need for quite a few of Nautilus' features. Foremost among these if the integrated Web browser (Konqueror is guilty of this too). A file manager is for managing files. A Web browser is for viewing files. To integrate the two is to create confusion, because you have the same app doing entirely different things (remember the OSX Dock, both an app launcher and task switcher? Same basic problem, though the purposes it serves are different).
Gnome doesn't need The App That Does Everything (neither does KDE, for that matter). All that does is lead to bloat, redundant apps on a system, and confusion for new users.
The Win/IE filemanager does have a few strengths, but these can be gained without bloating the filemanager itself. For example, the ability to show file information in a sidebar, rather than pulling up a new window for it. OSX's Finder can do this without the need to throw a browser in. The ability to navigate a filesystem using buttons in the toolbar is a Good Thing (particularly if you use only one window for file browsing), but you don't need a whole browser to do that (OSX's Finder, however, does this one very poorly; just a Back button which runs totally counter to the column-view paradigm).
I'm not trying to bash Gnome or KDE. I'm just pointing out that they're making quite a few of the same interface mistakes Microsoft made, and it'll only hurt them in the end.
----------
1 2 3 4 5 6 7
The home page for Eazel here.
...and their latest screenshots are here...