Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Look at the Upcoming GNOME 2.6

Posted by CmdrTaco on from the stuff-to-read dept.

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)."

46 of 428 comments (clear)

  1. Almost as interesting... by starseeker · · Score: 5, Interesting

    as the Gnome desktop itself is the fact he's using the freedesktop xserver to run it. I had no idea it was so far advanced.

    --
    "I object to doing things that computers can do." -- Olin Shivers, lispers.org
    1. Re:Almost as interesting... by be-fan · · Score: 3, Informative

      The FD.O X server runs existing X apps just fine. Since it was based on the already-working kdrive server, it should be working (varying degrees of "working") through most of its development cycle.

      --
      A deep unwavering belief is a sure sign you're missing something...
  2. Gnome 2.6 beta 1 release by Anonymous Coward · · Score: 5, Informative

    If you want to help Gnome 2.6, then you are in luck! The Beta release is here and it needs testing

    More details here

    Don't forget to report the bugs!

    1. Re:Gnome 2.6 beta 1 release by MenTaLguY · · Score: 4, Informative

      Having recently done a GNOME build from scratch on HP-UX, I had to work out the dependencies (I just used a makefile rather than figuring out the optimum order by hand).

      As far the core GNOME libraries go, though, here's an excerpt from the dependencies section of my top-level makefile. If you start from the bottom of this list and work your way up, installing the dependencies before you install each library/package, you should be OK.

      (you may already have some, like xrender, if you have recent XFree86)

      GConf: popt glib ORBit2 libxml2 gtk+

      libgnomeui: gtk+ libxml2 libgnome libgnomecanvas libbonoboui libbonobo

      libgnome: glib gnome-vfs libbonobo GConf

      gnome-vfs: glib libxml2 libbonobo ORBit2 GConf gnome-mime-data

      libbonoboui: gtk+ libbonobo libgnomecanvas libxml2 GConf

      libgnomecanvas: gtk+ libart_lgpl pango

      libbonobo: glib libxml2 ORBit2

      libgsf: glib libxml2

      libglade: libxml2 gtk+ atk

      gtk+: glib atk pango

      pango: glib freetype fontconfig xft

      ORBit2: popt glib libIDL

      xft: fontconfig freetype xrender

      fonts: fontconfig

      fontconfig: freetype expat

      atk: glib

      xrender: render

      render: pkgconfig

      glib: pkgconfig

      --

      DNA just wants to be free...
  3. Re:Windows Longhorn renders all this obsolete by grennis · · Score: 5, Informative
    Did you read the article?

    GNOME ... catches the SVG fever ... quite a few of the games have switched to SVG based graphics, which is a really nice thing, and a move towards the right direction

    FYI : SVG = Scalable Vector Graphics

  4. New File Selector - WOO HOO by starseeker · · Score: 5, Informative

    A new GTK file selector. FINALLY. I can't wait to use the new one - the old one was one of the great warts of the free desktop world, IMHO.

    But they have decided to remove the text entry box??? Eeep. I guess having the Ctrl-l shortcut to get one is OK (after all, it will most likely be geeks that want direct text on a file open) but thats one they need to document WELL.

    On the whole though, it might be a good thing. I guess we'll have to wait and see. But text box or not, it can hardly be worse than the old one.

    --
    "I object to doing things that computers can do." -- Olin Shivers, lispers.org
    1. Re:New File Selector - WOO HOO by hattig · · Score: 4, Interesting

      The best file selector in my opinion ever, was the ASL file requestor on the Amiga. It just worked (tm). Whilst the old GTK file selector was the worst I have ever had the misfortune to use, none of the others come close - Windows is annoyingly cludgy still (at least it is resizable now). KDE's isn't that bad though, certainly a lot better than a lot of the others.

      Then again, I think that the Amiga did a lot of things right for the desktop part of the OS, and in many underlying areas. Not bad for such an old, quickly written system.

    2. Re:New File Selector - WOO HOO by richie2000 · · Score: 4, Interesting

      I firmly believe the Amiga User Interface Style Guide should be required reading before anyone is allowed to even install a compiler with the ability to create GUIs.

      --
      Money for nothing, pix for free
    3. Re:New File Selector - WOO HOO by ultranova · · Score: 5, Insightful
      Since there is already a file browser such as Evolution

      Isn't Evolution a mail reader and not a file browser ? Or did you mean Nautilus ?

      To open a file, just view its directory and click on it; the application loads automatically and there is no real need for the two-step 'load application then use the Open menu', which dates from a time when computers didn't have a single GUI and there was no means to just open a file directly.

      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 ?

      To save a file, why not drag it from the application to the directory window.

      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 ?

      Matthew Thomas pointed out better than I could that the separate file-picker is user interface cruft left over from an earlier age.

      No, it's a useability feature. Lacking a separate file selector would give users unneccessary grief.

      Let's just have one file browser in the desktop and make it good enough to use for everything.

      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.

    4. Re:New File Selector - WOO HOO by Minna+Kirai · · Score: 3, Interesting
      1. Indeed, which is why RISC OS and ROX-desktop allow you to drag a file onto an application's window or icon.

        That still has failings: it doesn't guide you to which applications are valid for opening a certain type of file. If your system has many applications (typical result of a "Full" Linux install from commercial cdroms), then it'd be impossible to have an icon for every app without wasting pixels or inducing squinting. (Both of those are points of opinion that would bother some users and not others)

        The system in KDE's Konqueror filemanager is better because it recognizes multiple possible associations for each filetype, allowing a user to right-click to select opening something in the non-default handler. (KDE's approach still needs some improvement; the right-click menus need some streamlining, for example)
      2. You've got a little debate going between proponents of a separate filemanager application and those who prefer popup "Save As" boxes. Each way can have it's pros and cons. The big advantage a good SaveAs implementation can have is avoiding clutter (and extraneous actions like repositioning clutter) because the file widgets aren't displayed until they're needed. While a separate filemanager has the advantage that the user is more aware of it's context before needing to save, and thus needs to spend less time re-orienting herself when the window comes back up.

        Focusing on the "dialog vs filemanager" question ignores a more important UI design choice, though: Should each application include its own GUI code to pick files, or reference a centralized GUI system to perform that operation?

        Many of the problems you've cited with SaveAs are the result of poor and inconsistent implementations of dialogs, not file-dialogs per se.

        Ideally, the application program would be written at a higher conceptual level, where details like dialog boxes and icons are implementation trivia handled by a GUI control process. That way each user could load/save files in exactly the way she prefers, regardless of the biases of any specific application's author.
    5. Re:New File Selector - WOO HOO by juhaz · · Score: 3, Insightful

      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.

    6. Re:New File Selector - WOO HOO by Minna+Kirai · · Score: 3, Insightful

      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

      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 :wresult3.txt, and in many contexts I'd be right.

      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.

  5. Performance by Anonymous Coward · · Score: 5, Interesting

    When will we start to see serious performance improvements? Currently, GNOME doesn't feel much better than Windows XP, and it needs at least 128M to run acceptably with other apps.

    Linux is supposed to get us off the upgrade treadmill, but as far as I can see, GNOME just keeps getting bigger, slower and more complex. I've switched to XFce; it's so much faster. KDE is a hog too, but at least they're concerned about performance and efficiency as the 3.2 release shows.

    Really, this is something we should think about. When gconfd is eating up 20 megs (resident), just for a configuration back-end, it's evident that we're getting sloppy. A faster Linux could work wonders in terms of corporate and home adoption, but we just seem to be chasing Moore's Law and copying Microsoft for bloat.

    I'll try GNOME 2.6 when it arrives, but to give a better impression to newcomers we need to make things noticably faster, more elegant and more efficient than Windows. Companies have to support all this code into the future, after all...

    1. Re:Performance by Anonymous Coward · · Score: 5, Insightful

      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...

    2. Re:Performance by FooBarWidget · · Score: 5, Informative

      "When will we start to see serious performance improvements?"

      With GNOME 2.0 and 2.6. Nautilus 2.0 got a huge speed boost compared to 1.x. Nautilus 2.6 is spatial and has because even faster. Windows appear instantly.

      "Linux is supposed to get us off the upgrade treadmill, but as far as I can see, GNOME just keeps getting bigger, slower and more complex."

      Not true. GNOME (and KDE!) have only gotten faster and faster. The exceptions are KDE 2.0 (which is slower than 1.0; but 3.0 is faster than 2.0 and 3.2 is even faster than 3.0) and GTK (which has become a little slower but also smoother because of extensive double buffering). On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4. And GTK 2 feels smoother than GTK 1.

      "When gconfd is eating up 20 megs (resident), just for a configuration back-end, it's evident that we're getting sloppy."

      OMG not this again. I will repeat it *again*. Don't trust memory reports! The 20 MB you read includes shared memory! In reality it uses a lot less than 20 MB, somewhere around 6 MB on my system.
      People who think software x is bloated by looking at the system monitor's memory report are just deceiving themselves.

      And sometimes you need to use more resources in order to make things faster. Low memory usage doesn't always equal fast and high memory usage doesn't always equal slow!

    3. Re:Performance by murrayc · · Score: 4, Informative

      Nautilus is much faster in GNOME 2.6. And it was faster in 2.4 than 2.2, and faster in 2.2 than 2.0.

      There are also several specific performance improvements in particular GTK+ widgets, and the GNOME Help system has had an incredible speed up.

      Linux kernel 2.6 also makes a very noticeable difference, with it's pre-emptive schedule that gives priority to things that the user is doing.

    4. Re:Performance by MacJedi · · Score: 4, Informative
      Try Debian. Just do a base install to get a very minimal but bootable system and then apt-get install foo your way to whatever configuration you need.

      As for a low resource using window manager, check out XFCE4. It has the look and feel of Gnome but is far more zippy on old hardware. I run it (and occasionally fluxbox) on a P2 300 laptop with 128 MB RAM.

      --
      2^5
    5. Re:Performance by Ed+Avis · · Score: 4, Insightful
      On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4.

      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
    6. Re:Performance by Malc · · Score: 5, Insightful

      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.

    7. Re:Performance by maxwell+demon · · Score: 3, Interesting

      Some of the features described (the OO behaviour of the file manager, file templates) have been there under OS/2 Warp 3, running in acceptable speed in as little as 8 MB. And that was on a 486DX2/66.

      IMHO, a window manager/desktop environment should always try to eat up as little space as possible. After all, the applications you run are getting more memory hungry as well.

      BTW, nice to know that OS/2 goodies start to show up in GNOME! Now give me "Arbeitsordner" (don't know what the English name is, it's file manager windows which remember the documents opened from it and closing/reopening them when they are themselves closed/opened; sort of session management for single file manager windows), and I'll no longer miss anything from OS/2 Presentation Manager in Linux.

      --
      The Tao of math: The numbers you can count are not the real numbers.
  6. Wow... by unknown_host · · Score: 5, Funny

    "and now it is much easier to manage one's wallpaper collection".
    That does it. I am shifting to GNOME.

  7. Re:Windows Longhorn renders all this obsolete by Etyenne · · Score: 4, Funny
    The release of Windows Longhorn ...

    ...due somewhen in 2006 will render a 2004 software obsolete. Hey Sherlock, here's a cookie for your perspicacity !

    --
    :wq
  8. Re:File selector! by Lord+of+Ironhand · · Score: 3, Informative

    Site doesn't like /. referrals, just click the URL and press Enter on each 403 Forbidden...

  9. Complete Text by Anonymous Coward · · Score: 3, Informative

    Diving Into GNOME 2.5 - A Preview of GNOME 2.6
    Sayamindu Dasgupta
    The boring intro...
    As a part of the Bangla/Bengali GNOME l10n team, I decided to give the GNOME HEAD branch a spin - in order to find out what's new, as well as to get an estimate of how much we would have to translate (I hate that part of the job) to attain supported status. The last time I did this, I also wrote an article about what I saw, but unfortunately, I never learn from my mistakes - so here I go again....
    However, before jumping in into this guided tour, please remember that I have been involved with the GNOME community for the past few months as a helper in the GNOME Summaries, and I may not be able totally impartial towards GNOME. Feel free to consider me biased.

    The Vital Statistics
    Before going into the real stuff, let me give me a brief overview of my system, so that when I mention something as fast or as slow, you would be able to guess how it would crawl in your system.

    Processor: AMD Athlon XP 2600+
    RAM: 512 MB of PC 2700 DDR RAM (with 875 MB swap)
    Motherboard: Nforce 2 based mobo from Leadtek
    Storage: A 40 GB Seagate Barracuda HDD
    Distro: Mandrake 9.2
    Kernel: 2.6.2
    The Installation
    I had gone through (successfully) the GNOME dependency maze before, and to avoid losing my sanity, I decided to use jhbuild (one can also use GARNOME or cvsGNOME - maybe I'll test one of those with GNOME 2.8) .
    Using jhbuild is quite easy - just set some variables in ~/.jhbuildrc, and you are ready to roll. Jhbuild grabs the latest source code from CVS (taking care of the dependencies), compiles them, and installs them in whatever $prefix you want them to be in. OK - there was one major problem - but that was at a later stage, and it got fixed really quickly.

    First Impressions

    Fig 1. The default GNOME 2.6 desktop
    Jhbuild took around 6 hours to get a bare bones GNOME system up and running, and surprisingly, there were very few errors, and I had to manually intervene only thrice.

    I logged in as root the first time (yaya - I know security risk and other stuff..), to be greeted by a clean and polished looking GNOME desktop (Fig. 1) . (Note that I am running the Freedesktop.org Xserver here - so don't expect a stock GNOME 2.6 install to have panel shadows).

    Seeing an icon named "Computer" right on the desktop - my first reaction was to click on it, expecting Nautilus to pop up with my "/" directory or something like that.

    Nautilus goes spatial
    However, as soon as I clicked on that icon - my reaction was "Yikes!! What have they done to Nautilus ??". Gone was the old and familiar explorer like interface. In it's place was a really minimalistic window, with no toolbar, just a plain menubar. I was quite confused - I even clicked on "Help" -> "About" to verify that the "thing" was indeed Nautilus. After some head scratching I remembered a post at FootNotes, in which the Nautilus developers announced something about going "Spatial". People had been pretty much excited about this - though I personally had no idea about what this stuff was all about. Now I thought I understood.

    Fig 2. Spatial Nautilus - Showing "Computer"
    All my disks had been correctly identified by Nautilus, and was showing up in the "Computer" window (Fig. 2). But that was not very important at that point - all my attention was riveted on the new UI. After some Googling and RTFM sessions, I figured out that Nautilus was following a "Object Oriented" metaphor, instead of the normally used "Navigational" metaphor. The most user visible aspect of the OO metaphor is that there is a always a direct, one-to-one relationship between folders and windows, and the window for each folder remembers where you placed it the last time - i.e, the next time it will pop up in the same position. This new interface is partially inspired by the interface described in http://arstechnica.com/paedia/f/finder/finder-1.ht ml.

    Fig 3. Viewing a deep folder with spatial Na

  10. gpdf by starseeker · · Score: 4, Interesting

    Hmm. I really hope they do have thumbnail and bookmark support, and continue to add features. Xpdf is a nice renderer, but the interface IMHO is not exactly a nice one. If gpdf can become the full equal of Acrobat Reader I'll be one very happy camper.

    --
    "I object to doing things that computers can do." -- Olin Shivers, lispers.org
  11. File selectors? Why? by Anonymous Coward · · Score: 5, Interesting

    They go to all the trouble of creating a decent filer, Nautilus, and then ignore it for opening and saving documents by sticking with stupid file selectors. Again. Do any GUI developers bother challenging tired, illogical concepts? (Check out ROX for true drag and drop opening and saving: here)

    1. Re:File selectors? Why? by DreadSpoon · · Score: 3, Funny

      Getting rid of file selectors all together is *waaay* too big of a change for a minor version increment. Maybe in GNOME 3.0, sure. But not just jumping from 2.4 to 2.6. That'd be like dropping a new VM in a stable kernel series or something. ;-)

    2. Re:File selectors? Why? by Stinking+Pig · · Score: 3, Insightful

      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
  12. Gnome and KDE interoperability by pubjames · · Score: 4, Insightful


    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?

    1. Re:Gnome and KDE interoperability by dominator · · Score: 5, Informative

      There's quite a bit of inter-operability work going on at freedesktop.org. There's a lot of shared specifications and software there. Plus there are software libraries that both DEs use that aren't listed on FDO, like libxml2.

      The KDE folks have also worked on some Qt-GTK toolkit inter-operability stuff. See also:

      GTK-Qt
      Ditto
      Glib/Qt main loop integration

      amongst others.

  13. Re:Yuk by Xpilot · · Score: 3, Informative

    I guess I'll never be a Gnome user. What is the fascination with muddy colours?

    GNOME is quite themable; if you don't like the muddy colours, use another theme.

    --
    "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
  14. Re:Its called KDE 3.2. by sniggly · · Score: 4, Insightful
    It's unwise to say that kde is better than gnome on slashdot. It isn't true either. A lot of people will appreciate the way gnome works, nautilus reminds me of the finder in mac os pre osx - some people love it, some hate it, most don't care.

    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.
  15. Nice Job by ickoonite · · Score: 4, Interesting

    GNOME vs. KDE will perhaps be one of the holy wars of this millennium, and this is certainly another kick in the teeth for the ever-so-slightly clunky KDE (in my opinion). As said in the article, the developers have done some superb work and, well, put it this way, it is almost making me want to lose Mac OS X on one of my iBooks. Do not underestimate the pulling power of eye candy and the HIG!

    Liberal inspiration has, of course, been taken from the Apple way of doing things - the spatial navigation is, as noted in the Ars Technica article, based on the pre-OS X MacOS Finder. And that's no bad thing, certainly if FOSS wants to move towards real usability on the desktop.
    The file dialogue boxes are also notably similar to Mac OS X's way of doing things, although the puzzling (at least to me) scrollbars that the Mac uses to browse up and down a directory tree are here replaced with arguably simpler tabs. Very nice touch.

    Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that, but hell, if I were a Windows user, I'd be sitting here asking myself why the fuck I am waiting till 2006 for Longhorn when I can have this now...
    Zealots were quick to criticise the most prominent competition - Mac OS X 10.3 - in terms of eye candy on the desktop when it came to making comparisons with their darling Longorn (which is, rather pointedly, not available for purchase yet). Now that UNIX is offering two superb alternatives, one of them properly FOSS (and, more importantly, runnable on x86), Windows' days should surely be numbered...?

    iqu :)

    1. Re:Nice Job by ajagci · · Score: 3, Insightful

      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.

  16. New File Selector with type ahead by tjwhaynes · · Score: 4, Informative

    It is certainly not just geeks who will want or need to type in file names. Skilled typists will not want to move their hands from the home row to open a file. Making them use the mouse to open a file is a bad idea.

    So ... type in the name of the filename, anywhere in the window. This file selector has type-ahead support so it will search through the files looking for the next file that matches the string you have typed so far. If you've been using this feature extensively in Mozilla, it'll be second nature already.

    Cheers,
    Toby Haynes

    --
    Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
  17. Mirror by unmadindu · · Score: 4, Informative

    OK - Here's a mirror that should work properly - sorry for the initial goof up http://www.clai.net/sayamindu/GNOME-2.6/GNOME_2_6. html

  18. Nicely written article!! by mritunjai · · Score: 4, Insightful

    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
  19. you guys are so mean by tuggy · · Score: 5, Funny

    triple slashdotting??
    are you trying to break a new record or what? ^_^

  20. twist on an old alaskan joke. by juggaleaux · · Score: 4, Funny

    "My Uncle switched Linux Desktops today." "Gnome?" "Know him? He's my uncle!"

  21. About spatial navigation by mst76 · · Score: 5, Interesting

    Some people have the misconception that "spatial navigation" is about having one window per folder, but that's not really the point. In explorer-like navigation, every window is a partial view of the filesystem. Every window can be used to navigate the fs with browser-like controls (forward, backwards, folder up, folder down). Two windows are just two views of the fs, they can point to the same folder.

    The defining characteristic of spatial navigation is that a folder window IS the folder. That's why there cannot be two windows on screen that show the same folder, and why there are no navigation controls. The fact that folders open in the same place as when you left them is just a result of the fact that the position is an attribute of the folder itself, not of a windows which is a viewport of a folder. It's a subtle difference that people who have worked with explorer-like browsers for too long may have some difficulty adapting to.

    Personally, I feel more comfortable with an explorer-like fs browser, maybe just because I'm used to it. It seems easier to manage large trees this way. But I can easily see why new computer users would be less confused with the spatial model. It's hard for some people to understand (and remember!) that a dozen of shortcuts to "My Documents" in different places all point to the same folder "underneath".

    1. Re:About spatial navigation by hattig · · Score: 4, Insightful

      Maybe they never used Windows 95 either!

      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. ... and of course, the option to disable it completely if you want an explorer like UI.

  22. I disagree by bsd4me · · Score: 3, Interesting

    ``Not true. GNOME (and KDE!) have only gotten faster and faster. The exceptions are KDE 2.0 (which is slower than 1.0; but 3.0 is faster than 2.0 and 3.2 is even faster than 3.0) and GTK (which has become a little slower but also smoother because of extensive double buffering).''

    I can't comment on KDE, but when I upgraded from Gnome 2.2 to 2.4, I noticed significant performance hits. The desktop took longer to load, and in general, were noticably slower.

    ``On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4. And GTK 2 feels smoother than GTK 1.''

    Well, you have a nice system. My primary FreeBSD box has a 500 MHz CPU with 128M RAM. Yes, it sucks, but I was fairly disappointed when I upgraded to Gnome 2.4

    --

    (S(SKK)(SKK))(S(SKK)(SKK))

  23. Hyperbole is fun by Imperator · · Score: 4, Funny
    I firmly believe the Amiga User Interface Style Guide should be required reading before anyone is allowed to even install a compiler with the ability to create GUIs. [emphasis added]

    Isn't this just a tad bit harsh? Imagine someone opening his TiVo box:

    TiVo Quick Start Installation Instructions

    Step 1: Your TiVo runs the Linux operating system, and if you install development tools you can use it to create graphical user interfaces or GUIs. Therefore, before you finish setting up your new TiVo, please read the Amiga User Interface Style Guide.

    Step 2: Unpack the TiVo and the AC adapter (figure 1).

    [...]

    Step 55: Quick quiz: what do the Amiga User Interface Style Guide say about resizing windows that have widgets in a grid layout? Have the answer ready before you call Technical Support, or you will be put on hold while you reread the Amiga User Interface Style Guide.

    [...]

    Step 128: Profit!
    --

    Gates' Law: Every 18 months, the speed of software halves.
  24. Watch out for line breaks in article by palad1 · · Score: 4, Funny

    Firefox was set to 800x300 , here's what I could read:

    As a part of the Bangla/Bengali GNOME l10n team, I decided to give the GNOME HEAD

    those bengali guys sure are strange...

  25. Spring loaded folders by unoengborg · · Score: 5, Insightful

    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
  26. Gnome for the Developer by 0xB00F · · Score: 3, Insightful


    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)