Slashdot Mirror
Eazel's Nautilus Preview 1 Released
menthos writes: "Eazel released the first preview release of Nautilus, the new GNOME file manager in development, at the LinuxWorld Expo. You can Download Preview Release 1."
← Back to Stories (view on slashdot.org)
It does not even work on glibc 2.0 even if you hand compile it. Trust me.
If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.
And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.
Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.
-Nathan
PLEASE do not scream about the bloat (20MB download).
The only reason for this, is that most of the
libraries are alpha, and not present on ANY
production systems, hell.. some of the libraries
included could very well f* up your productionsystem good, if installed regularily. This means that the Nautilus-package (for it to be easy to install) has to include almost everything.
Of course this is going to mean a 20MB download.
Think about the size most apps would be if totally
statically linked. Nautilus-preview is not far from that.
In addition. It now downloads and installs
the FULL mozilla-app, while it when finished will
probably only use the mozembed-package.
All this means that the whole thing will move from
a 27MB download (with mozilla) to an about 9-10MB
download when it is all finished.
This is NOT too shabby for an application that is
graphical shell, web-browser etc.
Furthermore. A lot of people are bitching about it not being revolutionary.
What are you guys expecting?
This application will be able to embed about every
functionality on the desktop through Bonobo when
finished. Right now, there are not that many bonobo-components. But to get a glimpse of what
Nautilus will mean when finished, take a look
at the "music"-view when looking at a mp3-directory. This way of viewing directories is
just the beginning, and is TOTALLY different from
the way any graphical shell has operated on Linux,
and even on Windows earlier (I cannot speak for Macs).
Nautilus is not finished by far. But if you look
closely you may get a glimpse of what it may all
look like when finished.
The concept of different views for different kinds of people is excellent. And if you try to use
the "Novice"-view, you might understand how easy
Gnome may be to use come Gnome 2.0.
Considering that they're offering a source tarball as well, I would think you should be able to build it on any system.
I've been following the news on Nautilus and it looks pretty exciting to me. However, I only use FreeBSD and Solaris. It doesn't make much sense to me to limit Nautilus to Linux only, when Gnome holds so much promise for any system that runs X.
Hoping it's just a semantic error...
--
"While I support the ideals of this company, namely, to create a user friendly, almost 'mac-like' interface for Linux, wouldn't it have been better to refine a pre-existing one?" Such as...? I hope you don't say Konqueror, because I'll point out that that was a rewrite too (and a good one too!). Would you like to propose a pre-existing one that had a strong enough architecture that it would have been worth rewriting? In fact, adding necessary GNOME support (bonobo, gnome-vfs, etc etc) would have probably been more difficult than writing from scratch - almost all the original code would have had to have been nixed.
Code is only re-usable if it was written right. Period. And the architecture is part of what makes Nautilus great... You'll hear Miguel rave about bonobo but its true, Nautilus components are really reusable in other applications. And bonobo means that Nautilus *isn't* a total rewrite. There are some great bonobo components like EOG that we were able to just use off the shelf. What we're building is an architecture that means the next file manager revision, even if its by somebody else or a different architecture won't have to be a rewrite. (and yes, I am a Nautilus developer)
-seth (seth@eazel.com)
Major releases calculated to coincide with big trade shows. That has always been a sign of hype over substance.
At least this time it's not a 1.0 "stable" release that comes in the middle of a storm of new bug reports and latter had people excusing it with comments like:
"Of course it's ready. The developers have been in insane bugfix mode for the past week"
Yes,. This actually happened with Gnome itself. Linux, SaMBa, Apache, KDE, XFree. These are serious free projects that release code "when it's ready" and issue betas "when the software is complete enough to be called beta and normal people can help with bug tracking". Nothing but technical considerations are relevant.
--= Isn't it surprising how badly I spell ?
Its interesting that you bring this up. I don't want to go into a lengthy response, but the Nautilus architecture is in place to totally remove the necessity of a conventional filesystem for users who don't want to manipulate it. We won't drive that to the interface for 1.0, but post-1.0 almost all the underlying stuff is in place and will be tied in.
:-) The index files are pretty small (10 megs or so) and of course optional if you don't want this feature.
Medusa, which was developed at Eazel and will be part of GNOME 1.4 is a disk cataloger and search tool similar to slocate - except that it indexes far more than just filename. It takes about 30 minutes to scan a normal to large disk, and of course isn't going to be doing this while you're working
So what does this all mean? This means that arbitrary, complex searches take a couple seconds to run. Medusa is *also* interfaced in through our virtual filesystem. So, the term I like to use for it is remarkably similar to what you quote... Medusa *is* a multi-key semantically queried virtual filessytem. And yes, post-1.0 this will be tied into virtual folders that are actually "searches" that will live update as you change the disk, etc etc. And it will be *fast*. That's only one example of all the things Nautilus architecture is letting us do...
-seth (seth@eazel.com)
Linux is great. I like it. X is pretty fscked and makes it hard to do some things. X is great because its so networkable, etc, but X is definitely showing its age. This sometimes limits what we can do. There are things we'd like to do but couldn't because of Linux too, but all in all Linux (do to its draw on Unix) is a pretty good architecture, and at least its really stable :-)
I strongly doubt that you've actually used Nautilus, because it doesn't work like explorer. In fact, I thought we'd be flamed to death for it working so much like the Macintosh, but a bunch of lam3rz saw the sidebar and rather than actually looking at Nautilus decided that it looked like Windows Explorer. Guess what? We aren't exactly running explorer next to our development stations. And I'm not hearing people bitch about other free software products like Evolution, KWord, AbiWord, and KDevelop (not to dis them, they're great products - if somethings good by all means copy the good stuff!) that rip off Microsoft products interfaces DIRECTLY - to the menu organization level in some cases.
So guess what? Its not windows explorer. People don't think of mobile phones as computers, and hopefully Nautilus will be intuitive and physically consistent too. Explorer does a lot of things right, and has some good underlying architecture, but they just don't get the final result right. Its really missing in the "feels right" department. And Nautilus isn't. Even this really preliminary release, slow as it is, should give you a feeling for how cool Nautilus is going to be.
And its not a simple file browser. File browser is stupid and limiting. I'm too tired to really go into why its not, but basically Bonobo means that Nautilus can do a lot more to interface you with your documents, data, code, etc etc.
Besides all this, when you actually use Nautilus it looks nothing like Windows explorer. Nautilus has a lot of great eyecandy. Our sidebar is actually fucking useful too, not just wasted space (though I often prefer to turn my sidebar off, all that being possible and configurable of course). The sidebar allows you to access meta-view components like a tree browser, a drag board, annotations, man/info browser, etc etc (all componentized, so its easy for anyone to add new ones, we just have some sample ones).
Try Nautilus. Those who have just looked at screenshots...Fuck off. Come by the booth at LWE and I'll talk about the architecture. It rocks.
-seth (seth@eazel.com)
That's a user preference setting. Set your user level to Intermediate or Expert, and go to Edit Hacker Settings. The first option lets you open each item in a new window.
..do two things
/etc) I have to load up an entirely new GUI from the command line.
.' command. Now I'm in Linux I find I can't swap backwards and forwards easily, and end up doing everything from the command prompt - but I shouldn't be forced to do this.
1) Run occasional 'commands' as root. I tend know the root password (and therefore should be able to do what I want when I want,) but for obvious reasons I don't want to be running as root all the time. At them momement if I want to use my GUI to perform an action as root (e.g. copy a file into
2) Switch between GUI and command line easier. Back when I used to use Windows I did this with the 'DOS Prompt Here' Power Tool and the 'Start
Can anyone tell me of a GUI File Manager that has these facilities?
-- Sorry, I can't think of anything funny to say here.
Well, I've spent a half hour or so playing with Nautilus now, and I have to say I'm impressed. There's a lot left to be done with optimizations and bug fixes, but as nullity said, it does just feel right to a surprising extent.
I like the Novice/Intermediate/Hacker menu.. it feels surprisingly intuitive. I'm not used to working with software on Linux in which you look at something and immediately feel a ghostly sense of the perfect metaphor perfectly drawn and shaded hanging on, but I get that sense in several places with Nautilus.. the hacker menu, the way the drag select is rendered, icon stretching, the fact that if you drag an icon to the description panel on the left, you focus on the item you dragged, color and image dropping, and more. Much like with the Macintosh, oddly enough, but with some of the really nice touches of the OS/2 Workplace Shell thrown in. And browsing with Mozilla in Nautilus feels good too (although a progress/loading bar, right-click menus and keyboard page up/page down support wouldn't kill me).
I agree with nullity that Nautilus isn't going to truly 100% come into its own until Bonobo gets moving, but I can imagine living in Nautilus, and that's the first Linux environment I've felt that way about other than the command line.
Congratulations to all involved! Now, when will we get the ability to use the Nautilus shell as the default desktop background, a la gmc?
- jon
Ganymede, a GPL'ed metadirectory for UNIX
I only need one shortcut to work quickly in linux: ctrl+alt+backspace
- Everything that you like, sucks.
Yeah, I know you can come up with some drag and popup system to handle appends. But that's not the point. You can't handle every possible command, so it would be nice to have something there for people who know what they're doing. It *IS* possible to get the benefits of a GUI and the efficiency of a CLI in one if they had this.
What if I want to remove all mp3's in the current directory? Watch me do it faster with "rm *.mp3" than you can with the mouse. And like I said, you always have the option to open up an xterm and do it, but that's an unnecessary step in my opinion.
And of course, in the "Beginner" mode of Nautilus they wouldn't have to see the shell -- perhaps Expert mode only.
Nautilus could probably be 3x faster or more when its optimized (before release). We have major algorthimic slow-downs like n^2 algorithms still in the code, but they'll all go away (and its fairly easy). We're almost to the "Feature complete" milestone, and then we'll be in hardcore performance and bugfixing mode before release. Pavel Cisler, who wrote a lot of the file stuff on BeOS (which is *FAST*, like faster than ls!) is working on Nautilus and intends to give it serious speed boosts.
-seth (seth@eazel.com)
id3 tags are in MP3 file because they're part of the MP3 file format spec. Ditto .xcf files. In order to attach similar metadata to other filetypes that don't already have metadata blocks, you need a scheme at the filesystem access level that manages and accesses a "shadow" filesystem or a database containing this data. In other words, something like the MacOS's resource forks, which have been around for over 15 years.
The problem, of course, is that the internet's file-transfer protocols like HTTP, FTP, NFS, SMB and, heck, DCC transfers over IRC, have no notion of multi-"fork" files, designed as they are around the Unix/DOS/CPM/etc. file model. This is why Mac users often user Binhex or MacBinary formats to Base64 encode files they transfer over the 'net. What's actually happening is the file itself and its resource fork (where the icons, metadata and so forth are stored) are being packaged together so that the two parts can be reconsitituted when they're received on another Mac. As the Mac world has gradually strived to interoperate better with the rest of the computing world, less and less of a file is being stored in resource forks. Where once all the bitmaps and dialogs and audio samples used by a Mac database or multimedia file might have been in the resource fork, now cross-platform compatibility has cut that back to little more than a file's icon and its mimetype.
The problem with doing this on Linux--or any Unix or on DOS and Windows, for that matter--is that the tools that read, write and move files around aren't built to accomodate multipart files, apart from limited support for things like versioning in some of the more advanced OSes.
If you want to do something like this without changing the file formats themselves, you need to start by getting down to the filesystem level so that all read and write operations also read and write the metadata, whether to a database or to parallel invisible files, transparently.
There are also several screenshots and some nice blurbs that should make things a lot clearer. Something you can't see from the static shots is a simple yet elegant animation - as information flows between filters, the little connector lines fill up. I personally think this is an excellent GUI representation of the entire "pipe" concept, and would probably make a good starting point for someone who wanted to make a similar utility for Linix/*nix
But then, males would download more nuts from the Internet to claim that they have more and bigger nuts than anyone else. Hmm, have to think about that one...
--
--
The early bird catches the worm. The worm that sleeps late lives to see another day.
If you ask me, I'm not sure I want to have huge icons, inline rendering of images, crazy mp3 player integration, and all that stuff. Now, something really cool, would be some sort of xml based info reporting scheme that let something like a file browser ask the program that handles the mime type of a file to give it some info about the file. Something like, mpeginfo filename.mp3 returning bitrate, length, id3 tags, etc. Or imageInfo image.xcf returning the number of layers, colour (rgb/indexed/etc), dimensions, compression ratio, etc. Then integrating that info with the file browser. I'd be into that :)
:) But I hope that people get the idea. It would amount to adding a new field for mime types - something like 'info program' or something. Then, for each mime type, a simple info gathering program could be written based on available libs. Should be fairly easy to do. I wouldnt mind seeing the rendered image, etc, if I click 'more info' or something, but the varying dimensions of images could make viewing look 'unbalanced'.
I doubt that I explained myself too well
I haven't had a chance to install and look at Nautilus yet, but looking at the Nautilus web page struck me as an example of trend I really don't like. The installation instructions at http://download.eazel.com/download.html tell you to download the tarball, su to root, cd to /, and type 'tar -zxf (tarball). Not only is this a sloppy way to install software, it's also *dangerous*. One of the first things I learned as a Unix admin is "never do anything as root that you don't fully understand", and while nobody is ever 100% scrupulous about this (we've all typed 'make install' without reading the sources), there should still be an effort made for 'safe computing' - an option to run a new program safely from the user's home directory, for instance.
I spotted an even more unsettling example of this phenomenon on the Helix Gnome website the other day. The recommended install process consists of su-ing to root, then typing 'lynx -source http://url.com/ | sh'. Umm, sure, what better way to make the install process user friendly than by having you download a shell script from the net and run it as root, sight unseen.
What the hell is wrong with these people?
I agree that if Linux is going to gain popularity as a desktop platform, it needs to be made easier to use for non-technical people. But real thought needs to be given to those things that make Unix a better desktop than Windows -- mainly security and stability. Unix/Linux has held out remarkably well against the plagues of viruses, trojans, and so forth which cause problems in the Windows world. Encouraging practices like installers that unnecessarily require root access are a huge step backwards.
If you've actually tried the preview and you have any kind of feedback about Nautilus, whether bug reports, feature requests, wishlist items, etc, let us know!
You can reach the Nautilus developers on or #nautilus on irc.gnome.org. Or you can post bug reports or feature requests directly into bugzilla.eazel.com.
This is our first preview release so it is our first change to get feedback from the community. We want to know about everything you guys think can be done better.
I'm also goint to look over these comments and see if I can bring problems that users are having to the team's attention.
- Maciej Stachowiak
P.S. I wonder if this will get moderated up - actually being a developer of a product doesn't seem to count as very Informative these days!
So, let me get this straight...
:(
The pioneers of Apple, NeXT etc. throw away the rulebook and decide to revolutionise the way we use computers using Linux and X as the base.
And we get... a file browser. Can I even bring myself to say it? Yes: Explorer, guys. It looks like windows explorer. Immeasurably dissapointing.
I tell you, mobile phones, PDA's, they *own* the future. People don't even think of mobile phones as computers (mostly because they don't go wrong).
*sigh* Glad I stayed away from client side.
Dave
I write a blog now, you should be afraid.
I'm following in the footsteps of an earlier poster in saying that I'm disappointed to see Apple and NeXT's best and brightest come up with... a file browser. I'm just as disappointed as I was five years ago when I signed up to be one of the first fifteen-hundred BeBox developers, after I discovered what their idea of "revolutionizing" the operating system was.
To quote Alan Cooper, from About Face: The Essentials of User Interface Design:
Fundamentally, I'm a bit tired of hearing about how everyone's "revolutionizing" everything, when they're really not. Look: revolution and revolutioniz e both imply "sudden, radical, or complete change". The American colonies didn't fight the Revolutionary War to install a local king. The French Revolution wasn't so they could hire a newer, prettier cake-eater.
The file system, fundamentally, is an implementation detail. It's an artifact of how "things have always been done". It's a drag on doing real, substantive improvement to the way computers work for people. There are millions of people out there who have never used a computer, and have yet to learn. They don't need to learn what a filesystem is, or to navigate it. They need to be able to find and use the information and tools that are important to them, period.
If we truly want to revolutionize the user interface, the user experience, etc., then we really need to start with a more fundamental re-thinking of how things work. Some of the ideas Miguel de Icaza outlined in his Let's Make Unix Not Suck talk/paper are a good starting place. The universal presence of an ORB, lots of small tools cooperating via the ORB interactively, are all good kicks in the pants of the Unix mindset. But, fundamentally, that's nothing more than what Redmond is doing with COM*, etc. There's more work to be done. There's ripping out the filesystem as a mechanism for data storage and retrieval, and replacing it with a dynamic semantic network, allowing information storage and retrieval (don't confuse data and information). There's moving away from skins and into real, powerful, direct-manipulation user interfaces. For those of you that remember OS/2 and IBM's System Object Model, there was some very, very powerful technology underneath all of that! Hell, you still can't reliably drag a document over top of the printer and have it "do the right thing" in Windows or Linux like you could in OS/2. And that was CORBA all over the place, too, so there was plenty of room for those services to make their way out over the network.
Don't even get me started on package management and installation management, or system administration. Suffice it to say that very little of our technology is designed to help us achieve our goals. It's a lot of work, but this community has boundless energy, and the opportunity and environment to do things that are truly revolutionary. We revolutionized the development model, now let's revolutionize the technology.
Nonetheless, I'm pretty impressed with this thing for a preview release of version 1 software. It looks like it may surpass the Mac and Windows file browsers fairly soon...
Oh wait, I forgot, the idea of anyone using a decent GUI filemanager on Linux is just plain painful to the CLI folks. I guess all GUI development should stop so that those people aren't annoyed by the very existence of other ways of using a computer.
BTW, I love CLI, but when I want a GUI, I just use it and don't fret over the lost masculinity.
Hey eazel folks... keep up the good work!
That users can subclass and that can support simple messaging(a well defined interface is inherited from Object and used by all nodes on the scene).
WHY? well the advantages are obvious aren't they? In this age of always(we wish)on networking it would make sense to represent the most commonly dealt with domain objects as clearly as possible. Bruce Tognazzini made the suggestion that people ought to be first class elements of any net oriented UI. And of course if you have people they have places to go things to do people they do them with, things they need to do them, places where they can work undisturbed, places where they can choose things or make things, places to meet other people, etc, etc. until you reach a place that... well you don't really want to go there now do you?
The neat thing is that it's possible to do almost all of the messy parts in the XML layer, for which there are numerous commodity tools and libraries. It should (in theory) be crossplatform (assuming platforms are compatible to standard). ;-)
My major worry right now is whether most of the SVG clients are going to support in-picture-links as that would be the way to implement most of the method calls on objects. Greatest possible thing would be to be able to write the methods in scheme
Does anyone else get the idea when looking at Eazel's logo that the poor penguin is about to be squashed under the weight of the precipitously balanced puzzle piece? I hope it's not an allegory for Eazel's products' stability or performance.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
I haven't tried the preview release yet because I'm at work and can't, but hopefully someone familiar enough with Nautilus can answer this.
Is there any support or capability to do complex shell operations in Nautilus? For example, in the CLI you can append two text files by typing:
% cat file1 >> file2
This is great -- appending files with very little effort, something probably not possible in Windows Explorer. Now, what I'm wondering is, how could this be done in Nautilus? Rather than trying to think up of some GUI analogy for this _specific_ operation, I think it would be best to have some kind of "shell command prompt" sitting below the GUI file listing -- where commands entered would execute with respect to the current directory in Nautilus. The listing would usually need to be refreshed after execution, too.
There's endless possibilities to this, like selecting the file icon and having it paste to the text input box, or having it pass the selected files as parameters. I can't be the first/only one who has thought of this, and I would be suprised if Nautilus didn't already support something like this. Basically, this type of thing would be preffered over opening a new xterm, cd'ing to the right directory, and doing what you want.
So is it already there with a certain option enabled, or does the capability exist through some customization/component building?
IMO the whole 'folders' full of 'documents' doesn't quite do it for me. This analogy simply doesn't work in relation to a UNIX file system.
Someone needs to think of a really clever way of visualising the directory structure so that it makes sense both logically and metaphorically, hence more intuitive.
Icons and windows must die, we need a genius to create a new analogy!
Just one of the many people who have put this question out there...but.
Does ANYONE actually try software/read articles/whatever before posting here? Seems like over half of the responses in this topic are inane, given that the poster wouldn't have even posted had they gone ahead and tried the software.
At any rate, the software is quite cool, and also customizable (and pretty). As everyone should know, its not a finished product, so take what you see with a grain of salt.
Anyway, keep up the good work...its nice to see a large # of options out there.
It looks as though Eazel, like many other interfaces, makes use of a single-window file browser. Personally, I prefer a multi-window browser such as the current Mac Finder, in which opening a folder normally causes a new window to appear with the folder's contents in it rather than displaying the contents in the same window.
This design seems to be common in other interfaces, including Apple's new Finder in OS X, and it does seem to have its advantages - reducing screen clutter, for one. However, I find multi-window interfaces more useful to me; for example, when working with groups of files in different directories, or moving files around into different folders, it seems easier when opening a folder creates a new window.
It's worth noting that I've been a Mac user for years, and my opinion may be derived at least in part from my growing accustomed to this way of working. I'm open to the idea that a single-window browser may be a more effective interface, though I'm not especially fond of it at the moment.
The only Linux box I use regularly is a relatively slow system used primarily for server-type functions; I don't run X often, so I'm far from an expert on graphical interfaces to Linux. However, I'm curious as to whether there are any interfaces that use the same sort of multi-window design that the Mac Finder does, and why the single-window file browser seems to be more common these days.
Life is far too important to be taken seriously.