Slashdot Mirror


Gnome 2.0 Alpha 1 Released

Dave H writes "The first pre-release of the GNOME 2 platform is now available! Find it at you can grab it from FTP.gnome.org It is of course a technology preview; note that it can't be installed alongside GNOME 1.x." There's some more information information posted on LinuxToday.

19 of 315 comments (clear)

  1. New ORB. by sarkeizen · · Score: 5, Insightful

    Anyone know if there's intent to implement some kind of simplified IPC? Similar to DCOP? I'm a CORBA developer and even I think that CORBA presents a fair ammount of work to perform some relatively simple things.

    BTW: Great Job on the multilingual!, as someone who likes to have his desktop in traditional chinese this is a big deal for me.

  2. GNOME Stability by Arandir · · Score: 2, Insightful

    I just ran across a GNOME problem not just ten minutes ago. I want to build Dia because argouml is insufficient and Rose sucks.

    Dia is under GNOME/stable. gdk-pixbuf is under GNOME/unstable. Anyone see the problem here? Who in their right mind can call Dia "stable" when it relies on an "unstable" library?

    --
    A Government Is a Body of People, Usually Notably Ungoverned
    1. Re:GNOME Stability by NonSequor · · Score: 3, Insightful

      I'm pretty sure that gdk-pixbuf should be moved to stable. A lot of programs have been using it for quite some time.

      --
      My only political goal is to see to it that no political party achieves its goals.
    2. Re:GNOME Stability by efgbr · · Score: 2, Insightful

      Since gdk-pixbuf is a part of the GNOME 1.4 platform you can consider it stable.

      You shouldn't really be looking in the stable/ unstable/ dirs in GNOME's ftp.

  3. Re:GNOME, a thought by adadun · · Score: 2, Insightful

    IMHO, what's needed is a GUI that'll do for X what RISC architectures did for processors. Produce a MUCH simpler underlying architecture, using layers to provide more and more complex functionality.

    But isn't this exactly what X is? The X server is just a very dumb program that only knows how to draw lines, boxes, circles, and fonts. Everything else (i.e., the complexity) is layered on top of this through toolkits and window managers.

    A GNOME program uses the simple GTK toolkit to provide the GUI. GTK uses Xlib which uses X. The complexity is layered.

    Furthermore, neither the application nor the toolkit needs to worry about how the window is managed; this is taken care of by the window manager program. The window manager interacts with the user and moves, resizes, and iconifies windows. Layered complexity once again.

  4. Re:Love the warning by Unknown+Bovine+Group · · Score: 3, Insightful

    Which raises the question: Why is slashdot posting ALPHA releases? all this will lead to is a couple months from now people will comment "Yeah I tried Gnome 3 and it sucked."

    --
    m00.
  5. Re:A bit of thought on the evolution of the GNOME. by Jamie+Zawinski · · Score: 5, Insightful

    Eazel and Ximian are the most productive GNOME companies,

    By "most productive", did you mean "only"?

    Is it because the GNOMErs only know how to code in C, and not in C++. There are several good books and web sites on C++ programming, you know.

    I promise you that those of us who refuse to use C++ do not do so out of ignorance. Quite the opposite, in fact: I don't use C++ precisely because I know more about it than you.

  6. Bloat? by JahToasted · · Score: 1, Insightful
    I hope they remove the bloat that made 1.4 unusable. I think Nautilus was the biggest problem but not the only offender. From what I can see Bonobo hasn't been used to it's potential yet, I'll have to check out 2.0 from cvs to see what's happening with gnome now (I've been using KDE lately). Although KDE is winning the desktop environment wars now, don't count out gnome yet. As I see it these are what the priorities need to be for gnome to make me want to use it over KDE:
    • Nautilus shouldn't suck - I don't mean to insult those developing Nautilus, but for a file manager you need something fast, not pretty. If it can be both then fine, but right now it's just eye candy. I prefer a GUI for managing my files but so far I have not seen anything that is as nice as Windows Explorer (95 version or 98 with all the shit turned off). Why is this so hard?
    • Better Integration - Bonobo needs to be rock solid and needs to be used more often. This is especially true for Nautilus but also applies to many other apps. Nautilus should just give up trying to be a web browser and just load galeon as a component if it wants to view a web page.
    • More Organisation - The gnome project is very disorganised. If I want to develop a C Programme, do I use gIDE or Anjuta? Why is there so much duplication? While gIDE and Anjuta are working on two IDEs, KDE has one KDevelop completed.
    • Work with KDE instead of against it - Why all the hate between these 2 groups? They both want a free DE for unix, so why do they dislike each other so much? There needs to be more cooperation, or neither will be viable as a desktop for the average user, while microsoft will continue to get them hooked on their projects.
    • Make it fast again - I prefered 1.2 over KDE because it was twice as fast (or at least seemed so) after 1.4 I switched back to KDE because I got tired of waiting about a minute to open a text file.

    I don't mean to bitch, I really like gnome and look forward to switching back from KDE. The terminal is nicer, GIMP is cool, Galeon is the best web browser i've ever used, and Open Office looks promising (I know I can use these with KDE but I don't like having both GTK and QT loaded, I have better uses for my RAM). But right now KDE works, so that's what I'll use. But I'll give 2.0 alpha a shot... and when gnome works again, It'll be my primary desktop.

    Good luck to those working on gnome... and expect some bug reports from me soon!

    1. Re:Bloat? by reaper20 · · Score: 3, Insightful

      Nautilus shouldn't suck

      The latest Nautilus builds I have tried with the merges from the Red Hat guys have been AWESOME. Still needs some work, but it has come a long way towards becoming everyday usable.

      Work with KDE instead of against it - Why all the hate between these 2 groups?

      Why do people say this? I don't get it. I don't see Gnome developers trolling KDE, I don't see KDE developers trolling GNOME. What do I see? Users trolling for their preferred choice. Its not like KDE guys are making KDE apps not work in GNOME or vise versa.

      Everyone talks about this huge war and how only one can survive ... give me a break people, the only ones damaging BOTH desktops are the people that are supposed to be pushing for open standards and competion! Don't believe me, then read the crap in this thread.

    2. Re:Bloat? by hyperstation · · Score: 2, Insightful

      I'd agree that KDE and Gnome should be collaborating, but I sincerely hope that the GTK widget set wins through at the end of the day.

      gtk is all blocky and and ugly looking, while qt is streamlined and smooth. if you're ever gonna convert all the windrones over to linux, it's gotta look pretty...

      just my $0.02

  7. Re:Look is apparently the same by GauteL · · Score: 3, Insightful

    Well... at least you have anti-aliased fonts and bidirectional font-support.

  8. Re:Slower progress compared to KDE by PastaAnta · · Score: 3, Insightful

    Well, there is still one important issue left with KDE. The Qt library is released under a GPL license as opposed to the LGPL license for GTK+. This prohibits developers of commercial (non-GPL) applications from using the Qt library and therefore developing for KDE without paying royalties to TrollTech.

    This might not be an issue for the OpenSource community, but it sure is an issue for all the companies that have to make a living. This is why companies like SUN, HP etc. has chosen GNOME as their next desktop.

    Just my two bits "01" - It's a fact, like it or not.

  9. Re:Another thought... by David+Greene · · Score: 5, Insightful
    Insightful? I've never questioned the drug-using habits of moderators before, but there's a first time for everything. :)
    "But hardware != software", I hear some cry. Well, sorry to break it to you, but software is simply a simulation of hardware. There is nothing that you can do in software that you can't do in hardware. Faster.

    While it's true that hardware and software are essentially the same thing (a favorite rant of mine, BTW), it's not true that hardware is necessarily "better" than software, even in the speed department.

    Picture this - a graphics card that has a pure hardware implementation of XFree86 4.1, Gnome 2, and (just for the hell of it) KDE 2.2 as well. Nothing on the computer, the graphics is done entirely in silicon.

    If we look at this proposal from a perspective of practicality, it clearly falls down. Hardware is incredibly difficult to debug and change. That is the beauty of software. The fact that complex computer architectures are implemented in terms of software (microcode) only points to this flexibility.

    To address your speed claims, I point you to HP's Dynamo project. Dynamo is a dynamic translator for PA-RISC binaries. It is a software system that translates PA-RISC instructions to PA-RISC instructions at run-time. That doesn't seem to make much sense until you realize that the translation includes optimizations that can only be done at run-time. Binaries actually run faster under Dynamo than in native execution mode. By putting in a layer of software, HP was able to increase system speed.

    One cannot do this in hardware because metal and silicon is fixed and FPGA's are too slow. Yes, people are researching reconfigurabler hardware, but that is for very specialized applications like DSP's, applications that are already used to boost graphics performance today.

    A final observation: hardware gets much of its speed from parallelism. A ripple-carry adder runs much more slowly than a carry-lookahead adder. While certainly running at the speed of light (yeah, yeah, give or take) helps, parallelism (pipelining, O-O-O execution) is what got us the machine speeds we see today.

    Parallelism is really, really hard to extract at the instruction level. Theoretically, it's there, but damned if I know how to get at it. Certainly lots of graphics routines have loads of parallelism. But guess what? We already have hardware to exploit it!

    This would free up much of the computer's RAM, unload much of the heavier cycle devourers, and produce one of the fastest GUIs on the planet.

    Modern GUI's really don't need to be much faster than they are now. We all like high framerates in our pretty games, but those are very specific applications. In fact, good hardware solutions already exist for them. I don't see RAM consumption as a problem, considering that X runs just fine on the iPAQ with room to spare. I have no idea what software you are running, but the CPU usage of graphics code is not even close to the largest consumer of cycles on my machine.

    We already have good graphics hardware. Moving the X/GNOME/KDE control into hardware would gain almost nothing.

    --

  10. examples of hate between developers? by Anonymous Coward · · Score: 1, Insightful

    in interviews, on web sites, etc., it seems like KDE and gnome developers constantly point out how they each admire the other's project, they get together, drink beer when geography allows, etc.

    where do you see this so-called hate?

    Are you sure it's between developers, or just people who latch onto one or the other and find defnding it / attacking the "other" (as if there aren't plenty of other ways to run a *nix box besides with one of those) necessary to their identity?

  11. Re:A bit of thought on the evolution of the GNOME. by David+Greene · · Score: 2, Insightful
    Gnome is GPL. QT *is not*. (consider commercial implications as well).

    This is clearly false. Qt-free is very much GPL'd. I don't know what commercial implications you are talking about. There is absolutely nothing in the Qt license to prevent it from being ported to Windows. The only commercial implication I can think of is that the application compiled against it must be licensed under the GPL. But that doesn't seem to be a concern for you.

    --

  12. Re:Have they dropped Nautalus? by highcaffeine · · Score: 3, Insightful

    Maybe you should try reading the fine manual. You can *very* easily disable this behavior.

    First:
    Preferences --> Advanced

    Then:
    Preferences --> Windows & Desktop
    and uncheck "Use Nautilus to draw the desktop"

    Now, that wasn't so hard, was it? Don't knock a great piece of software (even though I rarely use filemanagers) just because you didn't read the docs.

  13. Re:Yuck! by David+Greene · · Score: 2, Insightful
    What it would mean is that your engineers sit down and Get It Right.

    Given the difficulties we have getting software to work correctly, do you honestly think hardware would be easier? Or even just as easy? Today's hardware only works because the specs are orders of magnitude simpler than even a mildly complex software system.

    Implementing in hardware shouldn't be too bad. Since software equates to hardware, you should be able to simply treat the software as a "macro" of the hardware definition. This would give you a version 0.0.0, which your engineers can then run through VLSI emulators to turn into a 1.0.0 product.

    So you want to use an HDL for this along with a synthesis tool? For synthesis to work, one has to either design a fairly simple piece of hardware or write relatively low-level HDL. In the worst case the designer will essentially write out the netlist. Not to mention the inefficiencies introduced by synthesis. Full-custom design is usually much more efficient, but also much harder to do.

    --

  14. Re:GNOME, a thought by Fnord · · Score: 2, Insightful

    >Think about that for a second. I have a *Lisp* >system that takes less disk space than 12M. That is >a huge, huge, amount of code. Sure, it is less than >the drivers, but considering that X does very >little, it is positively *enormous*.

    Ok, but first of all this is stuff used by X clients, not the X server. These are things like libX11 and libXt, essential apis for X clients. Then you have the fact that alot of these apis have been pretty much depreciated for modern X programs. Gnome doesn't use Xintrinsics or the athena widgets. If you're running mostly gnome programs libXt and libXaw almost never loaded. Then there are things sitting around in there like libPEX. Don't even try to say you've used a PEX based program in the past 4 years. All in all, you're probably only going to use libX11, libICE, libSM, libXm and if you're using pretty antialiased fonts libXft and libXrender. Thats about four megs.

  15. #define PROGRESS productive_end_user by Ukab+the+Great · · Score: 4, Insightful
    Real progress in an end-user, GUI-based, for-the-masses desktop computing environment is not about:
    • How many cool toys you have
    • How slick the thing looks
    • What language you use (those OO C is a pain in the ass to code in)
    • How many graphics buzzwords like AA or DRI you support
    • How little memory you use
    • How technically elegant you make it
    Real progress can be defined as whether the secretary, farmer, mechanic, CEO, or whoever else who isn't a card-carrying geek was able to be more productive and feel better about using than computer than they were with the last version. Anyone,GNOME, KDE, or otherwise, who does not understand this does not understand the desktop. If you do not understand the desktop, you will at best produce a successful user-hostile abomination such as Microsoft did and survive entirely by the politics of corporate IT or at worst get your butt slammed across the entire computing industry.