Slashdot Mirror

X-Windows is never going to cut it in the desktop world

Please explain why X-Windows won't cut it. I hear a lot of people bashing X, because X is supposed to be slow, tedious to program for, a memory hog, and a pain in the ass. However, I've noticed that my X desktop doesn't eat memory like the gluttenous pig it's being accused to be. I've noticed that it's really not that slow on a halfway decent machine (a P-200 was pretty responsive, even when using enlightenment with all bells and whistles). I've noticed that other APIs to do programming for proprietary windowing systems can be just as tedious and nervewrecking as Xlib/Motif/etc can be (gtk+ and QT are actually pretty good alternatives, but that should be pretty old news by now). A pain in the ass, I can't debate with that, but so are other windowing systems in different areas.

Why don't these software companies do what their supposed to do and actually program something.

Debian is not a software company, it's volunteer based

Linux will never make it to the desktop.

Perhaps we won't, perhaps we will... I've had hours of fruitless debates about this, and we've always come to that conclusion. Only time will tell. The apps aren't there yet, but getting there. The desktop isn't uniform enough, but Redhat is making the first attempt, with many others including debian.

the Linux community has to stop thinking like Sun, W3C and all these other monstrousities that crank out new ideas less frequently than LucasFilm does

I doubt that most of us think like Sun and w3c. Most kernel developers don't think like sun, and I think that w3c is overall a good thing (except for the patenting issues) because we need some standards. Oh, I don't mean that everyone should use XML for their new applications (goddess forbid), but at least HTML should be HTML and not some derived alphabetsoup with proprietairy extensions.

They need a revolution of thought that makes customers proud to stand behind their product.

How about freedom? That thought is still quite revolutionary to most people when it comes to source code.

If you're not happy with XFree, try to find an alternative... You'll find that you'll be switching back to X very quickly. But you can always contribute to one of those projects. Perhaps by programming, or perhaps by testing and sending bug reports or writing documentation. There won't be any good alternatives unless someone does some work on them.

Oh ho HO! International chat certainly is a problem in the Linux community, owing to many factors; not the least of which being that the developers of the major IM forces out there seem to largely be from ISO-8859-1 locales. Thus ISO-8859-1 works pretty well, and other, more ASCII-deviant (CJK) locales work with virtually no success.

The good news is that an answer is here! I've been on a crusade to make Gaim the penguin-pimpin'est international chat machine available, and it's really paying off! For the stable series of gaim (0.59.x, currently at 0.59.4 with 0.59.5 to be released possibly as I type this) (I just looked and 0.59.5 is out), if your locale is set correctly you should be able to chat in whatever language your little heart desires... (I have personally successfully used it with English and Japanese) as long as you aren't chatting over the AOL Instant Messenger service or the ICQ service, both of which use the Oscar protocol. However, MSN and Jabber, for instance, should be substantially correct.

The fabulous news is that the development version of gaim coming at us right now has first class i18n support on the whole gamut of protocols! With a timely move to Gtk+ 2.0 and the Pango text formatting system, Gaim now has international text formatting second to none in the OSS community and hardly rivalled in the commercial world. Images like this shot of gaim displaying Japanese, Russian, and English simultaneously display what I'm talking about very nicely. Not only can we do non-English text, thanks to UTF-8 we can do all of the modern languages of the world simultaneously. In addition, support for internationalization on the troublesome Oscar (AIM and ICQ) protocol has been added and is coming along very nicely.

In short, look for the next major release of gaim to clear up these issues in a big way. For those hardy souls wanting to test the code that's currently in CVS, please note that it is NOT currently complete, and isses that you have are most likely transient.

Also, please be aware that your locale MUST be set correctly for internationalized programs to work the way you expect. Programs that only deal with your system can be more forgiving, but programs that communicate over the network absolutely must know more about your locale, including your character set. If the output of your 'locale' command lists LC_CTYPE as, for instance, "C", it's no wonder i18n isn't working! Set your LANG or LC_CTYPE correctly for your language (en_US for English with ISO-8859-1, es_ES or es_MX for Spanish, pt_PT or pt_BR for Portuguese, ja_JP for Japanese, zh_CN for Chinese, etc.) and you might see general i18n support improving dramatically.

