Slashdot Mirror

← Back to Domains

Domain: gnome.org

Stories and comments across the archive that link to gnome.org.

Comments · 3,430

  1. Screenshots by frantzdb · · Score: 5, Informative · on GNOME 2.0 Released

    For the lazy, here are the Screenshots.

    Great work to everyone who helped with this. Gnome2 is amazing.

    --Ben

  2. Get To Those Mirrors! by Anonymous Coward · · Score: 5, Informative · on GNOME 2.0 Released

    GNOME FTP Sites This site is mirrored at:

    Last updated Wed Jun 26 03:18:01 2002 from our mirror database (webmaster@gnome.org).

  3. Get To Those Mirrors! by Anonymous Coward · · Score: 5, Informative · on GNOME 2.0 Released

    GNOME FTP Sites This site is mirrored at:

    Last updated Wed Jun 26 03:18:01 2002 from our mirror database (webmaster@gnome.org).

  4. Get To Those Mirrors! by Anonymous Coward · · Score: 5, Informative · on GNOME 2.0 Released

    GNOME FTP Sites This site is mirrored at:

    Last updated Wed Jun 26 03:18:01 2002 from our mirror database (webmaster@gnome.org).

  5. Re:Where's the ChangeLog ? by JamesHenstridge · · Score: 2, Informative · on Gnome 2.0 RC2 Asks For Abuse

    You can use bugzilla to find this information.

    As an example, here is a list of all bugs with the GNOME2 keyword that are in the RESOLVED, VERIFIED or CLOSED state that changed state between the RC1 and RC2 releases. It is not complete, and probably isn't fully accurate (some changes may have been fixed but no new tarball is available yet), but it gives you an idea of what has changed.

  6. Re:Where's the ChangeLog ? by JamesHenstridge · · Score: 2, Informative · on Gnome 2.0 RC2 Asks For Abuse

    You can use bugzilla to find this information.

    As an example, here is a list of all bugs with the GNOME2 keyword that are in the RESOLVED, VERIFIED or CLOSED state that changed state between the RC1 and RC2 releases. It is not complete, and probably isn't fully accurate (some changes may have been fixed but no new tarball is available yet), but it gives you an idea of what has changed.

  7. Re:Mirrors by Anonymous Coward · · Score: -1, Troll · on Gnome 2.0 RC2 Asks For Abuse

    Karma whore alert! Please mod down, and mod this anonymous post up!

    archive.progeny.com (US or Canada)
    ftp.twoguys.org (US or Canada)
    ftp3.sourceforge.net (US or Canada)
    ftp.rpmfind.net (US or Canada)
    ftp.sourceforge.net (US or Canada)
    ftp.cse.buffalo.edu (US or Canada)
    ftp.yggdrasil.com (US or Canada)
    planetmirror.com (Australia)
    ftp.sunet.se (Europe)
    ftp.dataplus.se (Europe)
    ftp.easynet.nl (Europe)
    ftp.unina.it (Europe)
    ftp.belnet.be (Europe)
    ftp.codefactory.se (Europe)
    ftp.tr.gnome.org (Europe)
    fr.rpmfind.net (Europe)
    ftp.acc.umu.se (Europe)
    ftp.no.gnome.org (Europe)
    ftp.dit.upm.es (Europe)
    fr2.rpmfind.net (Europe)
    linux.cem.itesm.mx (South America)

  8. Re:Does anyone know... by Ami+Ganguli · · Score: 5, Informative · on Gnome 2.0 RC2 Asks For Abuse

    I don't have any inside information, but if you look here you can see that they've added an unscheduled release candidate and they had planned two weeks between the last release candidate and going gold.

    Assuming we don't get another release candidate (which I think is a good bet - I'm running the nightlies and they feel solid) that places 2.0 around July 7.

  9. Garnome by Spock+the+Vulcan · · Score: 5, Informative · on Gnome 2.0 RC2 Asks For Abuse

    As always, if you want to give the latest Gnome a whirl without messing up your existing system, try Garnome
    It takes a while to build (about an hour on my 1.0 GHz PIII), but it doesn't touch your existing install - everything goes into ~/garnome.

  10. Mirrors by neo8750 · · Score: 4, Informative · on Gnome 2.0 RC2 Asks For Abuse

    archive.progeny.com (US or Canada)
    ftp.twoguys.org (US or Canada)
    ftp3.sourceforge.net (US or Canada)
    ftp.rpmfind.net (US or Canada)
    ftp.sourceforge.net (US or Canada)
    ftp.cse.buffalo.edu (US or Canada)
    ftp.yggdrasil.com (US or Canada)
    planetmirror.com (Australia)
    ftp.sunet.se (Europe)
    ftp.dataplus.se (Europe)
    ftp.easynet.nl (Europe)
    ftp.unina.it (Europe)
    ftp.belnet.be (Europe)
    ftp.codefactory.se (Europe)
    ftp.tr.gnome.org (Europe)
    fr.rpmfind.net (Europe)
    ftp.acc.umu.se (Europe)
    ftp.no.gnome.org (Europe)
    ftp.dit.upm.es (Europe)
    fr2.rpmfind.net (Europe)
    linux.cem.itesm.mx (South America)

  11. Mirrors by neo8750 · · Score: 4, Informative · on Gnome 2.0 RC2 Asks For Abuse

    archive.progeny.com (US or Canada)
    ftp.twoguys.org (US or Canada)
    ftp3.sourceforge.net (US or Canada)
    ftp.rpmfind.net (US or Canada)
    ftp.sourceforge.net (US or Canada)
    ftp.cse.buffalo.edu (US or Canada)
    ftp.yggdrasil.com (US or Canada)
    planetmirror.com (Australia)
    ftp.sunet.se (Europe)
    ftp.dataplus.se (Europe)
    ftp.easynet.nl (Europe)
    ftp.unina.it (Europe)
    ftp.belnet.be (Europe)
    ftp.codefactory.se (Europe)
    ftp.tr.gnome.org (Europe)
    fr.rpmfind.net (Europe)
    ftp.acc.umu.se (Europe)
    ftp.no.gnome.org (Europe)
    ftp.dit.upm.es (Europe)
    fr2.rpmfind.net (Europe)
    linux.cem.itesm.mx (South America)

  12. GTK port of Openoffice... by Anonymous Coward · · Score: -1, Interesting · on New York Times Plugs OpenOffice Suite

    The nice thing is that Michael Meeks talked about porting OpenOffice to GTK at FOSDEM , also he has mentioned the same thing on one of the GNOME mailing lists (can't be bothered to look this up).

    Miguel de Icaza too has said that time is better spent on improving OpenOffice rather than working on say Gnumeric (which he wrote part of too).

    So, nothing concrete but who knows, maybe Michael wil work on integrating OpenOffice with GNOME some day. Another possibility is that Sun will do the integration after they switch to GNOME (perhaps they could pay Ximian to do this for them?).

  13. Re:How about free books available online? by philll · · Score: 4, Informative · on General IT Books?

    O'Reilly Open Books Project
    Bruce Eckel's "Thinking in..." books
    Data Structures and Algorithms books
    MIT's Structure and Interpretation of Programming Languages
    Numerical Recipes series
    Handbook of Applied Cryptography
    The Art of Assembly Language Programming
    Object-Oriented System Development
    GTK+/Gnome Application Development
    GNU Autoconf, Automake, and Libtool
    Effective Perl (partial)
    Programming Pearls (partial)

  14. look closely by SkulkCU · · Score: 2 · on Gnome 2.0 RC1


    By the looks of this screenshot, somebody is taking a course in "Ethical Crap".

    (Unfortunately, its a fairly old screenshot.)

  15. Re:screenshots by phantomlord · · Score: 1, Troll · on Gnome 2.0 RC1
    But unfortunately during the discussion of the bug report, it became apparent that the developers really didn't care about this. It bothered me because one thing was being said on the public lists, while something rather contrary was being said in bugzilla.

    If you look at the thread I started entitled "Viewports and gnome 2" in the desktop-devel archives, you'll see that not only were developers not really interested in doing anything about it, they were downright belligerant to anyone who questioned what they did... to the point where in trying to discuss the problem, I wasn't allowed to call viewports "viewports". I specifically pointed out at length what I found to be deficient about having only workspaces in gnome2 and I kept being told to tell them what I thought the deficiencies were as if they just gave me a kneejerk reaction instead of reading what I wrote. The gnome2 developers really turned me sour on the whole project and I could really care less about the future of gnome2 now. I'll use gnome1 until something better comes along.

  16. VB on Solaris by yerricde · · Score: 2 · on Java Meets XP: Two Reviews

    not running VB on solaris might as well be a security feature opf Solaris as it protects it from run away programs and HORRIBLY coded apps...

    Actually, a VB compatible interpreter runs on the Solaris operating environment. What protects the system from runaway VB apps is not a lack of VB but the presence of working permissions on the system.

  17. Language supported by sebol · · Score: 1, Redundant · on Gnome 2.0 RC1

    What language supported in gnome2?

    here is the list


    http://developer.gnome.org/projects/gtp/status/g no me-2.0-core/

  18. Re:Truetype / Xprint by robkore · · Score: 1 · on Mozilla 1.0 Officially Here

    Hmm, after a little looking around, I came across this link. Mr. Blizzard doesn't like the truetype code, and does not want to support it. Too bad for me, I guess I will have to finally learn how to use those src.rpms.

  19. Re:Bugzilla Slashdot Blocker Circumvention Method( by jonasj · · Score: 1 · on Mozilla 1.0 Officially Here

    That's a bug in Galeon: http://bugzilla.gnome.org/show_bug.cgi?id=59572. Mozilla used to have this bug as well, but it was fixed in 0.9.9.

  20. Re:So... by DarkVein · · Score: 0 · on QuickTime 6 Public Beta Available
    Same reason you can't have Photoshop for Linux, or Microsoft Office for Linux: because the vendor wouldn't make any money off of a version of their software for Linux.

    Yet you can buy Maya for Linux, which costs just a hair more than Photoshop or Microsoft Office. You can buy Star Office, but most people don't, because OpenOffice is nearly the same quality with the definate promise of improvement. There's also Abiword. Gnumeric is a top-notch spreadsheet program that I've come to prefer to excel. There's more like this. There's really very little incentive to buy an office suite when you can get better for free.

    In other fields, the Free alternatives tend to kick the hiney of their commercial counterparts. Let's try a few, okay? Pan, a newsreader based loosley on Agent. Pan is the only newsreader to score perfectly on the GNKSA Evaluations. Compared this to its commercial basis, Agent's score really sucks. Then there's Quanta for HTML editing. VIM is fine for most people, but if you need that Dreamweaver-like crap, Quanta does it without getting in your way. And it's REALLY good. Oh yes, it's Free with a capital "EFF."

    This is a silly arguement to make against "Linux." This is Capitalism 101. Good products offered under better conditions succeed while inferior products do not. Maya is wonderful under Linux, and there is nothing else in its league available on a Unix-ish (OS X, Linux) platform.

    Oh, yes. You can also buy numerous games, of course. Neverwinter Nights in particular will be releasing for all three major platforms in a single box. We'll see what this does for sales.

  21. Re:Good news.. by bafu · · Score: 1 · on Germany, IBM Sign Major Linux Deal

    For infrastructure, it's top notch, for ease of use, it's a lumbering elephant.

    I'm not really sure I want to see it spread to the desktop since I'm afraid the process will involves changes that might make it a less effective for "infrastructure". Whether I like it or not, however, it's happening. There seem to be enough projects focusing on the desktop now (like Ximian Evolution, Nautilus, StarOffice/OpenOffice, etc., etc.) that we are reaching some kind of eerie critical mass. I keep hearing about folks who are using those tools to make the switch from a Windows desktop to a Linux one (in fact, I was just talking to a buddy who just switched 2 folks at his site at their request). Installation is not a biggie if the admin is involved since they can make install images for generic Linux desktop boxen as easily as they can for the Windows ones.

    Like I said, I'm not sure I like it, but it really looks like it's starting to happen...

  22. Re:Is this possible w/ linux/XFree? by phaze3000 · · Score: 2 · on Sun Discovers Dumb Terminals

    Both KDE and Gnome have session management features. Note that the applications you are using have to support them though..

  23. VB for UNIX by yerricde · · Score: 2 · on What's the Business Case for Microsoft and Open Source?

    Do you want this built in a month using VB, or in 6 months using C?

    "Do you want this built in a month using Microsoft Visual Basic, or in a month using GNOME Basic?" This will be the situation once GNOME Basic progresses some more.

    Even if "you can take the developer out of VB, but you can't take the VB out of the developer", you can take the developer out of a Microsoft environment while leaving the developer in what is essentially still VB. If you want to see this happen, fund the GNOME Basic project.

  24. Re:Extremism and Source Code Control... by rapid+prototype · · Score: 1 · on Interview With BitKeeper Author Larry McVoy

    am I the only one who is sick of RMS whining about the naming of Linux?

    so it's not okay to whine, but it's okay to whine about someone whining. cool. sounds like a Maple Leafs fan.

    RMS has the right to his opinion, but not to insult the intelligence of all of us by tring to tell us that we're all compromising our values by allowing this.

    but that is the point, we ARE compromising our values by allowing this. would you be happy if Linus openly professed his love for Internet Explorer (it is available free of charge)? As I said in an earlier post, Linus does not have the privilege of being able to choose the tool he wants based on its merits. he is the poster child of the revolution, the role model to aspiring little hackers everywhere. for him to use non-free tools to distribute a free OS sends the kind of mixed message that got us into this mess (first IBM, then Windows) in the first place.

    The accepted name is Linux not GNU/Linux.

    accepted by whom? you? not by RMS, not by a lot of people.

    -rp

  25. Slashdotted already! by Anonymous Coward · · Score: 1, Informative · on Murray Cumming on Programming for GNOME with C++
    Interview by Christian Fredrik Kalager Schaller

    If you have followed GNU/Linux for the last few years you know that GNOME has long been a stronghold of C, Perl and Python GUI programming. With Ximian's work on Mono, C# seems also to be a language that will see wide use in GNOME. Sun's involvement should also make Java applications integrate strongly with GNOME. But what about C++? Even in the GNU/Linux and Unix world this language has received many advocates and developers. I sat down with Murray Cumming, lead developer on the gtkmm and gnomemm C++ bindings for GTK+ and GNOME to get some information on the status of C++ development in GNOME.

    Christian: What is your background and what puts food on your table in real life?

    Murray: I'm a freelance developer, though that's difficult in the current market. I do C++ development on Unix, on all kinds of projects, such as protocol implementations, compilers, interpreters, data converters, management systems, and GUIs to make sense of all these. I've lived in Munich, Germany, for the past 3 years, but I'm officially a Brit. I love Munich's healthy outdoors lifestyle and easy-going socialising. I try to put the Lederhosen out of my mind.

    Over the past ten years I worked my way up through paper-shuffling, data-entry, typography/design, tech-support, database consultancy, and Windows development. I didn't learn programming at a college, and I still stubbornly believe that it made me a better developer. You have to really care about something to teach yourself in your spare time.

    I didn't use any Unix-like systems until Linux was widely available. People forget that before Linux you had to go to University to use Unix. Some companies had big Unix boxes, and the staff who used them generally earned huge sums because they knew how to move files around. Naturally they didn't let anyone else near them.

    I've grown to love the control that Unix gives you but I've done hardcore GUI development on MacOS and Windows, so I know there's more to life. Unlike lots of GNOME developers, I know that the Mac is a worthy influence but that Windows gives us nothing to chase.

    Christian: How did you get involved in developing gtkmm and gnomemm?

    Murray: I was originally just a user, more attracted to the up-to-date gtkmm than the awkward (and then non-free) QT. I did the carthorse work necessary to get gnomemm 1.2 usable and stable, and that's how I learned about the general issues involved.

    Then I decided to make a big effort to get gtkmm2 going, when it didn't look like anyone else was going to do it. Karl had the beginnings of gtkmm2, but it didn't build and he was reluctant to show it to the world, fearing that people would expect a certain amount of work from him. He didn't have time to do much more on it, but I did persuade him to put it on the gnome cvs. I worked on it gradually, sending progress reports to the list in case anyone was interested, and so that other people could learn too. After about 4 months I understood what it was doing, and it was able to run simple example code. As soon as I reached that stage lots of people started helping out.

    Christian: What are the main design ideas of gtkmm and gnomemm?

    Murray: We aim to provide the interface that a skilled C++ coder would expect, based on his experience of the language and the standard C++ Library. We try to use the standard language features wherever possible, just as any sensible C++ coder should. There would be nothing unusual about this if it weren't for bizarre C++ libraries such as QT and MFC. Is sanity really a design decision?

    It's not really a design decision, but we are particularly proud that C++ allows us to simplify the underlying C interfaces. For instance, GtkTreeView has a great deal of flexibility, but gtkmm doesn't expect you to worry about that functionality unless you actually want to use it.

    Christian: Okay, as you told me you made an effort to get gtkmm going, what where your aims when starting out with it?

    Murray: I had 2 aims for gtkmm2:

    1) Refactor it until both the interface and the implementation were ridiculously clear. I did not want any lingering doubt about the code just because people couldn't understand it. I believe that even a dull-witted person, with enough time, and enough notepaper, can make sense of anything. If he's not dull-witted then he'll make it easier for the next person.

    2) Get more developers involved. This becomes easier after 1) when people can understand the code enough to improve it, but it's also necessary to:

    • Present a clear vision so people know what's happening. To this end, I make a point of pre-announcing all major changes, discussing them, and announcing my interpretation of the consensus before proceeding. Everybody now understands that that's how we work, and that's why we've been successful. We only have to point to the list archives to justify our decisions in detail.
    • Nurture people to get them started. We do this on the mailing list and in the #c++ IRC channel on irc.gimp.net.
    • Let people know that their contributions are valued.

    I know from commercial software development that money alone doesn't motivate people. In both proprietary and open-source projects, a team can only succeed if its members feel valued and involved in something worthwhile. That requires constant attention, but it pays off eventually.

    Christian: That sounds good, so what is the current status of the C++ bindings for GNOME 2?

    Murray: We are approaching API stability for gtkmm2, I think. Our code generator warns us about any functions that we've forgotten to wrap, and we are keeping track of API coverage manually too. We are spending most of our time now perfecting and simplifying the complex TreeView and TextView interfaces, and I see the end in sight there too. Lots of people are using gtkmm2 now and the response is overwhelmingly positive.

    gnomemm 2 is progressing more slowly, mostly because it's more difficult for people to install all the latest GNOME 2 libraries. While it's still in development. Gnomemm 2 is much more integrated than gnomemm 1.2 - you can even download and install it as one tarball to get wrappers for libgnomeui, libglade, and gconf, among others.

    I recently shared the gtkmm maintainership with Daniel Elstner because he's been doing so much good work on fundamental stuff. With two committed maintainers, and several regular developers, the future should be secure.

    Also, we just announced support for the Forte C++ compiler that Sun will use for GNOME 2 on Solaris. And we are on the threshold of supporting Windows. Both of these platforms should be of great interest to commercial in-house developers.

    Christian: Do looking ahead, what are the future directions of gtkmm and gnomemm?

    Murray: For the future, we need to work on more Rapid Application Development stuff. The idea should be to add convenience without adding complication or straying from existing standards.

    I'm working on some libglade additions that should make it easier to link custom code with separately-designed user interfaces. libglademm's syntax is already simpler and more helpful than libglade.

    When GNOME's Anjuta2 is released, and when I can easily install KDevelop for KDE3, we need to add helper features for gtkmm.

    We need to add things such as:

    • Application-creation wizards so people can get started quickly.
    • An "Add a signal handler for this widget to this class" feature
    • An "Add a member variable for this Glade widget to this container class" feature.
    • A widget creation wizard.
    • A Bonobo control creation wizard.
    These IDEs should already have standard C++ features such as
    • Add a class, deriving from this widget class.
    • Add a method to this class.
    • Override this method in this class.
    We should then have all the functionality of Visual C++, but without requiring the same IDE for future editing or building of the code. It's possible to have those features without the insanity.

    Christian: OrbitCpp is being integrated to ship as part of the core ORBit2 package. What will this mean for C++ developers working on GNOME apps?

    Murray: The Bonobo bindings are progressing well, but until ORBit2's C++ support is merged in, just after GNOME 2, we must supply bonobomm separately. I'm particularly proud of the Bonobo bindings - the lack of API clarity in Bonobo has long irritated me and this is an opportunity to show that it's not really that difficult. I've explained the issues in more detail elsewhere. C++ is the natural language for CORBA, which is inherently object-orientated - CORBA in C was always a freakish idea so it's no wonder that it's difficult.

    So this means more people can use Bonobo. And the API clarity should mean that the Bonobo interfaces receive more scrutiny, because people will understand them well enough to criticize them.

    We're really lucky that Michael Meeks decided to support our efforts by merging the C++ mapping into ORBit2 itself. It gives it a mainstream future.

    Christian: The release of GNOME 2 is approaching fast now, how does the GNOME 2 platform look from the view of someone producing language bindings for the GNOME platform? Will there be any significant design changes introduced into the bindings due to the changed in the GNOME 2 platform?

    Murray: Language bindings should now be much easier. The GTK+ and GNOME authors are more aware of the needs of language bindings and the various bindings are cooperating more, particularly with the .defs interface-definition files. For instance, we use James Henstridge's .defs generation scripts for pygtk.

    The transition to GNOME 2 has allowed us to make previously forbidden interface changes to the underlying libraries. We developed gtkmm2 while GTK+ 2 was being developed. With gtkmm 1.2, we just complained about problems in GTK+ 1.2, but this time we fixed the problems in GTK+ as we found them.

    gtkmm2 (for GNOME 2) is significantly different than gtkmm 1.2 (for GNOME 1.x). Some of these changes are due to changes in GTK+, but most are just lessons that we learned from gtkmm 1.2. GNOME 2 rationalizes its interfaces a lot by deprecating its more crufty stuff, and we make our interfaces even clearer by omitting those deprecated parts completely.

    Christian: What are you favourite applications that has been developed using the gtkmm and gnomemm bindings?

    Murray: I use Gabber every day as an instant messenger client - I love how it Just Works. I'm trying to persuade Julian to start the gnomemm2 port, even if I have to code it myself.

    Cactus's Guikachu is also pretty impressive - it has made me want to do some Palm development.

    There's a bunch of specialist apps out there, though not so many have been ported to gtkmm2 yet. I think that a lot of our users are doing in-house stuff. C++ is much more popular than C for that kind of thing.

    I have high hopes for my own Glom app. It's meant to be a very easy-to-use database application that embodies my years of database design experience. But I've been too busy working on gtkmm2/gnomemm2 to port it properly. In the meantime, I released a small file utility, PrefixSuffix, which is a pretty good gtkmm2 example.

    Christian: What are your thoughts on the future of the C++ language? Will it continue to be one of the major computer languages or is it set to be replaced by languages such as Java and C#?

    Murray: In my opinion, Java and C# are much closer to interpreted languages in their design. By this I mean that much more is decided at runtime than at compile-time. I'm bored by discussions of executable speed, but I do feel that compile-time checking verifies designs and speeds development. Java and C# offer object-orientated improvements over scripting languages such as Perl and Visual Basic, but I see no competitor to C++'s feature set. I expect it to maintain its current high level of popularity.

    Christian: About two years ago there was a lot of noise around gtkmm and gnomemm, with Havoc Pennington having started the Inti project, and with the leaving of Guillaume Laurent from gtkmm development, after which Guillaume was quite vocal in why he felt that gtkmm wasn't what thought is should be, in fact he called it a 'throw-away prototype' for a GTK+ C++ wrapper. Two years is a lot of time in the software world so I'm wondering what your thoughts are on the issues debated on back then, and how you see today's versions of gtkmm and gnomemm responding to any real issues raised back then.

    Murray: I wasn't involved in those discussions, but I was annoyed at the schism. I like to think that I would have found an acceptable consensus. Most gtkmm users and developers strongly disagreed with Inti's design decisions so we carried on hoping that we would prevail. We did, and Inti didn't, and it's all history now. Inti died because it never involved a community of hackers, whereas I like to think that people preferred to work on gtkmm's design and felt more welcome in the gtkmm community.

    RedHat's whole Inti framework never made much sense to people. Havoc is such a pragmatic developer that I still don't believe it was really his brainchild.

    But Inti did create confusion among users, and even prompted one of the gtkmm maintainers to give up. My guess is that Guillaume never really got a handle on the gtkmm codebase and took the opportunity to jump clear of something that daunted him. When I was building gtkmm2 I sometimes felt the same but I chose instead to radically refactor it until it was manageable. I believe Guillaume felt certain anyway that, with RedHat's backing, Inti would succeed and gtkmm would fade away.

    Guillaume uses QT now. He has stated that it was more important for him to have a full working toolkit than a perfect API. gtkmm2 will go stable soon - then we will have both in one toolkit.

    Christian: What are the main differences of coding with gtkmm and gnomemm compared to coding with QT and KDE?

    Murray: I addressed this in my GUADEC talk (1) and (2).

    Basically, QT isn't developed publicly so it makes a number of mistakes without the benefit of any real criticism. Chief among these is its modification of the C++ language and the use of its own non-standard string class. It isn't necessary, as we've proved. These are just two ways that we've kept more up-to-date with the state-of-the-art in C++. It's then easier to use gtkmm in combination with other C++ APIs. I believe that you'll love gtkmm if you love C++, and that gtkmm is a better role-model if you're learning C++.

    People sometimes complain about a lack of gtkmm documentation compared to QT, but that hasn't been true for a long time(*).

    And perhaps most importantly, if you find a problem with gtkmm you can submit a patch or discuss it with the developers.

    Christian: What is the advantage of using the bindings when creating GNOME and GTK+ applications in C++ compared to just accessing the C widgets?

    Murray: Again, the GUADEC talk mentioned this (1) and (2).

    gtkmm applications tends to be more organized than GTK+ programs. That's mostly because it's laughably easy for us to derive new widgets just to organise our code. In comparison, the structure of GTK+ code tends to be defined by the path that data happens to take through the code, rather than the layout of the source code itself.

    Christian: What would you say to a developer who is trying to decide whether to write his application in C or whether to use gtkmm and gnomemm and C++?

    Murray: I believe it's easier to develop software with C++, even if you're not very experienced, because the structure is there in the code, not just in your head. If you're as good as the GTK+/GNOME developers then maybe you can deal with the underlying C interfaces, but, in my experience, most coders want an easier life.

    I'd recommend that people compare the C and C++ versions of the examples before deciding.

    Christian: You made a presentation at GUADEC 3 this year. What is your impression of the GNOME community, is it becoming more language agnostic or is there still a strong favouring of C among the hackers you talked too?

    Murray: I think people accept now that there will always be active language bindings for GNOME, and many of the core hackers now routinely use more than one programming language. There is still some general Unix-style dislike of C++, but interest has grown as people have seen that gtkmm is very much alive and useful.

    Christian: For anyone wanting to learn how to create applications using gtkmm and gnomemm, where should they start looking? Are there any applications out there that you think a newbie would find a easy starting point to look at before starting creating their own applications?

    Murray: Assuming that you're already a C++ coder, you should be able to get started easily by looking at the examples and the 'Programming with gtkmm' book. In fact, we have a particularly good documentation overview page with quick links into the manual and the reference documentation: http://www.gtkmm.org/gtkmm2/

    We have converted all of the GTK+ examples and demos and added some of our own. I believe it's easier for a C++ coder to understand the gtkmm examples than it is for a C coder to understand the GTK+ examples.

    I strongly suggest that you start with gtkmm2 rather than the stable gtkmm 1.2, because we have obliterated several confusing things.

    People should also join the gtkmm-main mailing list and the #c++ channel on irc.gnome.org. We are a helpful bunch.

    Christian: Okay, thanks for taking the time to talk with me Murray.

    Murray: No problem, it was a pleasure.

  26. Slashdotted already! by Anonymous Coward · · Score: 1, Informative · on Murray Cumming on Programming for GNOME with C++
    Interview by Christian Fredrik Kalager Schaller

    If you have followed GNU/Linux for the last few years you know that GNOME has long been a stronghold of C, Perl and Python GUI programming. With Ximian's work on Mono, C# seems also to be a language that will see wide use in GNOME. Sun's involvement should also make Java applications integrate strongly with GNOME. But what about C++? Even in the GNU/Linux and Unix world this language has received many advocates and developers. I sat down with Murray Cumming, lead developer on the gtkmm and gnomemm C++ bindings for GTK+ and GNOME to get some information on the status of C++ development in GNOME.

    Christian: What is your background and what puts food on your table in real life?

    Murray: I'm a freelance developer, though that's difficult in the current market. I do C++ development on Unix, on all kinds of projects, such as protocol implementations, compilers, interpreters, data converters, management systems, and GUIs to make sense of all these. I've lived in Munich, Germany, for the past 3 years, but I'm officially a Brit. I love Munich's healthy outdoors lifestyle and easy-going socialising. I try to put the Lederhosen out of my mind.

    Over the past ten years I worked my way up through paper-shuffling, data-entry, typography/design, tech-support, database consultancy, and Windows development. I didn't learn programming at a college, and I still stubbornly believe that it made me a better developer. You have to really care about something to teach yourself in your spare time.

    I didn't use any Unix-like systems until Linux was widely available. People forget that before Linux you had to go to University to use Unix. Some companies had big Unix boxes, and the staff who used them generally earned huge sums because they knew how to move files around. Naturally they didn't let anyone else near them.

    I've grown to love the control that Unix gives you but I've done hardcore GUI development on MacOS and Windows, so I know there's more to life. Unlike lots of GNOME developers, I know that the Mac is a worthy influence but that Windows gives us nothing to chase.

    Christian: How did you get involved in developing gtkmm and gnomemm?

    Murray: I was originally just a user, more attracted to the up-to-date gtkmm than the awkward (and then non-free) QT. I did the carthorse work necessary to get gnomemm 1.2 usable and stable, and that's how I learned about the general issues involved.

    Then I decided to make a big effort to get gtkmm2 going, when it didn't look like anyone else was going to do it. Karl had the beginnings of gtkmm2, but it didn't build and he was reluctant to show it to the world, fearing that people would expect a certain amount of work from him. He didn't have time to do much more on it, but I did persuade him to put it on the gnome cvs. I worked on it gradually, sending progress reports to the list in case anyone was interested, and so that other people could learn too. After about 4 months I understood what it was doing, and it was able to run simple example code. As soon as I reached that stage lots of people started helping out.

    Christian: What are the main design ideas of gtkmm and gnomemm?

    Murray: We aim to provide the interface that a skilled C++ coder would expect, based on his experience of the language and the standard C++ Library. We try to use the standard language features wherever possible, just as any sensible C++ coder should. There would be nothing unusual about this if it weren't for bizarre C++ libraries such as QT and MFC. Is sanity really a design decision?

    It's not really a design decision, but we are particularly proud that C++ allows us to simplify the underlying C interfaces. For instance, GtkTreeView has a great deal of flexibility, but gtkmm doesn't expect you to worry about that functionality unless you actually want to use it.

    Christian: Okay, as you told me you made an effort to get gtkmm going, what where your aims when starting out with it?

    Murray: I had 2 aims for gtkmm2:

    1) Refactor it until both the interface and the implementation were ridiculously clear. I did not want any lingering doubt about the code just because people couldn't understand it. I believe that even a dull-witted person, with enough time, and enough notepaper, can make sense of anything. If he's not dull-witted then he'll make it easier for the next person.

    2) Get more developers involved. This becomes easier after 1) when people can understand the code enough to improve it, but it's also necessary to:

    • Present a clear vision so people know what's happening. To this end, I make a point of pre-announcing all major changes, discussing them, and announcing my interpretation of the consensus before proceeding. Everybody now understands that that's how we work, and that's why we've been successful. We only have to point to the list archives to justify our decisions in detail.
    • Nurture people to get them started. We do this on the mailing list and in the #c++ IRC channel on irc.gimp.net.
    • Let people know that their contributions are valued.

    I know from commercial software development that money alone doesn't motivate people. In both proprietary and open-source projects, a team can only succeed if its members feel valued and involved in something worthwhile. That requires constant attention, but it pays off eventually.

    Christian: That sounds good, so what is the current status of the C++ bindings for GNOME 2?

    Murray: We are approaching API stability for gtkmm2, I think. Our code generator warns us about any functions that we've forgotten to wrap, and we are keeping track of API coverage manually too. We are spending most of our time now perfecting and simplifying the complex TreeView and TextView interfaces, and I see the end in sight there too. Lots of people are using gtkmm2 now and the response is overwhelmingly positive.

    gnomemm 2 is progressing more slowly, mostly because it's more difficult for people to install all the latest GNOME 2 libraries. While it's still in development. Gnomemm 2 is much more integrated than gnomemm 1.2 - you can even download and install it as one tarball to get wrappers for libgnomeui, libglade, and gconf, among others.

    I recently shared the gtkmm maintainership with Daniel Elstner because he's been doing so much good work on fundamental stuff. With two committed maintainers, and several regular developers, the future should be secure.

    Also, we just announced support for the Forte C++ compiler that Sun will use for GNOME 2 on Solaris. And we are on the threshold of supporting Windows. Both of these platforms should be of great interest to commercial in-house developers.

    Christian: Do looking ahead, what are the future directions of gtkmm and gnomemm?

    Murray: For the future, we need to work on more Rapid Application Development stuff. The idea should be to add convenience without adding complication or straying from existing standards.

    I'm working on some libglade additions that should make it easier to link custom code with separately-designed user interfaces. libglademm's syntax is already simpler and more helpful than libglade.

    When GNOME's Anjuta2 is released, and when I can easily install KDevelop for KDE3, we need to add helper features for gtkmm.

    We need to add things such as:

    • Application-creation wizards so people can get started quickly.
    • An "Add a signal handler for this widget to this class" feature
    • An "Add a member variable for this Glade widget to this container class" feature.
    • A widget creation wizard.
    • A Bonobo control creation wizard.
    These IDEs should already have standard C++ features such as
    • Add a class, deriving from this widget class.
    • Add a method to this class.
    • Override this method in this class.
    We should then have all the functionality of Visual C++, but without requiring the same IDE for future editing or building of the code. It's possible to have those features without the insanity.

    Christian: OrbitCpp is being integrated to ship as part of the core ORBit2 package. What will this mean for C++ developers working on GNOME apps?

    Murray: The Bonobo bindings are progressing well, but until ORBit2's C++ support is merged in, just after GNOME 2, we must supply bonobomm separately. I'm particularly proud of the Bonobo bindings - the lack of API clarity in Bonobo has long irritated me and this is an opportunity to show that it's not really that difficult. I've explained the issues in more detail elsewhere. C++ is the natural language for CORBA, which is inherently object-orientated - CORBA in C was always a freakish idea so it's no wonder that it's difficult.

    So this means more people can use Bonobo. And the API clarity should mean that the Bonobo interfaces receive more scrutiny, because people will understand them well enough to criticize them.

    We're really lucky that Michael Meeks decided to support our efforts by merging the C++ mapping into ORBit2 itself. It gives it a mainstream future.

    Christian: The release of GNOME 2 is approaching fast now, how does the GNOME 2 platform look from the view of someone producing language bindings for the GNOME platform? Will there be any significant design changes introduced into the bindings due to the changed in the GNOME 2 platform?

    Murray: Language bindings should now be much easier. The GTK+ and GNOME authors are more aware of the needs of language bindings and the various bindings are cooperating more, particularly with the .defs interface-definition files. For instance, we use James Henstridge's .defs generation scripts for pygtk.

    The transition to GNOME 2 has allowed us to make previously forbidden interface changes to the underlying libraries. We developed gtkmm2 while GTK+ 2 was being developed. With gtkmm 1.2, we just complained about problems in GTK+ 1.2, but this time we fixed the problems in GTK+ as we found them.

    gtkmm2 (for GNOME 2) is significantly different than gtkmm 1.2 (for GNOME 1.x). Some of these changes are due to changes in GTK+, but most are just lessons that we learned from gtkmm 1.2. GNOME 2 rationalizes its interfaces a lot by deprecating its more crufty stuff, and we make our interfaces even clearer by omitting those deprecated parts completely.

    Christian: What are you favourite applications that has been developed using the gtkmm and gnomemm bindings?

    Murray: I use Gabber every day as an instant messenger client - I love how it Just Works. I'm trying to persuade Julian to start the gnomemm2 port, even if I have to code it myself.

    Cactus's Guikachu is also pretty impressive - it has made me want to do some Palm development.

    There's a bunch of specialist apps out there, though not so many have been ported to gtkmm2 yet. I think that a lot of our users are doing in-house stuff. C++ is much more popular than C for that kind of thing.

    I have high hopes for my own Glom app. It's meant to be a very easy-to-use database application that embodies my years of database design experience. But I've been too busy working on gtkmm2/gnomemm2 to port it properly. In the meantime, I released a small file utility, PrefixSuffix, which is a pretty good gtkmm2 example.

    Christian: What are your thoughts on the future of the C++ language? Will it continue to be one of the major computer languages or is it set to be replaced by languages such as Java and C#?

    Murray: In my opinion, Java and C# are much closer to interpreted languages in their design. By this I mean that much more is decided at runtime than at compile-time. I'm bored by discussions of executable speed, but I do feel that compile-time checking verifies designs and speeds development. Java and C# offer object-orientated improvements over scripting languages such as Perl and Visual Basic, but I see no competitor to C++'s feature set. I expect it to maintain its current high level of popularity.

    Christian: About two years ago there was a lot of noise around gtkmm and gnomemm, with Havoc Pennington having started the Inti project, and with the leaving of Guillaume Laurent from gtkmm development, after which Guillaume was quite vocal in why he felt that gtkmm wasn't what thought is should be, in fact he called it a 'throw-away prototype' for a GTK+ C++ wrapper. Two years is a lot of time in the software world so I'm wondering what your thoughts are on the issues debated on back then, and how you see today's versions of gtkmm and gnomemm responding to any real issues raised back then.

    Murray: I wasn't involved in those discussions, but I was annoyed at the schism. I like to think that I would have found an acceptable consensus. Most gtkmm users and developers strongly disagreed with Inti's design decisions so we carried on hoping that we would prevail. We did, and Inti didn't, and it's all history now. Inti died because it never involved a community of hackers, whereas I like to think that people preferred to work on gtkmm's design and felt more welcome in the gtkmm community.

    RedHat's whole Inti framework never made much sense to people. Havoc is such a pragmatic developer that I still don't believe it was really his brainchild.

    But Inti did create confusion among users, and even prompted one of the gtkmm maintainers to give up. My guess is that Guillaume never really got a handle on the gtkmm codebase and took the opportunity to jump clear of something that daunted him. When I was building gtkmm2 I sometimes felt the same but I chose instead to radically refactor it until it was manageable. I believe Guillaume felt certain anyway that, with RedHat's backing, Inti would succeed and gtkmm would fade away.

    Guillaume uses QT now. He has stated that it was more important for him to have a full working toolkit than a perfect API. gtkmm2 will go stable soon - then we will have both in one toolkit.

    Christian: What are the main differences of coding with gtkmm and gnomemm compared to coding with QT and KDE?

    Murray: I addressed this in my GUADEC talk (1) and (2).

    Basically, QT isn't developed publicly so it makes a number of mistakes without the benefit of any real criticism. Chief among these is its modification of the C++ language and the use of its own non-standard string class. It isn't necessary, as we've proved. These are just two ways that we've kept more up-to-date with the state-of-the-art in C++. It's then easier to use gtkmm in combination with other C++ APIs. I believe that you'll love gtkmm if you love C++, and that gtkmm is a better role-model if you're learning C++.

    People sometimes complain about a lack of gtkmm documentation compared to QT, but that hasn't been true for a long time(*).

    And perhaps most importantly, if you find a problem with gtkmm you can submit a patch or discuss it with the developers.

    Christian: What is the advantage of using the bindings when creating GNOME and GTK+ applications in C++ compared to just accessing the C widgets?

    Murray: Again, the GUADEC talk mentioned this (1) and (2).

    gtkmm applications tends to be more organized than GTK+ programs. That's mostly because it's laughably easy for us to derive new widgets just to organise our code. In comparison, the structure of GTK+ code tends to be defined by the path that data happens to take through the code, rather than the layout of the source code itself.

    Christian: What would you say to a developer who is trying to decide whether to write his application in C or whether to use gtkmm and gnomemm and C++?

    Murray: I believe it's easier to develop software with C++, even if you're not very experienced, because the structure is there in the code, not just in your head. If you're as good as the GTK+/GNOME developers then maybe you can deal with the underlying C interfaces, but, in my experience, most coders want an easier life.

    I'd recommend that people compare the C and C++ versions of the examples before deciding.

    Christian: You made a presentation at GUADEC 3 this year. What is your impression of the GNOME community, is it becoming more language agnostic or is there still a strong favouring of C among the hackers you talked too?

    Murray: I think people accept now that there will always be active language bindings for GNOME, and many of the core hackers now routinely use more than one programming language. There is still some general Unix-style dislike of C++, but interest has grown as people have seen that gtkmm is very much alive and useful.

    Christian: For anyone wanting to learn how to create applications using gtkmm and gnomemm, where should they start looking? Are there any applications out there that you think a newbie would find a easy starting point to look at before starting creating their own applications?

    Murray: Assuming that you're already a C++ coder, you should be able to get started easily by looking at the examples and the 'Programming with gtkmm' book. In fact, we have a particularly good documentation overview page with quick links into the manual and the reference documentation: http://www.gtkmm.org/gtkmm2/

    We have converted all of the GTK+ examples and demos and added some of our own. I believe it's easier for a C++ coder to understand the gtkmm examples than it is for a C coder to understand the GTK+ examples.

    I strongly suggest that you start with gtkmm2 rather than the stable gtkmm 1.2, because we have obliterated several confusing things.

    People should also join the gtkmm-main mailing list and the #c++ channel on irc.gnome.org. We are a helpful bunch.

    Christian: Okay, thanks for taking the time to talk with me Murray.

    Murray: No problem, it was a pleasure.

  27. Re:Congratulations! by Anonymous Coward · · Score: -1, Troll · on KDE 3.0.1 Ships

    Confronting the KDE propaganda machine.

    The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

    • Myth #1 - KDE is more integrated than GNOME

      The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

    • Myth #2 - KDE is easier to use

      Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME, and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian, which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small and lame Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

    • Myth #3 - KDE is more popular

      In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

      One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

    • Myth #4 - Konqueror is the best Linux browser

      Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

    • Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

      This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

      GNOME applications get a good deal more testing in their 0.x stages, and despite shorter development phases they mature and reach stable featureful release versions much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

      It's not just in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

      It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.


      Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

    • Myth #6 - KDE is faster and takes less memory than GNOME

      KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

      Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

    • Myth #7 - GNOME development is slower. KDE releases faster.

      Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

      Perhaps the greatest example of KDE release games occured with the recent KDE 3.0 release. In a desperate race to beat GNOME 2.0 to, the KDE team did not put back their schedule in the middle of a late release freeze when they suddenly added lots of new features - and, as expected,

    • Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

      To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-out and of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

  28. Re:Congratulations! by Anonymous Coward · · Score: -1, Troll · on KDE 3.0.1 Ships

    Confronting the KDE propaganda machine.

    The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

    • Myth #1 - KDE is more integrated than GNOME

      The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

    • Myth #2 - KDE is easier to use

      Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME, and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian, which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small and lame Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

    • Myth #3 - KDE is more popular

      In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

      One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

    • Myth #4 - Konqueror is the best Linux browser

      Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

    • Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

      This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

      GNOME applications get a good deal more testing in their 0.x stages, and despite shorter development phases they mature and reach stable featureful release versions much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

      It's not just in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

      It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.


      Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

    • Myth #6 - KDE is faster and takes less memory than GNOME

      KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

      Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

    • Myth #7 - GNOME development is slower. KDE releases faster.

      Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

      Perhaps the greatest example of KDE release games occured with the recent KDE 3.0 release. In a desperate race to beat GNOME 2.0 to, the KDE team did not put back their schedule in the middle of a late release freeze when they suddenly added lots of new features - and, as expected,

    • Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

      To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-out and of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

  29. Re:Congratulations! by Anonymous Coward · · Score: -1, Troll · on KDE 3.0.1 Ships

    Confronting the KDE propaganda machine.

    The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

    • Myth #1 - KDE is more integrated than GNOME

      The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

    • Myth #2 - KDE is easier to use

      Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME, and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian, which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small and lame Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

    • Myth #3 - KDE is more popular

      In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

      One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

    • Myth #4 - Konqueror is the best Linux browser

      Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

    • Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

      This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

      GNOME applications get a good deal more testing in their 0.x stages, and despite shorter development phases they mature and reach stable featureful release versions much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

      It's not just in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

      It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.


      Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

    • Myth #6 - KDE is faster and takes less memory than GNOME

      KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

      Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

    • Myth #7 - GNOME development is slower. KDE releases faster.

      Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

      Perhaps the greatest example of KDE release games occured with the recent KDE 3.0 release. In a desperate race to beat GNOME 2.0 to, the KDE team did not put back their schedule in the middle of a late release freeze when they suddenly added lots of new features - and, as expected,

    • Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

      To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-out and of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

  30. KDE Myths by Anonymous Coward · · Score: 1, Funny · on KDE 3.0.1 Ships

    The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

    • Myth #1 - KDE is more integrated than GNOME

      The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

    • Myth #2 - KDE is easier to use

      Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

    • Myth #3 - KDE is more popular

      In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

      One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

    • Myth #4 - Konqueror is the best Linux browser

      Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

    • Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

      See also: Qt/TrollTech. This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

      GNOME applications get much more testing in their 0.x stages and despite shorter development phases they mature and reach stable featureful release states much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

      It's not only in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

      It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.


      Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

    • Myth #6 - KDE is faster and takes less memory than GNOME

      KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

      Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

    • Myth #7 - GNOME development is slower. KDE releases faster.

      Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

  31. Crux for Metacity exists by Turmio · · Score: 2, Informative · on Sun Drops Sawfish for Metacity

    Crux is ported. I'm currently using it. Works great, looks nice. This Metacity is compiled from source obtained from GNOME CVS, I'm not sure if the latest released tarball includes any themes, though. In Meta city CVS repository there're 8 different themes.

  32. Crux for Metacity exists by Turmio · · Score: 2, Informative · on Sun Drops Sawfish for Metacity

    Crux is ported. I'm currently using it. Works great, looks nice. This Metacity is compiled from source obtained from GNOME CVS, I'm not sure if the latest released tarball includes any themes, though. In Meta city CVS repository there're 8 different themes.

  33. Crux for Metacity exists by Turmio · · Score: 2, Informative · on Sun Drops Sawfish for Metacity

    Crux is ported. I'm currently using it. Works great, looks nice. This Metacity is compiled from source obtained from GNOME CVS, I'm not sure if the latest released tarball includes any themes, though. In Meta city CVS repository there're 8 different themes.

  34. Reason for the switch. by Hornsby · · Score: 5, Interesting · on Sun Drops Sawfish for Metacity

    I just grokked this off of the gnome mailing list here.

    > Btw: Why there has not been any updates for sawfish lately?

    Rumor has it that John was employed by Apple and that as part of the employment contract he's no longer allowed to develop sawfish.

    So there you have it! Before you start flaming back and forth about what's better, think about the logistics behind using a WM that's no longer being maintained.

  35. Re:They won't learn by sheean.nl · · Score: 3, Interesting · on Microsoft Urged Linux Retaliation

    it has a shitty gui(most distros)

    when was the last time you used Linux? Check out KDE 3 or GNOME they are sweeeet!

    noone writes software that works for linux

    It's not purely about how much, it's also about how good, and most Linux software is (imho) good. Before I'm going to write down a list of people that makes software for Linux, just check out sourceforge, download.com, tucows etc... you'll find a lot.

    noone writes software that works for linux

    Out of the box they mostly have far more beter support, and for most hardware you can get the drivers, only for those products-nobody-have-ever-heard-of-produced-on-ant artica-stuff you won't get drivers nowadays.

    And please if you reply, don't write down experiences of distros like RedHat 4.x, use a new one.

  36. Re:More props for Litestep by 0x0d0a · · Score: 1, Offtopic · on Alternative Desktops for Win32?

    Sure. Just about any UNIX desktop environment is as flexible as LiteStep. Roll your own...don't feel like you just need to use KDE or GNOME or something like that. I've got a rather nice desktop with sawfish, the sawfish pager, all status information being shown via gkrellm, and programs launched via the keyboard using xbindkeys. No GNOME or KDE flavoring necessary.

    AfterStep is probably the closest in functionality to LiteStep, but I personally prefer Enlightenment if you're looking for flash, Sawfish if you're looking for functionality, and Black Box if you're looking for speed.

    Steps in roll-your-own:

    Choose a base desktop environment (keep in mind that you can just mix and match bits of them...I used to use the GNOME panel without the rest of GNOME, and a roommate uses GNOME apps with the KDE environment):
    None
    GNOME
    KDE
    ROX
    foXdesktop
    Perltop
    Equinox
    XFce
    Once you've chosen a desktop environment (or the lack of one), and possibly removed the parts of it that you don't like (with GNOME, I wholeheartedly suggest trying it without Nautilus, possibly without anything but the panel), then you get to choose a dock. Your current desktop may or may not include a dock/panel/wharf.

    If it doesn't, icedock provides an environment-independent wharf for the afterstep-style wharf system -- swallowing apps.
    gkrellm (seems to be currently down) makes for a nice status-monitor style dock.
    Or you can make your own impromptu dock...I've built them before by starting xload and xlock with proper geometry arguments to stack them on top of each other, and having sawfish make the windows sticky and slap 'em at the edge of the screen.
    Now a window manager. There are so many of these that I'm not going to list them all. I'll mention a few notables:
    sawfish is a fairly fast, *extremely* flexible (everything's written in lisp, much like emacs) window manager that uses gtk. Currently GNOME's default. I love this thing, but it doesn't come with a pager, so you either need to use a base desktop environment with a pager or use spager.
    enlightenment is, at least until the next major release, still a window manager and not a desktop environment. Lots of emphasis on eye candy.
    ion, a novel window manager that's designed to be managed entirely with the keyboard and never overlap windows.
    blackbox is what I'd suggest if you needed a fast environment that still looked nice.

    Most WMs support launching programs with given key combinations. I'd advise against this. The excellent XBindKeys is window-manager independent, quite capable, allows you to kill off your window manager and still use keys to start programs, etc. Plus, there's a nice benefit to using a different program than your window manager to launch programs. If you never launch external programs with your WM, you can renice -10 `pidof sawfish` or whatever your window manager is. Making your window manager (and X) meaner with respect to CPU scheduling makes for a much more snappy environment when edge flipping or the like. Sure, it might take a sec for the mozilla windows in the background to finish redrawing when I flip to a new desktop, but in the meantime I can do my work without waiting around for them.

    The reason you don't want to make your WM meaner if you use it to launch programs is that then all the programs will also be equally mean.

    Decide on the Big Four applications of any X desktop. Text editor, web browser, file manager, and terminal emulator.

    Text editor:
    I can't possibly cover this holy war here. My personal preference is xemacs, which is a bit of a learning curve for new users from Windows, but well worth it in power in the long run. You may want something that meshes more with the rest of your chosen desktop environment.

    Web browser:
    Just because KDE uses Konqueror and GNOME uses galeon by default is no reason to stick with those. Of course, you also can use either Konq without KDE or galeon without GNOME. You're rolling your own environment!
    mozilla is now (after years of work) a good web browser. Big, still slow and still RAM-hungry, but usably so.
    dillo Lightweight, very fast, pretty stable, very screen-space efficient...I can't say enough good things about dillo. If you use dillo as your primary browser, be aware of the fact that it has fewer features than the large browsers, that it doesn't currently (without a patch) support SSL, that it uses a UNIXish config-file preferences interface, and that it doesn't lay out nested tables or wrap text around images the same way Mozilla does. I keep Mozilla around as a backup browser, but dillo is so freakishly fast that it's hard to want to use anything else.
    There are a few other browsers, but Konqueror, Mozilla, and dillo are (IMHO) the big GUI players on Linux. Amaya is a specialty browser, Opera (thanks to its MDI interface) doesn't seem to have caught on much in the Linux world, and Navigator 4.x is definitely on its way out the door.

    File manager:
    You may choose to simply use a command-line shell and the standard file utilities (cp, rm, ls) to do your file management -- I do, and I've tried hard to give other things a chance. But if you prefer to use a specalized GUI tool:
    Konqueror can be used, even if you aren't using KDE (you do, of course, need the KDE libraries installed). Faster than gecko (the engine in mozilla and galeon) and almost as standards compliant, Konqueror has a lot of fans.
    GMC is no longer being developed, but it's a reasonable lightweight interface.
    Nautilus, the current official GNOME file manager is big, slow, RAM-hungry, and pretty. Not sure how well Nautilus works outside of GNOME (given that Konqueror can work outside of KDE, I would expect this capability of Nautilus).
    ROX filer is a very fast little gtk file manager.
    There are a lot of file managers out there, so I won't list them all, especially as I'm happy with just bash and the POSIX tools.

    Terminal emulator:
    GNOME and KDE both come with terminal emulators -- gnome-terminal and Konsole. I'm not very impressed with either -- they're both very slow and aren't available apart from their associated desktop environment. Konsole supports tabbed terminals, which some people may like. Both of them are fairly easy to configure, and are suitable for newbies to work with.
    Multi Gnome Terminal extends gnome-terminal significantly with Konsole-style tabs and a set of other features. If you like gnome-terminal, you should probably consider using this instead.
    Eterm is a RAM-heavy terminal emulator that was designed to look nice. For all the tinting and blending it can do, reasonably fast.
    Aterm seems to be basically a less featureful, less memory-hungry Eterm-like terminal.
    xterm is the reasonably fast not-so-pretty fairly RAM-hungry terminal that's used all over the world.
    rxvt is easily my favorite terminal emulator. rxvt uses less RAM than anything else out there, and is incredibly fast. You can compile in only the features you want to use (which can, of course, also be disabled at runtime). Background images are supported, but emphasis is not much on eye candy. Very configurable. The biggest drawback is that configuration is through traditional UNIX methods, which may scare away some -- X resources, command line options, compile-time options.

    Whatever you do, choose a set of software that you like, and remember -- your desktop environment is based on Linux, which means it should composed of exactly the parts that you like most. Have fun!

  37. Re:More props for Litestep by 0x0d0a · · Score: 1, Offtopic · on Alternative Desktops for Win32?

    Sure. Just about any UNIX desktop environment is as flexible as LiteStep. Roll your own...don't feel like you just need to use KDE or GNOME or something like that. I've got a rather nice desktop with sawfish, the sawfish pager, all status information being shown via gkrellm, and programs launched via the keyboard using xbindkeys. No GNOME or KDE flavoring necessary.

    AfterStep is probably the closest in functionality to LiteStep, but I personally prefer Enlightenment if you're looking for flash, Sawfish if you're looking for functionality, and Black Box if you're looking for speed.

    Steps in roll-your-own:

    Choose a base desktop environment (keep in mind that you can just mix and match bits of them...I used to use the GNOME panel without the rest of GNOME, and a roommate uses GNOME apps with the KDE environment):
    None
    GNOME
    KDE
    ROX
    foXdesktop
    Perltop
    Equinox
    XFce
    Once you've chosen a desktop environment (or the lack of one), and possibly removed the parts of it that you don't like (with GNOME, I wholeheartedly suggest trying it without Nautilus, possibly without anything but the panel), then you get to choose a dock. Your current desktop may or may not include a dock/panel/wharf.

    If it doesn't, icedock provides an environment-independent wharf for the afterstep-style wharf system -- swallowing apps.
    gkrellm (seems to be currently down) makes for a nice status-monitor style dock.
    Or you can make your own impromptu dock...I've built them before by starting xload and xlock with proper geometry arguments to stack them on top of each other, and having sawfish make the windows sticky and slap 'em at the edge of the screen.
    Now a window manager. There are so many of these that I'm not going to list them all. I'll mention a few notables:
    sawfish is a fairly fast, *extremely* flexible (everything's written in lisp, much like emacs) window manager that uses gtk. Currently GNOME's default. I love this thing, but it doesn't come with a pager, so you either need to use a base desktop environment with a pager or use spager.
    enlightenment is, at least until the next major release, still a window manager and not a desktop environment. Lots of emphasis on eye candy.
    ion, a novel window manager that's designed to be managed entirely with the keyboard and never overlap windows.
    blackbox is what I'd suggest if you needed a fast environment that still looked nice.

    Most WMs support launching programs with given key combinations. I'd advise against this. The excellent XBindKeys is window-manager independent, quite capable, allows you to kill off your window manager and still use keys to start programs, etc. Plus, there's a nice benefit to using a different program than your window manager to launch programs. If you never launch external programs with your WM, you can renice -10 `pidof sawfish` or whatever your window manager is. Making your window manager (and X) meaner with respect to CPU scheduling makes for a much more snappy environment when edge flipping or the like. Sure, it might take a sec for the mozilla windows in the background to finish redrawing when I flip to a new desktop, but in the meantime I can do my work without waiting around for them.

    The reason you don't want to make your WM meaner if you use it to launch programs is that then all the programs will also be equally mean.

    Decide on the Big Four applications of any X desktop. Text editor, web browser, file manager, and terminal emulator.

    Text editor:
    I can't possibly cover this holy war here. My personal preference is xemacs, which is a bit of a learning curve for new users from Windows, but well worth it in power in the long run. You may want something that meshes more with the rest of your chosen desktop environment.

    Web browser:
    Just because KDE uses Konqueror and GNOME uses galeon by default is no reason to stick with those. Of course, you also can use either Konq without KDE or galeon without GNOME. You're rolling your own environment!
    mozilla is now (after years of work) a good web browser. Big, still slow and still RAM-hungry, but usably so.
    dillo Lightweight, very fast, pretty stable, very screen-space efficient...I can't say enough good things about dillo. If you use dillo as your primary browser, be aware of the fact that it has fewer features than the large browsers, that it doesn't currently (without a patch) support SSL, that it uses a UNIXish config-file preferences interface, and that it doesn't lay out nested tables or wrap text around images the same way Mozilla does. I keep Mozilla around as a backup browser, but dillo is so freakishly fast that it's hard to want to use anything else.
    There are a few other browsers, but Konqueror, Mozilla, and dillo are (IMHO) the big GUI players on Linux. Amaya is a specialty browser, Opera (thanks to its MDI interface) doesn't seem to have caught on much in the Linux world, and Navigator 4.x is definitely on its way out the door.

    File manager:
    You may choose to simply use a command-line shell and the standard file utilities (cp, rm, ls) to do your file management -- I do, and I've tried hard to give other things a chance. But if you prefer to use a specalized GUI tool:
    Konqueror can be used, even if you aren't using KDE (you do, of course, need the KDE libraries installed). Faster than gecko (the engine in mozilla and galeon) and almost as standards compliant, Konqueror has a lot of fans.
    GMC is no longer being developed, but it's a reasonable lightweight interface.
    Nautilus, the current official GNOME file manager is big, slow, RAM-hungry, and pretty. Not sure how well Nautilus works outside of GNOME (given that Konqueror can work outside of KDE, I would expect this capability of Nautilus).
    ROX filer is a very fast little gtk file manager.
    There are a lot of file managers out there, so I won't list them all, especially as I'm happy with just bash and the POSIX tools.

    Terminal emulator:
    GNOME and KDE both come with terminal emulators -- gnome-terminal and Konsole. I'm not very impressed with either -- they're both very slow and aren't available apart from their associated desktop environment. Konsole supports tabbed terminals, which some people may like. Both of them are fairly easy to configure, and are suitable for newbies to work with.
    Multi Gnome Terminal extends gnome-terminal significantly with Konsole-style tabs and a set of other features. If you like gnome-terminal, you should probably consider using this instead.
    Eterm is a RAM-heavy terminal emulator that was designed to look nice. For all the tinting and blending it can do, reasonably fast.
    Aterm seems to be basically a less featureful, less memory-hungry Eterm-like terminal.
    xterm is the reasonably fast not-so-pretty fairly RAM-hungry terminal that's used all over the world.
    rxvt is easily my favorite terminal emulator. rxvt uses less RAM than anything else out there, and is incredibly fast. You can compile in only the features you want to use (which can, of course, also be disabled at runtime). Background images are supported, but emphasis is not much on eye candy. Very configurable. The biggest drawback is that configuration is through traditional UNIX methods, which may scare away some -- X resources, command line options, compile-time options.

    Whatever you do, choose a set of software that you like, and remember -- your desktop environment is based on Linux, which means it should composed of exactly the parts that you like most. Have fun!

  38. Re:Why the Gnome Foot ? by N0Nick · · Score: 1 · on AbiWord 1.0.1 Released

    See here.
    AbiWord is a part of the "Gnome Office" suit.

  39. Re: Save your bandwidth by Black+Parrot · · Score: 2 · on Klez, The Virus that Keeps on Giving


    > If you want a pretty windoze gui for doing the same thing, and free as in 'beer' / nagware, try Mailwasher [mailwasher.net]. The ability to bounce spam and delete virii from POP boxs before downloading, not to mention dickheads who send huge emails is very useful. It has saved me numerous times.

    Similarly, except free as in {beer,speech}, try Balsa. When I crank it up it connects to my IMAP server and lists my inbox without downloading anything. The list includes the number of lines and and whether or not the message has an attachment. I just ctrl-click all the trash and then ctrl-d to delete it without downloading it to my local trashcan.

    This has saved me a huge amount of annoyance since I started using it. Basically, if a message isn't from a friend and doesn't have a subject line that makes me want to read it, it never gets downloaded. (And no, "MAKE MONEY FAST" doesn't make me want to read it.)

  40. Hollywood did glorify the gnome project! by Cardhore · · Score: 2 · on SETI@Home Close to Half-Billionth Result

    I thought hollywood glorified the gnome project in that movie "Antitrust"...

  41. Re:suggested X changes by Guy+Harris · · Score: 2 · on XFree86 10 Years Old
    The idea is that Gdk provides a "draw a raised button-like rectangle here" call. At least I think it does.

    No, that's not what GDK provides; it knows nothing about "button-like", for example.

    See the GDK 2.x reference. It has calls to draw rectangles, but not "raised button-like rectangle[s]". It's GTK+ that knows all that fancy visual stuff.

  42. Confronting the KDE propoganda machine by Anonymous Coward · · Score: -1, Offtopic · on VoIP at $15 a Pop
    Confronting the KDE propaganda machine.

    The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel isnot the only thing the KDE project has copied! In this short article I will address some of the lies andFUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

    • Myth #1 - KDE is more integrated than GNOME

      The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

    • Myth #2 - KDE is easier to use

      Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

    • Myth #3 - KDE is more popular

      In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense.Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run atthe same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE atall.

      One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

    • Myth #4 - Konqueror is the best Linux browser

      Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and evensimple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

    • Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

      See also: Qt/TrollTech. This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jumpfor 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

      GNOME applications get much more testing in their 0.x stages and despite shorter development phases theymature and reach stable featureful release states much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is nounderstatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling stillfurther ahead.

      It's not only in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

      It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.

      Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

    • Myth #6 - KDE is faster and takes less memory than GNOME

      KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers(which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

      Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDEarchitecture to see the truth.

    • Myth #7 - GNOME development is slower. KDE releases faster.

      Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

    • Myth #8 - The Qt toolkit is cross-platform and yet takes advantage of each individual platform

      The Qt toolkit (the software at the heart of KDE) is supposedly a cross-platform toolkit allowing the luckydeveloper the opportunity to write Windows/Linux/Mac software all at once. And yet, among the magicalmythical claims made, the most nonsensical is that it makes applications which take advantage of thedistinct features of the different platforms. This is of course, nonsense. Qt is a bloated, slow layerthat is slapped over a native system's APIs in an attempt to make all the systems look alike. It no moretakes advantage of Linux/Windows/Mac than Java does - in fact it offers many of the disadvantages of Java with few of the advantages. If you have ever wondered why the KDE desktop looks so much like Windows... youneed look no further than Qt. Qt is a lowest common denominator toolkit, and that LCD is Windows - Trolltech's,the creator of Qt, real market.
    • Myth #9 - TrollTech is a friend of Free software

      To Be Written. Ideas: Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stoleothers' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt, and hence KDE. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare (3 licenses todeal with). Gradual migration of features belonging in KDE into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE an irrelevant launcher of Qt applications. Claims made that Qt is GPL, while true, hide the real truth. There cannot be a real fork of Qt for the KDE project: Core developers work for Trolltech; any fork would need to be full GPL and hence ban any closed-source apps from KDE altogether (all KDE apps must link with Qt); Any commerical licensees of Qt (non-GPL) would and could only follow TrollTech. KDE is stitched up good and proper.

    • Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

      To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-outand of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

  43. GNOME Usability Study by nrosier · · Score: 5, Interesting · on User Interfaces in Free Software

    Didn't the Gnome Usability study done by Sun cover a lot of the shortcomings of the current GUI? It showed that the GUI was indeed created by geeks for geeks.
    The report can be found here.

  44. Re:Please, enlighten us further... by L1nUx+h4x0r · · Score: 0 · on Revolution OS

    I know, I can't think of a single solitary application that's installed as a binary, easily.

  45. Re:Useability research by daeglin · · Score: 1 · on Learn About Ximian and Gnome From Nat Friedman

    Have you clicked the full report link? I think, a 52 site document (PDF version) is not something you dash off in a half hour.

    They had 12 different testers (all Windows experienced). It is realy more than a casual "grandma" test. But you are free to send them your own proposals and observations. Yes there are usability issues. To describe them is the first step to solve them.

  46. Re:Useability research by daeglin · · Score: 1 · on Learn About Ximian and Gnome From Nat Friedman

    Have you clicked the full report link? I think, a 52 site document (PDF version) is not something you dash off in a half hour.

    They had 12 different testers (all Windows experienced). It is realy more than a casual "grandma" test. But you are free to send them your own proposals and observations. Yes there are usability issues. To describe them is the first step to solve them.

  47. Re:Useability research by daeglin · · Score: 1 · on Learn About Ximian and Gnome From Nat Friedman

    Have you clicked the full report link? I think, a 52 site document (PDF version) is not something you dash off in a half hour.

    They had 12 different testers (all Windows experienced). It is realy more than a casual "grandma" test. But you are free to send them your own proposals and observations. Yes there are usability issues. To describe them is the first step to solve them.

  48. Re:Gnu ROPE question by Patrick · · Score: 2 · on Learn About Ximian and Gnome From Nat Friedman
    Did the project die?

    It never really lived. It appears that Nat's 1998 ALS talk oversold the project's readiness, and that GNU Rope was never finished or released. In a note to Alan Cox on the gnome-hackers list, Miguel summed up the status (as of October 2000) thus:

    Last I head Nat dumped all his patches on Richard Henderson, or was trying to dump them to him.

    Currently there is no set of tools that would match IRIX's pixie/cord tools which is what we would ideally want to see.

    --Patrick

  49. Re:Core Gnome technologies by ambrosius27 · · Score: 1 · on Learn About Ximian and Gnome From Nat Friedman

    Having lots of different modules makes compiling GNOME a real pain but gives developers more fine-grained control on the libraries they include in their applications. The GNOMErs made a decision to favor developers in this regard, figuring end-users would depend upon their distributions or upon Ximian's Red Carpet to handle the rest.

    That said, have you tried GARNOME? It makes compiling GNOME very easy, to the happiness of beta-testers everywhere. Cheers!

  50. Re:Ximian soul by hettb · · Score: 0 · on Learn About Ximian and Gnome From Nat Friedman

    Read this post. It is the same company, and companies are known to change their focus and mission statement, as necessary.