Slashdot Mirror
A Look at the Upcoming GNOME 2.6
unmadindu writes "GNOME 2.6 is just around the corner, and I figured out that many GNOME users would like to know what's in store. So I installed GNOME 2.5 (development version for 2.6) in my box, and came up with a list of the new stuff that are coming up. (and just in case, copies of the article are also available here and here)."
Part of the problem is that developers, being geeks, tend to have all the latest kit. So the GNOME hackers working on their 512M / 1G 3 GHz box won't be concerned about performance, but the millions of desktop users running lower-spec machines will.
Let's be clear about this: the vast, VAST majority of machines on the planet, in homes and in businesses, have 32M, 64M (and occasionally 128M) RAM. That's nowhere enough to run GNOME/KDE, OpenOffice.org and Mozill at a realistic and usable speed. When did we become just as bloated as Microsoft?
If the GNME developers don't step back, look at the problem and concentrate on efficiency and clean design (rather than flashy features and bloat), it'll lead to long term damage for Linux on the desktop. They're doing a great job bringing Linux to the masses, but the masses are going to be less enthusiastic about Linux when it keeps requiring hardware upgrades...
I've always thought that the reason having two (main) desktops (KDE and Gnome) is good is not necessarily because of the competition, but because there is a need to interoperate between the two, so sensible 'generic' programming interfaces need to be created. This should create more modular code, and modular code makes successful open source projects.
However, to what extent is this true? Can I, for instance, use just the Gnome file manager in KDE, and vice-versa? Is it an aim of these projects to make this level of interoperability a goal?
It'll be interesting to read a decent "neutral" KDE 3.2 vs Gnome 2.6 article though! And it also has to be said that the competition between KDE and Gnome really had driven both communities to excellence. Als competition has not deterred them from cooperating in freedesktop.org - something to be encouraged until hopefully one day somehow the libraries can be unified.........
Of those to whom much is given, much is required.
Have to say it, this was one of the best written personal review article submitted to slashdot in recent past.
It covers the functionality well, does not break the continuity and was fun to read.
If only we had more articles like this, slashdot might gain few more subscribers.
- mritunjai
That's the same argument Microsoft used to say that Windows 95 is faster than Windows 3.1. And on a system with plenty of memory, it is. But most people's experience with the hardware available at the time was that Win95 was much much slower, thrashing horribly with less than eight megabytes and still rather uncomfortable with less than sixteen.
Making a program twice as fast in CPU time but at the expense of using twice as much memory may not be a good trade-off. If you start running low on memory then you get a very steep performance drop from paging to disk (or not having enough RAM for disk cache, which is effectively the same thing). The most important benchmark is how it performs on a machine with, say, 64 megabytes of RAM, or whatever minimum level you want to require. Not shaving a few fractions of a second off times on recent hardware.
-- Ed Avis ed@membled.com
According to Google's Zeitgeist", Windows XP represesnts 45% of the market out there (well, of their customers/users). Windows 2000 represents 18%, and although it will run in 64MB, I don't view anything less than 128MB realistic. Therefore, I would guess that the majority of people are already using machines with 128MB or more.
I would assume it's because nautilus is a lot bigger than a gtk file selector. Anyway, a file selector is still required because people will choose to run your apps while the whole DE is not running. For instance, I run a number of GNOME and KDE apps on XFce4; I may have konqueror installed, but it never runs and I certainly don't have nautilus installed. Even if they were installed, if they were required to do file operations from Cervisia or Gnumeric I'd have to wait for those browsers to come up from a standing start when all I wanted was to open or save a file.
"Nothing was broken, and it's been fixed." -- Jon Carroll
GNOME vs. KDE will perhaps be one of the holy wars of this millennium,
Yes, and like most holy wars, it's about obsolete ideas. Gnome and KDE are both serviceable desktop environments, but let's not kid ourselves: imitating Windows and MacOS should not be the future of computing.
Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that,
Whatever makes you happy, dear. Personally, I dumped Mac OS X because I got tired of the manual upgrades and install hassles; Debian has been much less effort to maintain and has a lot more software available for it. And kernel upgrades just work, with no recompiles, with Debian.
Isn't Evolution a mail reader and not a file browser ? Or did you mean Nautilus ?
Or you could leave both options open and let people use whichever they want. Like it's done now.
Besides, if I have both mplayer and xine installed, how does the One File Browser know which one to launch ? Or Emacs and Vi ? Or whatever ?
And yes, I realize you can set this in preferences; but suppose you want to use different tools for different tasks, despite the file format being the same ? Or if I just want to try out a new program ?
Because that would mean resizing application windows to fit them besides the directory windows, and be a lot more hassle than simply using a selector window ?
No, it's a useability feature. Lacking a separate file selector would give users unneccessary grief.
The more features you bundle into a single program, the less likely it performs any of them well, simply because different features (such as useability and low learning curve) conflict with one another.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
This new spatial apperance of the new Nautilus reminds me of old MacOS finder. I liked it back then and I will probably like it in Nautilus.
But I am a bit worried, some folder hierachies in Unix is quite deep.
Perhaps they should introduce something like the Mac spring loaded folders.I.e. if you want to move a file down in the hierachy you just drag and hold it over a folder, after a short while the window opens, and you hold the file over a folder in that window, until that opens and so on. When you finally reach the right folder you drop the file, and all windows you encountered on the way is closed automatically.
God is REAL! Unless explicitly declared INTEGER
Not trolling or anything, but here goes...
As a developer, I have always been interested in writing software for Gnome since 1.x. The one thing that has really set me back from doing so is the fact that with each and every iteration, something in the very core of Gnome changes and more often than not, those changes mean that you would have to recode large chunks of your software to cope with the changes.
Yuh, sure all your Gnome 1.x apps will still run but it won't be able to use any of the new features in 2.x. This comes naturally, since this is after all a "major release" upgrade. They've really done it with 2.x this time, something major changes with each "minor" version is released. I know this is all about bringing Gnome closer into the "integrated desktop where you have everything you need to do everything you need" that it is trying to achieve.
Case in point, this whole new-fangled "Object-Oriented" metaphor. Now not only do I probably have to learn a whole new set of interfaces to get desktop integration going for programs that I write for Gnome, I also have to learn how to operate this contraption. I mean come on! Do we really need all this HIG crap?!? My UI was "usable", at least for me, before all of this HIG things were implemented. If the developers want to implement this HIG thing, then go ahead and do it but it would also be nice to let users with "bad habits" choose to revert to the old UI behavior when they want. And for heaven's sake, leave the API's unchanged until the next major release! Being a developer for Gnome is a lot like being Sisyphus.
Now I realise why there are more apps written for KDE than for Gnome.
</rant>
Yuh, I know this rant probably doesn't make any sense to you. But maybe that's because you haven't been around when Gnome 1.x was new and Miguel was still sane.
(puts on asbestos underwear and ducks under the sink)
Maybe they never used Windows 95 either!
... and of course, the option to disable it completely if you want an explorer like UI.
True Spatial Navigation is quite good really. As long as you have options for opening the parent folder, and autoclosing the parent folder when opening a new folder to keep clutter down.
Why is it that drag & drop fanatics are always trying to force their preference to everyone else?
EVERY TIME there's talk about file selectors, someone pops up and seriously suggests an option that not only encourages the need to use mouse, but actually requires it.
Especially for saving... instead of hitting ctrl-s (and quickly typing a name if it's the first time), I'm supposed to a) resize application window, b) locate file manager from open windows, or open one if it isn't running, c) drag icon somewhere? Excuse me, I think I need to puke.
Certainly none that matches the convenience of the Filer windows in RISC OS where you would double-click (or drag) a file to open it, and drag from the application to the Filer to save
:wresult3.txt, and in many contexts I'd be right.
That's subjective... I could claim that needing to drag an icon from a text editor to a whole other window (which I'd have to find and make visible first) is painfully slow compared to
That points to one big advantage of the dialog box approach: keyboard compatibility. Desktop environments which offer DnD should provide some (optional) way to perform equivalent actions from the keyboard, but I'm not aware of any having done so.
Digressing down that topic:
There have been some small steps made towards keyboard-controlled DnD, but I haven't seen any adequate yet. Of course, some systems let you push a button to steer the mouse from the keypad, but that's too awkward to consider. Some file managers include an abuse of the clipboard metaphor (like a Copy button which makes a "shallow copy", instead of a "deep" one like every other Copy command besides Excel) to provide features that could be better solved by enabling DnD via keyboard. There are assorted taskbar-applets which provide a "shelf" to set down an icon in mid-drag; enhancing one of those to be controllable by keyboard would be the most direct implementation of a solution.