This is my humble opinion on how to design a good interface:

1. Define your 'document', i.e. the data you're going to work with as a set of classes.

2. Define a user interface that lets you access these classes (their methods and properties) when they are relevant.

3. Make sure to analyse what functions that are going to be used most, make them one, or at worst two-click commands.

There are a number of ways of showing information to the user. I list a few good ways here, no special order:

* Show global information in a status area that is globally (read always) visible.

* Show local information in a special area, so that the options for a line and a box appear in the same place even though they may contain different options.

* Provide two interfaces for complex operations, one wizard (with an 'don't show this again'-option) and one dialog (possibly with tabs) allowing the advanced user to pick the items that he/she needs.

* Use context menus (right clickable or automatically appearing in the menu bar).

* Make frequently used commands (let the user choose, but supply an intelligent default) on a toolbar. Let these buttons simply trigger a standard command, i.e. no extra code here!

If you have done your document classes right it shouldn't be too hard to add all the inteface classes around them. Perhaps you will have to handle some states in a view, etc. But otherwise it should just be a matter of wrapping the document into something UI like.

As for tools I must say avoid MFC (i mean *run* if you hear it mentioned, it is not a serious option). The same applies to Borland's alternative (I cannot remember what it is called). If you are forced to write in C, use GTK and perhaps Gnome, but be prepared to write OO code in C, and a huge dependency problem if you use Gnome. Also, portability is not always what it aught to be. If you have the freedom to use C++, use Qt. It is portable, beautifully designed and works flawlessly.

I must also say that the implementation 'method' I presented above fits very nicely into Qt. I think (haven't tried any big projects with it yet) that it is quite easy to do in GTK too.

On a side note, I've used wxWindows in Python and I must say I was definitely impressed how one wxWindows Python script can display identical windows on Mac OS, Linux, and Win32s. We need more of this cross-platform compatibility.

Tim Janik came out with a utility called Gerd a while back that lets you script GTK+ applications. It appears to have been abandoned at version 0.0.3, however.

Huh? How is Troll Tech evil? People wanted QT under the GPL, and lo and behold, they released it under the GPL. Seems like a nice bunch of folks to me.

Not quite. People really wanted it under the LGPL or BSD licenses, just like GTK+, FLTK, FOX, wxWindows, etc.

One of the problems (unless you follow Stallman's manifesto) is that although the Free version is free for open-source, their commercial licenses are structured so that if at any point in time your software project is touched by a free (free, non-commercial, acedemic, etc) version of Qt, you may never at any later time buy a commercial license and release your software commercially.

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.

• Add a class, deriving from this widget class.
• Add a method to this class.
• Override this method in this class.

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.

• Myth: KDE is more integrated than GNOME
  
  Reality: 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's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac.

• Myth: KDE is easier to use
  
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. What about application (see GNOME apps later) 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 very tricky cross-platform and potentially risky system configuration operations - KDE offers a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim 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 on a zealot-ridden site can reduce the result to a running joke. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system - and indeed, can co-exist except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead. Both Hewlett- Packard and Sun Microsystems have committed to using GNOME as the desktop for their Unix systems. This ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME effort 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: Konqueror is the best Linux browser
  
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror is a fine piece of software - it's authors deserve plently of praise - it is, however, quite unreliable and lax in its support of basic web standards compared to either Mozilla or Opera . It is also extremely slow - slower than the latest incarnations of the GNOME Nautilus filemanager/browser.

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  
  Reality: See also: Qt/TrollTech. Easily 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 wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly: 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 , Anjuta . All of these packages ooze quality, far outclass and are, at least, 18 months ahead of their KDE/Qt counterparts. It's not only in the area of user applications that GNOME is lightyears ahead, with the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo ), media (Gstreamer ), internationalisation (pango ). As a developement platform, GNOME 2.x is, frankly, years ahead of KDE. And what's more, it is not tied to a lowest common denominator cross-platform bloat-fest like Qt. Yet despite all this, we are still fed the lie that Qt and C++ makes development easier. Judge for yourself.

• Myth: KDE is faster and/or takes less memory than GNOME
  
  Reality: KDE is written in C++. While this is not necessarily a bad thing, it is when the programmers do not know enough to avoid certain pitfalls that can plague software projects. Stupid use of ++/-- with C++ objects; masses of unnecessary allocations and deallocations of memory, and the most cretinous of all, 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) to see the problem inherent in the KDE architecture and basic design.

• Myth: GNOME development is slower. KDE releases faster.
  
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the consequent problems with libraries. It 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. Occasional releases of the entire GNOME system are done, and that's when the GNOME version number is bumped (currently it is 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 and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  
  Reality: Qt started out as non-Free. KDE developers knew this violated the GPL and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Labyrinthine licensing nightmare.

• Myth: Most good GNOME apps are actually GTK applications.
  
  Reality: Most KDE apps, such as those from The Kompany are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

• Myth: KDE is attractive/GNOME/GTK is ugly
  
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

• Myth: KDE is more integrated than GNOME
  Reality: 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's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: 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 (indeed, 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 [ximian.com] 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 very 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: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim 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. Indeed, 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 the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] 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: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished 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 [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. 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 [koffice.org] 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 [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the 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 lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's 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.

  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: KDE is faster and takes less memory than GNOME
  Reality: 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) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE 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 see 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: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' 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. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features 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 irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

and Galeon is the lightest Gecko based browser that I can find.
Well, seems like you need to find SkipStone, then. It's the Gecko engine packaged up using only GTK+ widgets, no GNOME. It's pretty nice.

GTK:
GTK

QT:
QT
Excellent QT Tutorial

wxWindows:
wxWindows
wxPython

Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL

Others:
FLTK
Fox Toolkit

Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page

I needed this list for my own use. Maybe it will be of interest to you.

GTK

QT


Post Comment Lameness filter encountered. Post aborted! Reason: Don't use so many caps. It's like YELLING.

• Sheer complexity of compiler implementation, which leads to fragility. Remember, the compiler must translate each compilation unit (a source file and headers it includes) into an object file, which has rather primitive means to link to other modules. This is OK for C, but is too tight for C++. Basically, all components of a program and the libraries it uses must be compiled by the same compiler, the same version of it, with the same set of 'runtime-sensitive' flags e.g. exception support. I take part in development of a high-profile Linux distro and I know what a headache C++ libs are.
  
  
• The C++ Programmer's Disease, when one leverages all the advanced C++ features for easyness's sake, but has no idea on what repercussions they have in the real world of cold machine code. Needles to say how these things are affected by quality of design.
  

Yes, there are lot of areas where C++ fails, because it wasn't designed to address their requirements. In fact, it fails everywhere except small COM/CORBA/whatever components, generation of boilerplate code (the idea behind ATL is neat), and huge monolithic software systems where rapid development is on top of the list. And we on /. know how the latter sucks, don't we?

Perhaps in this case the problem is not the language, but the programmer.

Totally agree here, except with "the language" substituted for "the language that fits the job", and "the programmer" with "one that moans about how he misses the features of his favorite programming language". The Real Programmers don't hesitate doing OO stuff in C, and doing it elegantly.

why not GTK/GLIB? 1.3.x is coming along quiet nicely... native windows/*nix ports... developed by the community, for the community ..not by a single company sure redhat support GTK+/Gnome, but hey dont own it.Its always been under LGPL/GPL, none of this QPL-hybrid shit.

Trolltech still fully control QT on non-linux platforms...why cant QT be open on every platform?

I'll never trust trolltech.

I myself am working on software for Traveller. Called travtrack, it is in the middling stages. It's very cool, using gtk+ and glib for data structures, classes, inheritance &c. and guile for its scripting language. Ideally, I'd like it to someday be the emacs of interstellar science-fiction RPGs.

Right now it's surprisingly far along, and is doing fairly well on the SourceForge ratings. It's just me working on it, but I'm hoping that once I get release 1.0 of both travtrack (the actual galaxy-tracking software) and travlib (the library which implements Traveller objects) more developers will pitch in.

Traveller's very, very far from dead.

http://www.gtk.org/faq/

http://www.gtk.org/tutorial/

http://www.gtk.org/api/

All of which are referenced in the README that comes with gtk+. You're welcome.

http://www.gtk.org/faq/

http://www.gtk.org/tutorial/

http://www.gtk.org/api/

All of which are referenced in the README that comes with gtk+. You're welcome.

http://www.gtk.org/faq/

http://www.gtk.org/tutorial/

http://www.gtk.org/api/

All of which are referenced in the README that comes with gtk+. You're welcome.

Gtk, on the left hand side in a table called "Documentation".

Cool thank you

P.S. This guy sounded like a troll.

Well it just seems to me that if you are going talk about good documentation you should give a link to it. Otherwise people might think you are just talking out of your ass.

Gtk, on the left hand side in a table called "Documentation". P.S. This guy sounded like a troll.

QT too slow and unresponsive for you, too? I found an easy fix.

Well, now that gtk and gnome are around, X apps are starting to look more "coherent" to me. This is probably the same for the KDE side of things, but I have never used it.

The fact that there is more than one popular GUI toolkit available means there are still going to be strange looking apps out there, but it is definitely getting better than the "everyone designing their own GUI using Xt" days..

> I respect your opinion, but it doesn't really matter whether or not you like C++ if its is one of only two options for Linux desktop programming.

FYI, if you ease on over to gtk.org and look at their bindings page, you'll see that in addition to C there are 4 other languages with bindings described as "complete", plus a number of others that don't merit that flag yet.

--

I don't understand why the Linux community shuns C++.

If you ask me, GTK being based on C is a critical weakness.

C++, if used correctly, removes complexity.

Language bindings are actually a good argument for writing GTK+ in C, since just about every language can call C libraries, but calling C++ libraries is usually considerably painful. This approach also shines for languages like Python and Scheme, whose flexible object model and typing are a good fit to the GTK+ object model.

It's already happening. You just have the parties reversed.

Qt/Windows and Free are inherently incompatible. Since the only version of Qt/Windows is non-Free, it can't be used to build Free software on Windows. In this case, Qt is a non-Free, third-party library. TrollTech leaves the cop out that you can use Qt/Free with X11 libraries and an X server for Windows. Why this is absurd is left as an exercise to the reader.

GTK+, on the other hand, is licensed under the LGPL. And that means all platforms, including proprietary ones, such as Windows, BeOS, and Mac OS X.

That killer app you speak of will get here, but as a Gnome app, not KDE.

We're not scare-mongering/This is really happening - Radiohead

It's already happening. You just have the parties reversed.

Qt/Windows and Free are inherently incompatible. Since the only version of Qt/Windows is non-Free, it can't be used to build Free software on Windows. In this case, Qt is a non-Free, third-party library. TrollTech leaves the cop out that you can use Qt/Free with X11 libraries and an X server for Windows. Why this is absurd is left as an exercise to the reader.

GTK+, on the other hand, is licensed under the LGPL. And that means all platforms, including proprietary ones, such as Windows, BeOS, and Mac OS X.

That killer app you speak of will get here, but as a Gnome app, not KDE.

We're not scare-mongering/This is really happening - Radiohead

An operating system is not only the kernel and a bunch of device drivers! We didn't even start the most important project of them all: consolidating our manpower and our technologies. We could really use a component object model. The good news is: we have that technology. The bad news is we are working on more than one.. XPCom part of the Mozilla web browser project and ORBit part of the Gnome Desktop project. Speaking of desktops, like Doug said, we are working on two competing projects, Gnome and KDE. We already have all the technologies Doug thinks put Microsoft ahead in the game. Mainframe / AS400 connectivity? Linux-SNA. A kick-ass web browser? Mozilla vs. Internet Explorer. Word processor, spread-sheet, Business presentations? Star-Office. I could go on and on but I guess you get the picture. What we have to do now is to consolidate all that into a coherent system.. I want to be able to manipulate Star-Office spread-sheets using a system-wide scripting language (how about perl? python?..?).. I want to be able to embed that spread-sheet into any application, not only into Star-Office's word processor (XPCom? ORBit?) I want to be able to use the same printer driver from Star-Office and any other application on the system (anybody working on a printing subsystem for X? Or do we put it into GTK's GDK?).. There's still a lot of work for us to do before we can really kick their asses on the desktop. I'm looking forward to both.

I think doing cross-platform development is of critical importance both to the software developer and the public. Find out why at:

• Freeing the Developer from OS Vendor Shackles

You can find a list of many application frameworks in several languages, many of which are cross-platform, and many of which are free or open source, at the GUI Toolkit, Framework page.

Mike

I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.

You mean GTK+ on Win32 like offered here which is linked from the GTK+ webpage?

>>Back on topic: will qt free edition (or xfree86)
>>ever be ported to windows 9x?
>Probably not in this lifetime.

YM "not by Trolltech." Qt Free is GPL and can be ported. XFree has already been ported to NT, and there's a good shareware X server from Microimages called MI/X. I don't think it would be that hard to get Qt Free running under Win32, or does Qt have some technical issues I'm not aware of that one of its biggest competitors that has been ported to Win32 doesn't?

"write one, run anywhere" widget set

Java Swing, Tcl/Tk, GTK+, Allegro... The field is already crowded.

>>Back on topic: will qt free edition (or xfree86)
>>ever be ported to windows 9x?
>Probably not in this lifetime.

YM "not by Trolltech." Qt Free is GPL and can be ported. XFree has already been ported to NT, and there's a good shareware X server from Microimages called MI/X. I don't think it would be that hard to get Qt Free running under Win32, or does Qt have some technical issues I'm not aware of that one of its biggest competitors that has been ported to Win32 doesn't?

"write one, run anywhere" widget set

Java Swing, Tcl/Tk, GTK+, Allegro... The field is already crowded.

GTK is a GUI toolkit for The X Window System (also ported to Win32 I believe). The homepage is gtk.org

Apparently, PHP-GTK gets by with linking to version 4 because GTK is released under the LGPL.

I'm surprised Richard Stallman hasn't released a blistering condemnation of the project yet.

It has to work on Windows...

Apple has announced it has no plans to support a JVM later than 1.1.8 on the classic Mac OS so you can't use all those great collection classes in Java 1.2 and be cross platform! (See Apple's Java Developer page and scroll down to where it says "Mac OS Classic Java".)

Use a cross-platform application framework. That way you can program on Linux, Mac, BeOS, Windows or maybe even QNX and deliver for all those schoolkids running Windows ME on their parents' PC.

One such framework, for C++, is ZooLib. There are many others, as you can see from The GUI Toolkit, Framework Page.

Read about why it's important to write cross-platform code.

I'm most familiar with ZooLib, because I've been working with it on the products I write for my clients, and I helped ZooLib author Andy Green prepare it for open source release late last year under the MIT License.

ZooLib offers all of the following implemented as C++ classes:

• Multithreading, with cross-platform C++ thread classes and various kinds of locks (simple mutexes, reader/writer locks) - multithreading is important for something like a servent. For systems like the Mac OS that don't have preemptive threads it has a handrolled thread scheduler.
• GUI, with a uniquely flexible layout method. The widgets are rendered by platform appropriate renderers, and you can make custom widgets. There's a renderer that will call through to the Appearance Manager on the Mac OS, if it's running.
• platform-independent TCP networking, it's implemented in terms of sockets on Linux, WinSock on Windows, sockets on BeOS and MacTCP on Mac OS. I think Open Transport may be working too on the Mac, I'm not sure - but on all platforms you use the same C++ classes for your networking with no platform-specific client code needed.
• Thread-safe reference counted smart pointers, for quick, efficient memory management that's free of leaks.
• Extensive debugging support - assertions in core components and a debugging memory manager, handy macros for assertions and the like
• Single-file database format with C++ interface. Create ZDatabase objects with ZTables in them. Much zippier than SQL and more pleasing to the object-oriented soul.
• File objects - you instantiate a ZFile object from a ZFileRef object, then use its Open, Close, Read and Write methods
• Platform-specific file open and save dialogs with an API that's consistent with the rest of ZooLib. Filter by filetype on the Mac or filename three letter extension on windows. While ZooLib is cross-platform, it breaks out into platform specific code in cases like this where it's appropriate, in a way that's considered entirely sacreligious by the Java community.
• Streams that can be chained to provide filtering, somewhat like the iostreams classes in the C++ standard library but more appropriate for use with binary data. This is how you typically read or write to a file or network connection.
• Handy preprocessor macros to deal with platform specific code or selecting options like debug builds.
• Offscreen graphics buffers that may be manipulated directly via pointers or accessed in a manner that is transparent to the bit depth via GetPixel and SetPixel calls. All platforms have the same API that provide a wrapper around platform bitmap buffers. I believe there's a purely homegrown in-memory implementation, plus platform implementations bounds to the native GUI layer like GWorlds on the Mac OS.

ZooLib 0.81 is known to build with MetroWerks CodeWarrior on Windows and Mac OS, gcc on Linux, and gcc on BeOS for Pentium.

If you use CodeWarrior you can cross-compile and cross-debug; check out Thursby Software for some filesharing solutions that work well for this. (Tip - on Windows, select the "MacBinarize" post-linker in the target linker prefs when building a Mac target - you also need to derez all your resource files and include them as Rez text source).

While it should ultimately work, there are known build problems with BSD, CodeWarrior for BeOS PowerPC and Visual C++ on Windows. These are all being worked on and full support for all these platforms is expected before long.

Other cross-platform frameworks I'd like to note are:

• The Adaptive Communications Environment for cross-platform networking
• GTK - yes, that's right, GTK! but you must forgo using XLib calls and POSIX calls that are not in the ANSI C Standard Library
• The Netscape Portable Runtime for the non-GUI aspects of cross-platform development
• The Mozilla XPToolkit for cross-platform GUI
• Mozilla Netlib for network and file stream access
• Mozilla XPInstall for cross-platform installation, packaging and updating.
• Also check out AbiWord, a great cross-platform WYSIWYG word processor that's open source, with an open file format. As far as I know the only product coded in AbiWord's XP framework is AbiWord itself, but it's worth looking into for another look at how people architect these things.

People often mistake these problems for valid arguments that one should not do cross-platform development, or perhaps not render your own widgets when doing so but depend on platform specific ones (like AWT vs. Swing), but I think the lightweight, well architected, efficient and easy to use ZooLib answers those arguments very eloquently.

Help me teach the Free Software community to write quality code.

Mike

Applixware Office is not free software. It is a traditional closed-source, proprietary software product that just happens to run on Linux and use GTK+ as it's widget set.

So, what "proof of a broken business model" was that again?

Gtk+ is one of the finest examples of software engineering I've ever seen. By extension, I'm including glib. Check out these documents for most of my reasoning:

The Gtk+ FAQ
The gobject reference
Tic Tac Toe in Gtk+

Gtk+ is one of the finest examples of software engineering I've ever seen. By extension, I'm including glib. Check out these documents for most of my reasoning:

The Gtk+ FAQ
The gobject reference
Tic Tac Toe in Gtk+

But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).

For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.

I think the Win32 port, which antedates the frame buffer port, was also done largely at the GDK layer.

There are people working on a BeOS version of GTK+ - there's a GTK+ for BeOS page on the GTK+ Web site, and somebody's been sending patches to the gtk-devel mailing list.

But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).

For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.

I think the Win32 port, which antedates the frame buffer port, was also done largely at the GDK layer.

There are people working on a BeOS version of GTK+ - there's a GTK+ for BeOS page on the GTK+ Web site, and somebody's been sending patches to the gtk-devel mailing list.

You tell me how this code is easier to read than this code.

I show these examples to a lot of people (mostly casual coders) and not one tells me that Microsoft's official Hungarian style is easier to read.

I will admit that a simple prefix makes things easier to read, but stuff like rgbsyHash is garbage.

Personally I think the native GTK+ port to win32 is cooler than the CYGWIN one. You don't need an X server. Granted GNOME would be a huge task to port since you don't have the POSIXness. Check out the Gimp and GTK+ ported to Win32.

For example, several changes are required to port 1.0 programs to 1.2. If you've checked out the 1.3 version you'll find that it's incompatible with just about everything. (Although I think most of that is just to keep clueless people from complaining when app foo doesn't compile.)

The GTK developers try to maintain a minimal number of changes required for existing programs, but they're not afraid to make backwardsly incompatible changes if they feel it will significantly improve the library.

Imagine that in a comercial program! Hardly anyone in the Wintel camp is willing to do that. In practice, I can't see why (other than because of laziness) making backwardsly incompatible changes should be difficult in a one-vendor product such as gtk as long as they provide an emulation library for backwards compatiblity. Documenting the programming interface changes is also essential.

The problem with a multi-vendor standard such as Java is that any changes to the standard have to be implemented not just once but in every provider. You have the social issue of ensuring that all providers do it and the technical issue of ensuring that they do it right. (Java is somewhat less disadvantaged than many "standards" on this point.) This is enough to discourage many worthy improvements.

(from the spoilsport dept.)

Large caveat: This applies only to QT free edition; that is, QT/Unix. Those who wish to develop cross-platform applications will still have to look elsewhere for their toolkit.

Note: Don't bother replying with flames about GTK+ sucking for Windoze. At least the port exists, is free software, and has the chance to improve eventually.

--

[Missing symlinks] are causing far more difficulty than the fact that X and Win32 GDI are completely different.

Tiddly-day, especially when one considers that the GIMP toolkit (GTK+ & Co.), allows one application to be written for X and Win32 with minimal OS-specific code.

GTK widgets are implemented in an object oriented fashion. However, they are implemented in standard C. This greatly improves portability and stability over using current generation C++ compilers; however, it does mean that the widget writer has to pay attention to some of the implementation details. The information common to all instances of one class of widgets (e.g., to all Button widgets) is stored in the class structure.

Notice too that the if you use the GTK+ widget library, you have to pay attention to some of the implementation details. In a object-oriented language, I do not have to pay attention to any implementation details. This save me time (and money) when I build my program.

IMHO - forcing C into an object-oriented paradigm is a waste of time because you end up writing so much code to support it, rather than letting the language specification deal with the implementation details. Given this point, I wonder if an object-oriented C is actually object-oriented at all, since you have to write a library to support your "version" of object-oriented. In this case, there is no guarantee (via language specification) that the object-oriented C library that I write tommorrow will work with your object-oriented C library. This is the point of object-oriented languages such as Java or C++. So, if you want objects, I think you are better off to use an object-oriented language.

The C language cannot solve every programming problem in a reasonable manner. IMHO, it is not reasonable to reinvent an "object-oriented" library that is not supported by the language specification.

Later

--

GLib/Gtk+/GNOME's use of C is actually pretty amazing in my opinion (and yes, I've used C++, Java, Python, ... as well, so I'm not ignorant in these issues). It's quite a pretty language when used well.

- Tom

What are the prerequisites for building the Open Inventor software? Linux (glibc 2.x) or IRIX, X11R6, Motif, C++ compiler and OpenGL.

Does anyone know how closely tied it is to Motif? Is it the whole thing, or just a small part? How hard would it be to use it in, say, a GTK+ program without dragging Motif (or even Lesstif) along with it?

(I would download it myself and take a look, but their server seems to be /.'ed.)

Try this.

After you finish that you can use the reference manual..

Similarly, if you want to learn how to use Perl, try typing "man perl."

Granted, there are occasions where you want to buy yourself a book. But the book to buy is NOT going to be titled "Teach yourself (well documented system) in (N) (days|steps|lessons)."

Try this.

After you finish that you can use the reference manual..

Similarly, if you want to learn how to use Perl, try typing "man perl."

Granted, there are occasions where you want to buy yourself a book. But the book to buy is NOT going to be titled "Teach yourself (well documented system) in (N) (days|steps|lessons)."