Slashdot Mirror

← Back to Stories (view on slashdot.org)

Gnome 2.0 RC1

Posted by michael on from the fever-when-you-kiss-me-fever-when-you-hold-me-tight dept.

lurgyman writes "The GNOME Desktop 2.0 release candidate 1 has been released! It looks like it's finally on schedule for its projected June 21 release." The release notes have some good information.

8 of 287 comments (clear)

  1. Please test it! by Anonymous Coward · · Score: 5, Insightful

    Gnome will not be a good product without testing.
    Please don't wait for the final product to come out.
    It is you obligation (ok, maybe not) as a user of "software libre" to contribute something. If you cannot program, you can at least test the stuff on your hardware.

    You would be sureprised at how few tester there are. I have found that if I submit a valid bug, it is fixed quickly. YOUR INPUT COUNTS!

  2. Re:Can it compete with KDE? by IamTheRealMike · · Score: 5, Interesting
    Asking .... will KDE vanquish GNOME, or "which will win the desktop environment wars" is the wrong question. It's like asking "Which will win, Ford or Vauxhall?". I wouldn't be surprised if a decade from now, KDE and GNOME are still around, still with plenty of happy users. I think KDE will be loved more by those who came from Windows and are most happy with a Windows style desktop environment (which is in fact quite a good design, MS bashing aside).

    I think GNOME should start to differentiate itself in some way, and I expect we'll start seeing them diverge somewhat as GNOME realise they can't out-KDE KDE, and instead try and do their own thing.

  3. Differences appear minor by Outland+Traveller · · Score: 5, Interesting

    I'm not sure what you mean when you ask "Can Gnome compete with KDE"?

    I've installed both KDE-based systems and Gnome-Based systems and shown them to Linux newbies- everyone from relatives to co-workers (caveat: I work in an engineering dept.)

    After spending a few hours playing around with each one, my personal experience is that Gnome is their preferred choice, apparently because the icons and screen widgets look better, the interface appears simpler, and most of the engineers like the graphical virtual desktop manager on the gnome panel as opposed to the KDE version.

    Granted, I use Gnome a lot and there are some deficiencies.. Nautilus is very slow. Sawfish has focus problems. The panel can behave in unexpected ways. The library dependencies for applications like Evolution are scary, but it generally works well and many people use Gnome as their full time desktop.

    It looks to me like KDE may be slightly more stable, and may be easier to program for. Still, the differences between gnome and KDE from a user's point of view do not seem so great that you can call one "high level" and the other "mid level". They both look high level to me.

    So, does someone want to try to explain the qualitative user-experience differences between KDE and Gnome, or is it as I suspect very minor?

    1. Re:Differences appear minor by pthisis · · Score: 5, Insightful

      From a development standpoint, GNOME is ugly as sin...I would much rather use Qt than everything under the GNOME sun for development, and C++ rather than C

      Not meant to be flamebait, but there is a large set of developers out there who greatly prefer C to C++; this is especially true on a Unix-like platform, given the close history of the two. Saying that "from a development standpoint, GNOME is ugly as sin" is _definitely_ an opinion. C++ and Qt are out there if you want to use them. Personally I think that the language difference has had a huge impact on the high-level goals and progress of the two projects, and that sort of diversity is a good thing.

      GNOME and Ximian could do many good things for developers and system maintainers by consolidating a lot of those little libs into big lib packages.

      Likewise here. On many occasions I've used just one small library from GNOME in a completely non-GNOME (often not graphical at all) project, and I love that it's easy to pull out small pieces (glib, libunicode, parts of the gcal ical implementation) and use them.

      Sumner

      --
      rage, rage against the dying of the light
    2. Re:Differences appear minor by akeru · · Score: 5, Interesting

      Wow, do I have to disagree about the development standpoint here. Sure the dependencies can be a pain, but that's where the beauty and flexibility of autoconf/automake and pkg-config make life easy again. The additional modularity granted by separating different functions into their own libraries far outweighs the additional overhead of a lot of dependencies. Having watched GNOME and KDE development closely since before the 1.0 KDE and 0.3.0 very unstable "technology preview" GNOME I can say the essential difference between the two projects is that KDE is focused on "doing it now" and GNOME cares more about "doing it right" than they do about timelines. And it shows. KDE has caused me nothing but problems, and, from a systems administration standpoint, is a real PITA. GNOME, on the other hand, has continually tried to integrate and play nice with existing standards and conventions, which means that, among other things, configuration files are in /etc and everything else is where it is "supposed" to be.

      And while you may prefer C++ to C (and for good reason too), the decision to use plain old C for GTK2 was, IMHO, a good one. In so doing you enable the maximum flexibility and, when done right (as GTK2 is, for the most part) makes writing language bindings (almost) trivial. I can't say for QT, but GTK/Glib 2 allow for complete run-time introspection of types, parameters, etc. in a very clean manner. By doing the base object-system in C with a clean API, it allows binding authors and programmers in general, a way to write to the underlying library in a way that fits in naturally with the language they are using to write it. Rather than using moc hacks or other ugliness, you get clean, standard, C (which may be, IYHO, ugly, but it is standard C, which most compilers support at this point in history -- excluding C99 -- which cannot be said for either C++ or the C++ derivitive used by Qt/KDE). Say what you will about C the language, but using it to implement the object system was a good idea, the additional complexity involved in coding for it is minimal and a the code, in large part, for creating a GObject subclass is largely boilerplate anyway which can be scripted or wrapped by something like 'gob'
      Everytime I've looked at Qt/KDE development I've been struck with just how . . . unwieldy and inflexsible it is.

      The differences in attitude ("let's do it now and invent some new, quasi-documented, way of doing it" vs. "is there a standard way to do this and how should we do it RIGHT") are behind most of the differences in toolkit and, more importantly, time line. GTK2 took a long time to get out, because a lot of thought and planning when into it. Whether this was actually the case with KDE2/3 as well or not, I can't tell, but it certainly doesn't look like or feel like it.

      --Shahms

      --

      Let's hope that there's intelligent life somewhere out in space 'Cause there's bugger-all down here on Earth.

  4. Re:screenshots by Tack · · Score: 5, Informative
    If you're looking for GNOME 2 screenshots that don't look like barf (and I agree, the ones posted here look hideous), then try these images from Jimmac's site:

    Jason.

  5. Re:UI Features? by IamTheRealMike · · Score: 5, Informative
    While I realize this release wasnt supposed to 'look' much different, they still could have taken advantage of new eyecandy availible to x and gtk2. Even kde supports tranparent menus. Besides anti-aliased fonts and alpha blending in widgets, nothing else looks much different.

    Well like you said, this release is about under the hood changes, much like the difference between Windows 95 and 98 - a lot of good changes, but not really in the visuals department.

    2.) cool little features like drop shadows on the menus and windows, alpha blending and animations on mouse over widgets or icons, faded menus, transparency, etc....

    Drop shadows on menus will have to wait for real transparency, which doesn't rely on taking a screen grab of the underside (which is how current X transparency is implemented, it means once blended it'll get out of date). This doesn't exist in X yet, but will once Keith Packard has finished his transparency server. I wish I knew when this would be.

    Animations on mouse over widgets and icons is implemented in KDE3, so I dunno why GNOME doesn't have it either - guess it's just priorities. For faded menus, I guess you mean transparent menus, see above. In fact, that list basically comes down to "transparency". It's coming. Hold tight.

    Meanwhile, here is a shot of GNOME that actually looks good. And look - the terminal is transparent. Happy now?

  6. Re:screenshots by epukinsk · · Score: 5, Informative
    The following was posted on desktop-devel-list@gnome.org:
    From: Rui Miguel Silva Seabra
    To: GNOME Desktop Hackers
    Subject: Re: GNOME 2.0.0 Desktop Release Notes Contributions
    Date: 14 Jun 2002 12:37:21 +0100

    A sawfish known issue that people might pointout: viewports are
    ''gone''.
    Suggest adding the following to ~/.sawfishrc
    ;; Get viewports back
    (setq customize-command-classes '(default viewport))

    ;; (setq viewport-dimensions '(NUMBER_OF_COLS . NUMBER_OF_ROWS))
    (setq viewport-dimensions '(6 . 1)) ;; example
    Not only do GNOME developers know this is an issue, there are GNOME developers who want the functionality viewports offer to be a part of GNOME. I wouldn't be surprised to see there be a GConf key that enables viewports in 2.0.1, BUT...

    GNOME 2 developers can't listen to GNOME 2 users unless the users speak directly to them. File a bug in bugzilla.gnome.org. That's the best way to put this request on the developers' plate. And don't just say "RE-ENABLE VIEWPORTS," explain exactly what it is about viewports that you miss... is it that windows can straddle viewports? Is it navigation?

    It's my understanding (after lurking on the gnome lists for a while) that the intention is not to leave viewport users in the dust, but to try to allow viewport users to use workspaces in the same way they used to used viewports. I.e. put a checkbox somewhere that says "allow windows to straddle workspaces" etc.

    But this functionality won't be implemented unless the GNOME developers know people want it. So file a bug. File several bugs, one for each bit of functionality you miss that viewports had.

    -Erik