C++ gets a lot of antagonism from Gnome people. I've seen it many times.
I have to admit, I've never seen it and I follow Gnome (and to a slightly lesser extent KDE) closely. I see far more anti-C antagonism from the KDE/Qt crowd than anti-C++ antagonism from Gnome/GTK. In fact the GTK developers have even said that if you use GTK for a big project you probably shouldn't be using C.
Of course, C++ bindings are available for GTK. But who will use them if there is an a priori hatred for the language? Do you see my point now?
No, I don't. In fact GTKmm is used plenty - often by in house commercial projects. See the gtk.org success stories - many of them are based on GTKmm. I've never seen people flaming GTKmm because it's C++, in fact.
A huge issue is generic programming. Few people understand the boon of the STL until they use it. And home-grown generic templates are unbelievably useful as well.
Templates have costs and they have benefits, same as anything else. The costs are obvious - fewer people understand them, and being basically a textual hack when they go wrong the error messages have to be seen to be believed. The benefits can sometimes (often, perhaps) outweigh those costs.
I can't specialise on structures written in C, a real strength of KDE/Qt.
I really think you should check out GObject. It's a light year from being just "structures in C". In particular GObject has things signals and reflection. It was designed with object orientation in mind, and as such wrappers like GTKmm can do a good job.
Sorry. GTK is used in VMWare, and so far as I know, that's the only commercial app on earth that uses it
Then I'm afraid you are seriously misinformed and I see no reason to take you seriously. See the gtk.org success stories page, they are almost entirely commercial/proprietary software developers.
I have seen it happen many times - people who are scared by OOP, defensive about their lack of knowledge, and maintaining that C is perfect for everything, when Python, Java, or C++ are better fits.
I hope that comment isn't targetted at me. I've written plenty of OOP code in my time, in a variety of languages. I'm certainly not "scared" of it. I've written bindings from Delphi (which has a pretty clean object model) to Python. I've written Java class frameworks. I've implemented parts of COM (though whether that's object oriented is highly arguable). Object models are in interest of mine - I can argue with you about the merits of CORBA vs GObject vs [D]COM vs.NET vs native C++ all day.
What I am pointing out is that your blanket assertion that anybody who doesn't use C++ or Qt is "irrational and emotional" is pure zealotry - the real world is simply not that black and white. Why do you think so much software is written in Visual Basic? Because of its merits as a language? I think not.
No offense, but I get the feeling you write code as a hobby, not for a living. You have all the time in the world to plink away at your little projects. I don't want to belittle your efforts, but please get real.
Then your feelings are as incorrect as your beliefs. I've worked for my countries Ministry of Defence (Java, C, XML and relational databases, webapp development), I've contracted (Delphi) and I've been paid freelance to do free software. I've worked the span from education software for preschool kids to reverse engineering DCOM. I would have done more but I'm 19 and simply haven't had the time.
In the case of much Linux software development, C is a popular choice because lots of people are very familiar with it, and that's more valuable than being able to play with functors. If you want to of course, GTKmm lets you do that: the interfaces to (for instance) the tree view are designed to strongly resemble the STL.
All the SuSE versions I have ever used included XMMS, which depends on GTK 1.2, which depends on Glib 1.2 - I have no idea if modern SuSE installs XMMS by default or not but I never asked for it specifically.
Well, a lot of what you posted is bogus (resize performance is mostly due to Xrender and WM asynchronity - try GTK on Win32 to see what I mean), but I feel obliged to point out that a lot of what you're seeing is functionality that was elsewhere (like in libgnome or whatever) being moved to where it should actually be, like in the toolkit.
Which is better - to have one standard implementation in the toolkit that everything uses, or to relentlessly duplicate stuff from the toolkit in an enormous set of libraries and call it a desktop framework?
KDE duplicates so much stuff from Qt, that Qt-only apps feel entirely foreign. It wasn't that long ago that they even started sharing themes! Qt programs have different dialog boxes, different toolbars, often different icons (!) and so on.
So for instance, take the "combo box widget". The old GTK one works, but it has a few shortcomings that people wanted to address. The KDE way would have been to either subclass it or create an entirely new replacement but that started with a K and stick it in KDE libs. The GTK way is to fix GTK, so all apps benefit, not just those that decided to make the all-or-nothing choice that is KDE vs Qt.
So to say "KDE already has this" is disingenuous. In many cases, so did Gnome, but the code is actually being moved to where it belongs (and being made nicer in the process).
Very, very nice work. But the obvious technical merits of KDE aren't enough to convince those who feel irrational and emotional about two things: Qt's "corporate" status, and a visceral hatred for C++.
What, so the reason people don't use Qt is because they are irrational and emotional? Let me remind you that C++ users can always use GTKmm which is arguably more "C++" than Qt will ever be.
Let me explain to you why the autopackage project has a very nice GTK2 based front end, and no KDE or Qt frontend. NB: plenty of people have offered to work on one, including core KDE hackers. We never saw any code. Make of that what you will.
We chose to use GTK from C because:
- C is a simple language that both me and Hongli (the other principle author of it) knew well. I've done plenty of OO programming in Delphi and Java before but only a little C++. The greater featureset of C++, in this case simply wasn't worth the hassle of ensuring we both knew it well, and weren't churning out constructs that the other couldn't understand.
It also increased dramatically the number of people that could work on it. Surprising though it may be, not everybody (especially in the unix world) knows C++.
- C has a stable ABI. For a program that is supposed to work anywhere without recompilation this is a big deal. That won't be an issue in a few years when gcc 2.95 is but a distant memory, but at the moment it is.
- It required no bindings. You can, of course, use C++ with GTK by using the rather spiffy GTKmm which gives you STL and a C++ish API so that other than a few minor oddies you'd never know the underlying toolkit was written in C, but this is an extra dependency, the cost of which was simply not worth it.
I look at the Gnome source code and shudder. It just reminds me so much of writing GUI code for Windows 3.1 and 95 (yes, I've done that).
If you're going to compare modern GTK to Win32 then all I can say is that you either haven't actually done any GTK programming or you haven't done any Win32 programming. I've done plenty of both and I can tell you that GTK is about a million light years away from Win32. The API is sane, consistant, and the toolkit is a powerful one.
Now let me tell you what I don't get.
I see people bitching (mostly ignorantly) about GTK, Gnome, C, whatever and praising the shining pearls of light that is KDE and Qt, yet the fact is that GTK is way more popular.
No, really, it is. I have no Qt or KDE apps on my desktop at any point these days. That's not because I don't like Qt or KDE - I do - but the fact is that I don't choose apps based on what toolkit they use but on merit. I use Firebird (XUL), emacs CVS (a mixture of raw Xlib and gtk2 these days), irssi (ncurses), Pan (raw GTK) and so on.
Yet, I once read a KDE developer claim that Yes! It's true! He had spent a whole month without glib installed on his system - he wanted to prove it was possible to do it, and well done he did. But if people have to do macho time trials to prove they can do without something - isn't this a hint?
I could be cynical and say that GTK is more popular because the people using it are busy getting shit done in whatever language lets them work most effectively (c, python, c++, whatever) instead of trolling about the superiority of Qt and C++ on Slashdot, but I won't. I'll let readers make up their own minds. I use what works for me.
Is it the output of a disassembler cobbled back together into C?
Yeah, I think this almost certainly is. Huge amounts of bit manipulation, lots of magic numbers, meaningless variable names. No type safety? No comments?
I've seen code like this before, when people have disassembled Windows DLLs back into C then tried to submit it to Wine.
I'd say Jon is treading on very slippery slopes indeed with this code. It might be possible to show that it's been simply generated from the original code which is almost certainly copyright violation - laws against that certainly exist in Norway.
Frankly, looking at the code, I think he simply found the relevant part of iTunes/Quicktime with a debugger and converted the relevant machine language straight into C with no major adjustments.
If true that'd be a pretty serious accusation. Reverse engineering is allowed under most western laws - copyright infringement is not. Translating from assembly back to C simply changes the form, not the content of a work and iirc this is simply not legal.
Of course, it's hard to prove. Maybe too hard. But if Jon has made heavy use of dissasembled code he could be in for a rough ride.
No, you need the iTunes client to play any files you buy from the iTunes store. And No, it doesn't (yet) work under Wine or CrossoverOffice.
Right. People make a lot of noise about wanting iTunes[MS] on Linux, but the fact is we've had zero people actually trying to make it work on Wine. When it first came out there were a few attempts to run it by end users, but so far nobody has sat down and hacked out the code necessary to make it work.
This tells me that probably the number of people who *really* care about this is reasonably small, they just make a lot of noise. Otherwise out of all those people who wanted iTMS, one or two of them would have sat down and hacked code.
Is anybody going to prove me wrong? I'm happy to give some tips, you know. You might want to start with the installer: it requires an unusual form of COM activation in order to start MSI (service-based). We don't implement this in Wine yet, but it wouldn't be hard to add.
The fact is that if you use non-Free software, then you are beholden to the whims of someone else.
This is true of many things, not just software. Yes, if you use a service or product that can only be supplied by somebody else then you might get screwed. This is not great.
One solution (the most common one) is simply to be careful in whom you trust and who you don't. The solution RMS advocates is that nobody should ever place themselves in a situation where they could possibly be screwed - and he preaches this regardless of how practical it might be in any situation.
Remember, this is the guy who won't actually recommend any installable version of the GNU system (iow Linux) because none of them - not even Debian or Red Hat which don't include any non-free software by default - live up to his levels of purity.
My objection to Stallmans stance is not so much that I think he's wrong (a lot of what he says is valid) but that he shuns people if they dare use or recommend even one piece of proprietary software - in effect he wants people to use free software so badly he's happy to withhold information from them to "encourage them to make the right choice".
For instance, he won't name Ximian Connector because it might encourage people to use non-free software: this is a fundamentally condescending idea in my view, as it assumes that the listener could not make up their own mind based on their own priorities.
Or any of the other stories on Slashdot where a closed-source company lures users and developers with gratis copies of their new, shiny product - and then changes licensing terms once everyone's hooked?
One legal point - you can't retroactively change the license on a piece of software, as far as I'm aware. Sure, you can change the license on future releases if you own the copyright on that work, but this is as true for free software as anything else, so simply being GPLd does not mean you won't get screwed by dubious license clauses in future versions, it means you could fork the last acceptable version and use that instead.
This is the problem with RMS - he is too black and white.
If you have read his writings, he has fairly convincingly argued from first principles that software should be free. I, and many others, have read this and been inspired, because the world he ultimately wants to live in is about co-operation and sharing.
However, RMS often leaves people behind with his extreme on/off view. This sentance is pivotal:
Users cannot be free while using a non-free program
This is seriously distorting his already bent definition of "free". Freedom, as he defines it, can be applied to software (and with a bit of work books, music etc) and while you might argue with the word used it's a useful concept to have.
Here though, he applies the word free to users, and this is a different thing entirely. Worse, he asserts that all it takes is one piece of non-free software to spoil his utopian dream.
I think a lot of people like the idea of free software, but we're willing to accept compromise. It's not an all or nothing proposition. Free software have inherantly good vibes because we're not imposing arbitrary limitations on what people can do with what we made (which is ultimately beneficial) but it's not like I'm a slave to the machine because I use the NVidia video drivers.
Yeah, I'd like to have free drivers, but Alan Cox himself has said he cannot think of a way to justify NVidia freeing their code - their fears of what would happen to their business if they did that are justified, he thinks. That's good enough for me. In this case, it just isn't practical. I don't like it, but that's life.
That feature has been discussed a few times by the Gnome team I think, but the general consensus is that nobody cares enough to actually implement it. You can change the colours in GTK, but there is no UI for it because the theme picking stuff is already complex enough without loads of stuff for "color themes" as well.
Personally I don't find it to be an issue, but whatever floats your boat....
Installing stuff together isn't the same as linking them together. Of course GTK can be used at the same time as proprietary and free software, the question is can you link them together using plugins in this way. At least from discussions I've seen in GStreamer the answer appears to be "no".
This is interesting for sure, but what are the licensing implications of this? Can anybody tell me?
GTK is LGPLd. That means it can be used by proprietary software (and in fact, sometimes is). If I use this theme engine does that mean I can no longer run proprietary software that uses GTK because I'd be linking it with GPLd code?
Perhaps the same concept should be applied but in reverse - a Qt theme engine to use GTK. There seems to be more experience going this way too, for instance XUL is already GTK themable and it works nicely.
Well, it depends if you consider my employer to be my boss or my company.
My boss was A-OK with this approach. If it got the job done, he didn't really care. Corporate headquarters may have taken a more official line - which is exactly why they are never told.
Well, of course there are two sides to every coin. I expect there's more corp sponsored free software hacking going on than you might think though. Remember that it's not always official - at my last job I submitted patches to various open source projects that I did on the job, because they happened to be basically what we needed and along the way I felt it was necessary to improve them. Often the only indication that they were done on paid time was that I sent them from my company email address.
I'm not sure why so few people have posted to this story (having fun at christmas i guess:) but as my family are just taking a break between watching Monsters Inc and starting the evening meal, I might as well post the things that are most likely to happen. BTW this is most appropriate for new years day - maybe we can get an article posted.
First, my own projects. autopackage will hopefully make it to 1.0 this year, or very near to it. We're starting to get aggressive about dropping non-essential features and by the end of 2004 hopefully the Linux community will have:
A nice framework for building installers that install Linux software on nearly any (sane) distribution, give you a pretty gui, detect and resolve dependencies regardless of how they were installed and integrates with existing RPM based technology.
A guidebook on how to write portable binaries - Linux binary portability is much better than most people seem to think but a best practices document won't hurt.
Some example packages that show how to do it.
Hopefully during 2004 Wine will release 0.9, which focusses amongst other things on ease of use. Or it might not. We're pretty bad at sticking to schedule there:(
On other fronts, expect to see multimedia finally start getting polished. We've got some really nice apps in development (in particular the Totem movie player and the Rhythmbox/JuK music players). These apps all still need a bit of work - for instance, inserting my Monsters Inc DVD today gave me a "Could not seek on NAV packet" or something equally cryptic: I needed libdvdcss installed. Easy for someone who's been around this block a few times already, useless for anybody else. Once that lib was installed though, it all worked perfectly, with a great user interface to boot.
Expect to see hardware integration getting into gear. Now RML is hired by Novell to hack exclusively on kernel desktop integration issues we're about to get *much* closer to plug and play hardware.
Gnome 2.6 will come out about half way through the year (prolly a bit earlier) and totally kick ass, as will KDE 3.2. In particular Gnome 2.6 will include Epiphany, which is one of the few native widgets browsers IMHO that I'd be happy presenting to my family. Firebird is great, but XUL/Gecko is still slower on X than Windows and has been for years, it's probably not going to improve much more soon.
Ephy was in Gnome 2.4 but unfortunately was release before it was really ready. The current version is buggy and missing essential features like popup blocking. You'll be pleased to hear that already in the Gnome development releases these problems are all gone, and it's a really cool little browser. It also takes advantage of lots of cool stuff from GTK 2.3, as well as some stuff still in development like a MacOS X style toolbar editor (with sliding buttons). Unfortunately that stuff won't get into GTK proper until it's proven itself in apps like Epiphany so it'll probably be 2005 before we start seeing it widespread.
The FDO X server (kdrive) will start getting usable in 2004. I have no idea if any major distros will switch, hard to tell while the driver situation is so uncertain, but where it works it'll bring Linux up to new levels of prettyness - not bad considering it already looks very professional IMHO.
Finally, expect to see lots of stupid desktop bugs and interop problems get nailed, as was the case during 2003, especially with things like removable media.
That's all I can think of! Definately we have to do this proper in the new year. Merry Christmas!:)
I don't think they can do that - last I heard they don't have any documentation themselves, the closest is a reference implementation of the loader.
At the bytestream level it'd be pretty hard anyway, as the formats are based on several different technologies (for instance, OLE Structured Storage). The format also contains wierd stuff like gaps of garbage to stay compatible with bugs in earlier versions.
It's funny that one would exclude the top C++ GUI toolkit for commercial development for the purpose of making the distribution friendly for commercial development.
I'm pretty sure the top C++ GUI toolkit for commercial development in terms of statistics would be the Microsoft Foundation Classes, or the ATL (or a mix). It probably isn't Qt.
You're also overlooking the efforts of the GTKmm team, which is made up of several people with many years of commercial development experience. All the reviews of GTKmm I've seen are positive - it has the advantage of being pretty new and therefore modern. Look at the email addresses of people on the GTKmm lists sometime - there's plenty of commercial development going on there, but GTK doesn't have a dedicated sales team that compiles big lists of them.
If I can put on my tinfoil hat for a second here, the best reason I can think of for not including the KDE libs is to stir up the traditional KDE/GNOME debate and get more coverage on slashdot and other sites. Trolling for media coverage, it's the wave of the future!
Sigh, no, read the article. This whole issue has been misunderstood by a lot of people - Perens is not dropping KDE because he doesn't like it, or he thinks it's a bad desktop - he's dropping it because to business he wants to present a single unified platform.
Reread that last sentance. The key word there is PLATFORM. If he included kdelibs, he'd now be presenting two platforms, not one.
This is not a personal snub against KDE or its developers, despite how some of them react. It's about business, and consistancy at the platform level.
Why would a Linux distro have to worry about its toolkit not being free on Windows ?
A Linux distro might not, but there's a lot of free software developers still on Windows you know. Portability has always, right from the start, been a big concern of the GNU project. Linux is only one (albiet the flagship) free software project.
The whole point of free software is that anybody should be able to use it - white or black, muslim or christian, criminal or saint, Windows user or Linux user. The point is not to play favourites, or to try and "lock in" people to Linux, despite the temptation.
Hmm, I'm starting to sense a pattern here. Now, go find the list of ISV's or commercial companies developing with GTK+.
In fact quite a few do, especially when writing software specifically for Linux. For instance, VMware, Real, Loki, there was some photo website company who support Linux (can't remember their name now) who have a GTK app to upload images and stuff.
Really, having a big list of companies who use Qt is not that useful. The fact is that NO major platform in existence today requires you to pay big bucks to write proprietary software for their platform. Not Windows, not MacOS - Linux should be no different. It'd be a serious competive disadvantage if it did. Yes, Apple and Microsoft charge for developer tools but it's nonetheless possible (and with stuff like.NET these days even easy) to develop for the platform entirely for free, and sell the resultant products as proprietary software.
And yet another reason the so-called licensing issue is bogus? The FSF prefers GPL'd libraries as a matter of principle.
It may have escaped your notice that most people ignore the FSF. The FSF (or really RMS) recommends people refer to Linux as "The GNU system, powered by the Linux kernel" or something like that. Yet nobody does.
That's because while RMS and the FSF have some great ideas (and software), not everything they say makes sense. This is one such thing.
The FSF want libraries to be GPL because they want all software to be GPLd, eventually. In fact, this could be achieved by making glibc GPLd, and in fact at one point RMS did try and do that - the glibc maintainers publically disowned him despite being long time GNU developers (some of the earliest in fact).
Besides, shouldn't the community benefit from some form of recompense from proprietary developers using our Free systems? Yes, we should and with Qt, we do.
This line of reasoning is an extremely poor one IMHO - by this logic don't all free software developers deserve recompense? What about server developers who couldn't care less about widget toolkits? Don't they deserve recompense from proprietary developers too?
I know - why not make most of our libraries GPLd? Oh yes, I know why: because then there'd be no proprietary developers at all.
In fact that's the main argument against Qts licensing - it's a slippery slope. Why should the widget toolkit be special? glibc is perhaps just as important, why not make that GPLd too?
Some community names went around spreading this ridiculous 'licensing problem' with Qt as deliberate FUD. And now we all have to clean up after their mess.
That's an interesting viewpoint. The alternative view is this: if the original KDE developers had paid more heed to the ideology of the FSF (the organization they now claim as allies so willingly) and simply worked on a new widget toolkit (maybe GTK, maybe something else) rather than take a convenient shortcut, there'd be no mess to clean up! We'd have one major desktop environment which would have more people working on it. There would be no licensing flamewars, no KDE vs GNOME trolls. We'd just be getting on with building a great desktop.
It's certainly a powerful lesson for the future - the only thing that makes our platform different is the licensing, the way we let anybody who wants to use it, modify it, and build upon it.
If we don't have that, we might as well just let Apple and Microsoft duke it out.
Despite RedHat no major distribution used Gnome as default.
Yet Red Hat is still the most popular distro, by a long way. Even in Europe, I now see lots of people using Red Hat (certainly this was true where I used to work).
Have you considered that people choose their distro based on what desktop they prefer? I used to use SuSE because they had a nice KDE desktop, but when Red Hat 8 came out I changed and have not looked back. I changed partly because Red Hat have a very nice default desktop (based on gnome2).
Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.
That is completely wrong - GTK doesn't support Win32 style MDI because:
a) Most window systems don't support it (X doesn't, Quartz doesn't).
b) It's extremely poor usability wise.
c) It's a lot of extra complexity for little gain.
It has nothing to do with the way GTK is built.
There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.
Again, you are completely wrong. The Win32 widget toolkit, which is *the* industry standard, is written in C.
Slashdot Mirror
I have to admit, I've never seen it and I follow Gnome (and to a slightly lesser extent KDE) closely. I see far more anti-C antagonism from the KDE/Qt crowd than anti-C++ antagonism from Gnome/GTK. In fact the GTK developers have even said that if you use GTK for a big project you probably shouldn't be using C.
Of course, C++ bindings are available for GTK. But who will use them if there is an a priori hatred for the language? Do you see my point now?
No, I don't. In fact GTKmm is used plenty - often by in house commercial projects. See the gtk.org success stories - many of them are based on GTKmm. I've never seen people flaming GTKmm because it's C++, in fact.
A huge issue is generic programming. Few people understand the boon of the STL until they use it. And home-grown generic templates are unbelievably useful as well.
Templates have costs and they have benefits, same as anything else. The costs are obvious - fewer people understand them, and being basically a textual hack when they go wrong the error messages have to be seen to be believed. The benefits can sometimes (often, perhaps) outweigh those costs.
I can't specialise on structures written in C, a real strength of KDE/Qt.
I really think you should check out GObject. It's a light year from being just "structures in C". In particular GObject has things signals and reflection. It was designed with object orientation in mind, and as such wrappers like GTKmm can do a good job.
Sorry. GTK is used in VMWare, and so far as I know, that's the only commercial app on earth that uses it
Then I'm afraid you are seriously misinformed and I see no reason to take you seriously. See the gtk.org success stories page, they are almost entirely commercial/proprietary software developers.
I have seen it happen many times - people who are scared by OOP, defensive about their lack of knowledge, and maintaining that C is perfect for everything, when Python, Java, or C++ are better fits.
I hope that comment isn't targetted at me. I've written plenty of OOP code in my time, in a variety of languages. I'm certainly not "scared" of it. I've written bindings from Delphi (which has a pretty clean object model) to Python. I've written Java class frameworks. I've implemented parts of COM (though whether that's object oriented is highly arguable). Object models are in interest of mine - I can argue with you about the merits of CORBA vs GObject vs [D]COM vs .NET vs native C++ all day.
What I am pointing out is that your blanket assertion that anybody who doesn't use C++ or Qt is "irrational and emotional" is pure zealotry - the real world is simply not that black and white. Why do you think so much software is written in Visual Basic? Because of its merits as a language? I think not.
No offense, but I get the feeling you write code as a hobby, not for a living. You have all the time in the world to plink away at your little projects. I don't want to belittle your efforts, but please get real.
Then your feelings are as incorrect as your beliefs. I've worked for my countries Ministry of Defence (Java, C, XML and relational databases, webapp development), I've contracted (Delphi) and I've been paid freelance to do free software. I've worked the span from education software for preschool kids to reverse engineering DCOM. I would have done more but I'm 19 and simply haven't had the time.
In the case of much Linux software development, C is a popular choice because lots of people are very familiar with it, and that's more valuable than being able to play with functors. If you want to of course, GTKmm lets you do that: the interfaces to (for instance) the tree view are designed to strongly resemble the STL.
All the SuSE versions I have ever used included XMMS, which depends on GTK 1.2, which depends on Glib 1.2 - I have no idea if modern SuSE installs XMMS by default or not but I never asked for it specifically.
Icon theming is a freedesktop.org standard, so GTK should be able to use it directly with no Gnome dependencies.
Which is better - to have one standard implementation in the toolkit that everything uses, or to relentlessly duplicate stuff from the toolkit in an enormous set of libraries and call it a desktop framework?
KDE duplicates so much stuff from Qt, that Qt-only apps feel entirely foreign. It wasn't that long ago that they even started sharing themes! Qt programs have different dialog boxes, different toolbars, often different icons (!) and so on.
So for instance, take the "combo box widget". The old GTK one works, but it has a few shortcomings that people wanted to address. The KDE way would have been to either subclass it or create an entirely new replacement but that started with a K and stick it in KDE libs. The GTK way is to fix GTK, so all apps benefit, not just those that decided to make the all-or-nothing choice that is KDE vs Qt.
So to say "KDE already has this" is disingenuous. In many cases, so did Gnome, but the code is actually being moved to where it belongs (and being made nicer in the process).
What, so the reason people don't use Qt is because they are irrational and emotional? Let me remind you that C++ users can always use GTKmm which is arguably more "C++" than Qt will ever be.
Let me explain to you why the autopackage project has a very nice GTK2 based front end, and no KDE or Qt frontend. NB: plenty of people have offered to work on one, including core KDE hackers. We never saw any code. Make of that what you will.
We chose to use GTK from C because:
- C is a simple language that both me and Hongli (the other principle author of it) knew well. I've done plenty of OO programming in Delphi and Java before but only a little C++. The greater featureset of C++, in this case simply wasn't worth the hassle of ensuring we both knew it well, and weren't churning out constructs that the other couldn't understand.
It also increased dramatically the number of people that could work on it. Surprising though it may be, not everybody (especially in the unix world) knows C++.
- C has a stable ABI. For a program that is supposed to work anywhere without recompilation this is a big deal. That won't be an issue in a few years when gcc 2.95 is but a distant memory, but at the moment it is.
- It required no bindings. You can, of course, use C++ with GTK by using the rather spiffy GTKmm which gives you STL and a C++ish API so that other than a few minor oddies you'd never know the underlying toolkit was written in C, but this is an extra dependency, the cost of which was simply not worth it.
I look at the Gnome source code and shudder. It just reminds me so much of writing GUI code for Windows 3.1 and 95 (yes, I've done that).
If you're going to compare modern GTK to Win32 then all I can say is that you either haven't actually done any GTK programming or you haven't done any Win32 programming. I've done plenty of both and I can tell you that GTK is about a million light years away from Win32. The API is sane, consistant, and the toolkit is a powerful one.
Now let me tell you what I don't get.
I see people bitching (mostly ignorantly) about GTK, Gnome, C, whatever and praising the shining pearls of light that is KDE and Qt, yet the fact is that GTK is way more popular.
No, really, it is. I have no Qt or KDE apps on my desktop at any point these days. That's not because I don't like Qt or KDE - I do - but the fact is that I don't choose apps based on what toolkit they use but on merit. I use Firebird (XUL), emacs CVS (a mixture of raw Xlib and gtk2 these days), irssi (ncurses), Pan (raw GTK) and so on.
Yet, I once read a KDE developer claim that Yes! It's true! He had spent a whole month without glib installed on his system - he wanted to prove it was possible to do it, and well done he did. But if people have to do macho time trials to prove they can do without something - isn't this a hint?
I could be cynical and say that GTK is more popular because the people using it are busy getting shit done in whatever language lets them work most effectively (c, python, c++, whatever) instead of trolling about the superiority of Qt and C++ on Slashdot, but I won't. I'll let readers make up their own minds. I use what works for me.
Yeah, I think this almost certainly is. Huge amounts of bit manipulation, lots of magic numbers, meaningless variable names. No type safety? No comments?
I've seen code like this before, when people have disassembled Windows DLLs back into C then tried to submit it to Wine.
I'd say Jon is treading on very slippery slopes indeed with this code. It might be possible to show that it's been simply generated from the original code which is almost certainly copyright violation - laws against that certainly exist in Norway.
If true that'd be a pretty serious accusation. Reverse engineering is allowed under most western laws - copyright infringement is not. Translating from assembly back to C simply changes the form, not the content of a work and iirc this is simply not legal.
Of course, it's hard to prove. Maybe too hard. But if Jon has made heavy use of dissasembled code he could be in for a rough ride.
Right. People make a lot of noise about wanting iTunes[MS] on Linux, but the fact is we've had zero people actually trying to make it work on Wine. When it first came out there were a few attempts to run it by end users, but so far nobody has sat down and hacked out the code necessary to make it work.
This tells me that probably the number of people who *really* care about this is reasonably small, they just make a lot of noise. Otherwise out of all those people who wanted iTMS, one or two of them would have sat down and hacked code.
Is anybody going to prove me wrong? I'm happy to give some tips, you know. You might want to start with the installer: it requires an unusual form of COM activation in order to start MSI (service-based). We don't implement this in Wine yet, but it wouldn't be hard to add.
Anybody?
Hear hear. Couldn't have said it better myself.
This is true of many things, not just software. Yes, if you use a service or product that can only be supplied by somebody else then you might get screwed. This is not great.
One solution (the most common one) is simply to be careful in whom you trust and who you don't. The solution RMS advocates is that nobody should ever place themselves in a situation where they could possibly be screwed - and he preaches this regardless of how practical it might be in any situation.
Remember, this is the guy who won't actually recommend any installable version of the GNU system (iow Linux) because none of them - not even Debian or Red Hat which don't include any non-free software by default - live up to his levels of purity.
My objection to Stallmans stance is not so much that I think he's wrong (a lot of what he says is valid) but that he shuns people if they dare use or recommend even one piece of proprietary software - in effect he wants people to use free software so badly he's happy to withhold information from them to "encourage them to make the right choice".
For instance, he won't name Ximian Connector because it might encourage people to use non-free software: this is a fundamentally condescending idea in my view, as it assumes that the listener could not make up their own mind based on their own priorities.
Or any of the other stories on Slashdot where a closed-source company lures users and developers with gratis copies of their new, shiny product - and then changes licensing terms once everyone's hooked?
One legal point - you can't retroactively change the license on a piece of software, as far as I'm aware. Sure, you can change the license on future releases if you own the copyright on that work, but this is as true for free software as anything else, so simply being GPLd does not mean you won't get screwed by dubious license clauses in future versions, it means you could fork the last acceptable version and use that instead.
If you have read his writings, he has fairly convincingly argued from first principles that software should be free. I, and many others, have read this and been inspired, because the world he ultimately wants to live in is about co-operation and sharing.
However, RMS often leaves people behind with his extreme on/off view. This sentance is pivotal:
This is seriously distorting his already bent definition of "free". Freedom, as he defines it, can be applied to software (and with a bit of work books, music etc) and while you might argue with the word used it's a useful concept to have.
Here though, he applies the word free to users, and this is a different thing entirely. Worse, he asserts that all it takes is one piece of non-free software to spoil his utopian dream.
I think a lot of people like the idea of free software, but we're willing to accept compromise. It's not an all or nothing proposition. Free software have inherantly good vibes because we're not imposing arbitrary limitations on what people can do with what we made (which is ultimately beneficial) but it's not like I'm a slave to the machine because I use the NVidia video drivers.
Yeah, I'd like to have free drivers, but Alan Cox himself has said he cannot think of a way to justify NVidia freeing their code - their fears of what would happen to their business if they did that are justified, he thinks. That's good enough for me. In this case, it just isn't practical. I don't like it, but that's life.
RMS sees it differently. That alienates people.
Personally I don't find it to be an issue, but whatever floats your boat....
Installing stuff together isn't the same as linking them together. Of course GTK can be used at the same time as proprietary and free software, the question is can you link them together using plugins in this way. At least from discussions I've seen in GStreamer the answer appears to be "no".
GTK is LGPLd. That means it can be used by proprietary software (and in fact, sometimes is). If I use this theme engine does that mean I can no longer run proprietary software that uses GTK because I'd be linking it with GPLd code?
Perhaps the same concept should be applied but in reverse - a Qt theme engine to use GTK. There seems to be more experience going this way too, for instance XUL is already GTK themable and it works nicely.
Sun have a policy that everything which ships with Solaris must be built with Forte. A major PITA for sure, but an understandable one.
The other reason was that Sun have more engineers that know C well than C++, as far as I know.
My boss was A-OK with this approach. If it got the job done, he didn't really care. Corporate headquarters may have taken a more official line - which is exactly why they are never told.
Well, of course there are two sides to every coin. I expect there's more corp sponsored free software hacking going on than you might think though. Remember that it's not always official - at my last job I submitted patches to various open source projects that I did on the job, because they happened to be basically what we needed and along the way I felt it was necessary to improve them. Often the only indication that they were done on paid time was that I sent them from my company email address.
First, my own projects. autopackage will hopefully make it to 1.0 this year, or very near to it. We're starting to get aggressive about dropping non-essential features and by the end of 2004 hopefully the Linux community will have:
Hopefully during 2004 Wine will release 0.9, which focusses amongst other things on ease of use. Or it might not. We're pretty bad at sticking to schedule there :(
On other fronts, expect to see multimedia finally start getting polished. We've got some really nice apps in development (in particular the Totem movie player and the Rhythmbox/JuK music players). These apps all still need a bit of work - for instance, inserting my Monsters Inc DVD today gave me a "Could not seek on NAV packet" or something equally cryptic: I needed libdvdcss installed. Easy for someone who's been around this block a few times already, useless for anybody else. Once that lib was installed though, it all worked perfectly, with a great user interface to boot.
Expect to see hardware integration getting into gear. Now RML is hired by Novell to hack exclusively on kernel desktop integration issues we're about to get *much* closer to plug and play hardware.
Gnome 2.6 will come out about half way through the year (prolly a bit earlier) and totally kick ass, as will KDE 3.2. In particular Gnome 2.6 will include Epiphany, which is one of the few native widgets browsers IMHO that I'd be happy presenting to my family. Firebird is great, but XUL/Gecko is still slower on X than Windows and has been for years, it's probably not going to improve much more soon.
Ephy was in Gnome 2.4 but unfortunately was release before it was really ready. The current version is buggy and missing essential features like popup blocking. You'll be pleased to hear that already in the Gnome development releases these problems are all gone, and it's a really cool little browser. It also takes advantage of lots of cool stuff from GTK 2.3, as well as some stuff still in development like a MacOS X style toolbar editor (with sliding buttons). Unfortunately that stuff won't get into GTK proper until it's proven itself in apps like Epiphany so it'll probably be 2005 before we start seeing it widespread.
The FDO X server (kdrive) will start getting usable in 2004. I have no idea if any major distros will switch, hard to tell while the driver situation is so uncertain, but where it works it'll bring Linux up to new levels of prettyness - not bad considering it already looks very professional IMHO.
Finally, expect to see lots of stupid desktop bugs and interop problems get nailed, as was the case during 2003, especially with things like removable media.
That's all I can think of! Definately we have to do this proper in the new year. Merry Christmas! :)
At the bytestream level it'd be pretty hard anyway, as the formats are based on several different technologies (for instance, OLE Structured Storage). The format also contains wierd stuff like gaps of garbage to stay compatible with bugs in earlier versions.
I'm pretty sure the top C++ GUI toolkit for commercial development in terms of statistics would be the Microsoft Foundation Classes, or the ATL (or a mix). It probably isn't Qt.
You're also overlooking the efforts of the GTKmm team, which is made up of several people with many years of commercial development experience. All the reviews of GTKmm I've seen are positive - it has the advantage of being pretty new and therefore modern. Look at the email addresses of people on the GTKmm lists sometime - there's plenty of commercial development going on there, but GTK doesn't have a dedicated sales team that compiles big lists of them.
Sigh, no, read the article. This whole issue has been misunderstood by a lot of people - Perens is not dropping KDE because he doesn't like it, or he thinks it's a bad desktop - he's dropping it because to business he wants to present a single unified platform.
Reread that last sentance. The key word there is PLATFORM. If he included kdelibs, he'd now be presenting two platforms, not one.
This is not a personal snub against KDE or its developers, despite how some of them react. It's about business, and consistancy at the platform level.
A Linux distro might not, but there's a lot of free software developers still on Windows you know. Portability has always, right from the start, been a big concern of the GNU project. Linux is only one (albiet the flagship) free software project.
The whole point of free software is that anybody should be able to use it - white or black, muslim or christian, criminal or saint, Windows user or Linux user. The point is not to play favourites, or to try and "lock in" people to Linux, despite the temptation.
In fact quite a few do, especially when writing software specifically for Linux. For instance, VMware, Real, Loki, there was some photo website company who support Linux (can't remember their name now) who have a GTK app to upload images and stuff.
Really, having a big list of companies who use Qt is not that useful. The fact is that NO major platform in existence today requires you to pay big bucks to write proprietary software for their platform. Not Windows, not MacOS - Linux should be no different. It'd be a serious competive disadvantage if it did. Yes, Apple and Microsoft charge for developer tools but it's nonetheless possible (and with stuff like .NET these days even easy) to develop for the platform entirely for free, and sell the resultant products as proprietary software.
And yet another reason the so-called licensing issue is bogus? The FSF prefers GPL'd libraries as a matter of principle.
It may have escaped your notice that most people ignore the FSF. The FSF (or really RMS) recommends people refer to Linux as "The GNU system, powered by the Linux kernel" or something like that. Yet nobody does.
That's because while RMS and the FSF have some great ideas (and software), not everything they say makes sense. This is one such thing.
The FSF want libraries to be GPL because they want all software to be GPLd, eventually. In fact, this could be achieved by making glibc GPLd, and in fact at one point RMS did try and do that - the glibc maintainers publically disowned him despite being long time GNU developers (some of the earliest in fact).
Besides, shouldn't the community benefit from some form of recompense from proprietary developers using our Free systems? Yes, we should and with Qt, we do.
This line of reasoning is an extremely poor one IMHO - by this logic don't all free software developers deserve recompense? What about server developers who couldn't care less about widget toolkits? Don't they deserve recompense from proprietary developers too?
I know - why not make most of our libraries GPLd? Oh yes, I know why: because then there'd be no proprietary developers at all.
In fact that's the main argument against Qts licensing - it's a slippery slope. Why should the widget toolkit be special? glibc is perhaps just as important, why not make that GPLd too?
Some community names went around spreading this ridiculous 'licensing problem' with Qt as deliberate FUD. And now we all have to clean up after their mess.
That's an interesting viewpoint. The alternative view is this: if the original KDE developers had paid more heed to the ideology of the FSF (the organization they now claim as allies so willingly) and simply worked on a new widget toolkit (maybe GTK, maybe something else) rather than take a convenient shortcut, there'd be no mess to clean up! We'd have one major desktop environment which would have more people working on it. There would be no licensing flamewars, no KDE vs GNOME trolls. We'd just be getting on with building a great desktop.
It's certainly a powerful lesson for the future - the only thing that makes our platform different is the licensing, the way we let anybody who wants to use it, modify it, and build upon it.
If we don't have that, we might as well just let Apple and Microsoft duke it out.
Yet Red Hat is still the most popular distro, by a long way. Even in Europe, I now see lots of people using Red Hat (certainly this was true where I used to work).
Have you considered that people choose their distro based on what desktop they prefer? I used to use SuSE because they had a nice KDE desktop, but when Red Hat 8 came out I changed and have not looked back. I changed partly because Red Hat have a very nice default desktop (based on gnome2).
That is completely wrong - GTK doesn't support Win32 style MDI because:
a) Most window systems don't support it (X doesn't, Quartz doesn't).
b) It's extremely poor usability wise.
c) It's a lot of extra complexity for little gain.
It has nothing to do with the way GTK is built.
There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.
Again, you are completely wrong. The Win32 widget toolkit, which is *the* industry standard, is written in C.