This is due to the way C++ is generally taught or learned on ones own.
The original question was rhetorical - the reason many large C++ projects like Mozilla don't use these features is because they aren't sufficiently portable between compilers: writing a good C++ compiler is so hard that almost nobody does it right. While the latest compilers for the major platforms (MSVC++7 and gcc) get it mostly right many others do not.
It has nothing to do with the way C++ is taught, sorry, and everything to do with the language itself.
Having said that of course, gcc is available everywhere so I don't have too much sympathy....
If people want to profit from code based on the excellent Qt toolkit, why should they not have to pay Trolltech for the privelige of using their excellent toolkit?
There's a huge stack of excellent code on the typical desktop, yet nobody else requires the sort of licensing TrollTech do. If you're going to take that position for Qt, why not also take it for the Linux kernel, glibc, libpng, Xlibs, Cocoa, Java,.NET etc.
How do you obtain the MS API, core libraries, and development environment without buying a license to use at least soem flavor of Windows, and probably VB, or another MS-compatible IDE as well?
You can get the Platform SDK for free (with free updates) here.
Yes, you need a license to use Windows (not much use otherwise, is it?) but that's different to needing a license to develop for the platform which Microsoft has never required.
Having said that, Windows is not a good development platform out of the box, so they still make money by selling some rather spiffy tools to make developers lives easier.
Could the answer be the mach kernel osx uses? Maybe we need a new suite of benchmarks for user interaction. (os+X+wm/etc).
Hahah, no, Mach sucks donkey ass. The slowdown in performance given heavy IO based benchmarks (like compiling things) is noticeable. Mach-O is one of the most primitive binary formats around.
No, the reason the MacOS X GUI feels fast is that it's entirely double buffered and given priority over practically everything else on the system. The freedesktop.org X server has double buffering working nicely, but it's not ready for wide-spread usage yet.
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing.
Er, do you know how much software out there is OOM safe? Almost none.
Though FWIW DBUS bucks that trend and actually is OOM safe.
Nonetheless, failing cleanly (with an understandable error message) instead of a segfault is waaaay better than simply dying at some random later point because malloc returned null when you assumed it didn't.
Great for building toy programs, but absolutely terrible for building a production quality system.
I really don't see what your problem is. Can you give examples of where glib "lacks error handling" sufficient for "production systems" (which almost invariably aren't fully OOM safe anyway).
While I'm an avid Linux fan, why do I get the feeling that if a large Linux distributor like Red Hat arranged for a glut of software to be sent to UN countries, the headline would have been slightly more flattering?
How would they do that? Linux costs nothing. It's already available to them for free.
It could be that Red Hat would donate free support but that is very different, especially considering that people can and will either support themselves or go elsewhere if Red Hat were to go bad.
Is KParts good enough to be used generally - apart from KDE? Like what CORBA is designed for?
KParts isn't really anything like CORBA, it's far less ambitious for starters and is essentially little more than a glorified wrapper around a C++ class loader.
In particular, KParts must be written in KDE/Qt C++, ie they are tied at a fundamental level to KDE and Qt. You can write them in other languages if you can somehow export your languages classes via a C API (for instance Python) because you can write a code generator that builds a C++ wrapper around it, but if that isn't the case, for instance with Java/gcj, D, or whatever, then you're basically SOL. You have to be able to access your objects from C++ and you have to be able to link against Qt. It's obviously also in-proc only.
Now, for the purposes it was designed for, KParts has been a large success, but partly only because KDE has a tendancy to reinvent lots of applications internally to make them K enough, so obviously there are no problems using KParts.
Usage of KParts is non-existant outside of KDE apps, for obvious reasons, unlike Bonobo which is an optional dependency for some non-Gnome apps like AbiWord. That's not necessarily a bad thing, mind.
Having said that, I'm not sold that KParts is even a good thing. It was designed back when OLE and OpenDoc were fashionable, and a platform without the ability to do in-place editing of documents just wasn't cool. Since that time almost all major desktops have dropped or de-emphasised these features, except KDE. For instance, MacOS X doesn't appear to have one at all, and on Windows the traditional role of OLE has been blurred by initiatives like OLE Automation and ActiveX which bear little resemblance to traditional uses.
While KParts are used all over KDE, I see little evidence that this makes it a better, easier to use desktop. If anything it's harmful - Konqueror is the very definition of jack of all trades but master of none. In the few cases where document embedding is useful, specialist integration is the way forward for free systems I feel.
I can't tell you how infuriating it is when you go to copy a page of text from, say, openoffice.org, and paste it into a webform in Mozilla - only to find that perhaps the first half a paragraph out of 6 made it over.
This has nothing to do with X and has everything to do with a long standing bug in Mozilla, which fails to use the X clipboard correctly. Mozilla on X has always been secondary to Mozilla on Windows/GDI, and unfortunately it shows here badly.
Here is the buglink: http://bugzilla.mozilla.org/show_bug.cgi?id=56219, you'll need to copy/paste to stop bugzilla being Slashdotted (don't bother if you aren't interested or able to understand the technical details).
Basically Mozilla does not properly support the ICCCM protocols and as is often the way with Mozilla the bug has been blocking on one or two overworked people for a very long time.
An object lesson in why inventing your own toolkit is a silly idea, IMHO....
Sure, but most people don't use Konqueror remember, and dragging in the whole of kdelibs just to embed MPlayer is too heavyweight for most desktop users. I also can't really fathom how that works, unless you're using a much newer version of mplayer than me - I gave it the URL and it simply couldn't grok the reference media.
I'd consider crashing at all a serious problem, aking to a kernel panic in terms of badness. Fortunately X is pretty stable. Crashes in it are normally XVideo related in my experience.
Also, Desktop and icons must be files, and not stupid complex data-files, which is pretty hard to modify.
At least in Gnome 2.4 the "virtual" icons on the desktop are overlayed by the file manager and do not actually exist on the filing system (home, start here etc). The desktop is then made up from the files in ~/Desktop
Here's a few items from a private "Linux TODO list" that me and some friends maintain:
Easy software installation. People do not want to spend an hour installing a program. Apt/yum/emerge et al are not full solutions:
There are not and never will be any repositories that contain all the software you want in an up to date fashion. Mixing repositories leads to big issues, see OpenCarpet.org which immediately wanted to upgrade my copy of Frozen Bubble 1.0 to Frozen Bubble 1.0 thanks to metadata mismatches.
There is no standard for desktop integration - why should users have to type a cryptic command in order to install software? Why not just click the icon in the webpage?
The status quo is that packagers don't notify software maintainers when their software is packaged, so frequently there is no way to find out what random permutation on the softwares name your repository uses short of grepping/searching the full list. Worse, some packagers choose to split things into different sized pieces, for instance on Debian to get a full Wine setup you need not just "wine" but also "wine-tools".
Multimedia support is still weak. Today I wanted to watch the trailer for the Runaway Jury, but unfortunately Apple have monopolised the market on film trailers (I heard they pay or give free/ultra cheap hosting in order to make people use QuickTime) and, surprise, their website doesn't work well on Linux. There is no real standard location for browser plugins, nor is there any readily accepted implementation for embedding playback engines into the browser. You have to grep the page sources for the URL to the.mov, and even then it doesn't work as neither mplayer nor xine understand the MOV reference types (a proprietary form of redirect, in effect). So I can't watch the trailer.
We need to be able to run peoples existing games, applications etc nearly flawlessly. Wine has to get a lot better first. Recently Jeremy White of CodeWeavers set an interesting challenge - given how far Wine has come in the past few years, he thinks it might be possible to have 95% of Windows apps roughly functional by the end of 2005.
That's just a random subset of things that we need in order to provide a quality desktop that most non-trivial/non-grandma users do. There are a million and one other things we need as well.
In short while a huge amount has been accomplished, there's still a huge pile left to do. Still, it's not as hopeless as it looks - the distance Linux has come since I started using it only 2 years ago is incredible. Beautiful fonts, cleaned up desktops, hugely improved artwork, maturing applications and powerful media players are just a few of the achievements I can think of.
I guess I'm tired of seeing the flames. Can't the developers simply acknowldege that there is more than one way to look at the UI and add the simple option to have MDI? Or is it really not that simple? Perhaps not. Is that why the option is being avoided?
Your problem is solved by virtual desktops. MDI is not supported by most windowing systems that Gimp is run on (X, Quartz).. in fact only Win32 does support it. MDI is a hack that doesn't allow you to use standard windowing widgets like the window list to switch between them. It's hard to implement. It's a limitless source of bugs. It's got terrible usability - even Microsoft doesn't use it anymore.
In short, if you want to have many windows open at once and manage them all, use virtual desktops - use many of them, if you like. Have each image you are working with on a different desktop. I've done this and found it works nicely, much better than MDI ever did.
Or what - did you really think that Unix was so great it could be loved? A 20 year old design that has been surpassed by grad students a hundred times over? An OS that has no desktop infrastructure at all, so it has to be painstakingly built up one piece, one argument at a time?
Only a crazy fool would love Unix. Don't get me wrong. I like Unix, I like the command line and the things I can do with it, I like X and the things I can do with that, but there is also plenty I dislike about Unix too like the stupidly cryptic and overshort command/function names (creat, mbstowcs.. ?)
Linux is for those that hate Windows.
Only a crazy fool would hate Windows. For all its faults, it has a lot of neat features, and despite over a decade of monopoly the latest versions do basically work pretty well. It has unrivalled backwards compatability - though the measures they use to get it make me sick.
Still, I dislike Windows. It's internal design is gross and the only official solution is.NET - yay, just what we need, another performance hog of a VM, yet more variants on the PE format. I dislike what it stands for more to the point - if the open source world had turned out Windows I wouldn't be disappointed, in fact I'd be impressed, but the fact remains that Windows is the figurehead of the proprietary software world. And I dislike that.
You know what I dislike most of all though? Trite sayings like that one;)
We need something like the old loadlin that overwrote the in-memory DOS image on DOS/Win9x systems, so you can boot up Linux direct from your Windows desktop.
Of course, this is the very definition of Not Trivial. Windows is a highly complex OS, if you simply load a driver and proceed to boot into Linux you run the risk of permenantly damaging the machine, possibly destroying the registry or the file systems.
OTOH we have some seriously smart hackers working on Linux these days. I'm pretty sure it'd be possible to build a program that suspended Windows and passed control to Linux that could be launched from the desktop, to get around this problem of needing to fiddle with BIOS settings etc.
No, instead we have software with names like yacc, Bison, and ANTLR (all of these programs are used in compiler design).
Why is this relevant? Yacc and Bison are used by software developers, not end users. ANTLR isn't even a program, it's (iirc) a type of grammar.
If you're going to try and pick examples of bad software naming, go ahead there are plenty of them (Excel, Access, Windows;-), but at least choose ones which are used by end users.
Could this prog be separated between UI dependant and toolkitn agnistic (yes, gtk+ is a freakin' X widget toolkit.. anbd I hope it will saty so)
You don't know what you're talking about. GLib and GObject don't even depend on X, let alone a widget toolkit. GTK is built upon these libraries, but to say GStreamer depends on a widget toolkit is flat out wrong.
I wonder what will happen when MPlayerG2 comes out from an incubator. Will the two projects simply compete, or will they work out some way to integrate/support each other?
To be honest, the two don't really compete... mplayer is purely playback focussed. It has no pretensions as a multimedia framework, or anything of the sort. GStreamer is all about being a powerful multimedia framework.
It's easy to forget how much code sharing goes on between these projects. They are all liberally licensed, all import each others code all the time and swap codec implementations etc. This isn't like standard capitalist competition where people constantly reinvent the wheel in order to stay ahead - if mplayer has a codec the GStreamer guys want, licensing issues nonwithstanding they'll go and take it.
In fact, there is little out there to compete with GStreamer, at least on Linux. The nearest equivalent would be DirectShow on Windows which has nowhere as nice an architecture.
You're probably thinking that GStreamer duplicates Xine and MPlayer (though mplayer isn't really a library). To a certain extent it does - they all allow you to play back files, however GStreamer allows you to do a whole lot more.
Having said that, at the moment XineLib is more robust than GStreamer is, but the competition actually is spurring them forwards.
Well, this phrase on their PR story: "Novell Ximian Desktop 2 is the complete enterprise Linux desktop" kind of suggests that they'll do the most likely thing and release a new distro, based on SuSE but using Ximian desktop and integrating nicely with NDS and Red Carpet (as management/integration tools are their business plan) while leaving the standard home user SuSE Linux alone.
I think you should compare the UI of Sound Juicer (an application dedicated to CD ripping) to the UI of audiocd:/ and then perhaps you will see what I mean. The file manager is not a generic catch-all UI for programs, it's for managing files. Abusing that to turn it into a CD ripper is just asking for sub-par UIs
Hmm, that reasoning seems circular. Developers are the only ones who care about the underlying platform, users generally do not as it rarely affects them (stuff like kio-slaves being an obvious exception). So if users use KDE, it'd make sense that they use it because they feel it's a better desktop.
So, why are more apps written using GTK/Gnome? I don't know. FWIW I feel the KDE framework is better too, but ultimately they are both pretty good. In particular GTK stands on its own more than Qt does on the Linux desktop - for apps that wish to remain desktop neutral it seems a more natural choice (and to be honest GTK vs Qt is a pretty even match, you can argue about the corner cases all day but I'd say they're just as good as each other).
Whenever I read the KDE API docs I can't help thinking what a shame it is - if the original developers had cared more about licensing we'd probably only have one desktop, and everybody would use these great frameworks. There'd be no problems with desktop neutrality, no need to slowly reinvent everything in order to make it desktop neutral and so on.
A lesson learned hard, and one I hope future developers will respect..... those who don't take community concerns over platforms seriously can seriously damage things.
Well, this has been theoretically possible for ages, both GTK and Qt have pluggable main loop abstractions. The thing is, somebody has to care enough to want to do it.
So if nobody cared enough to integrate the KDE dialogs into GTK, doesn't that indicate that the people using GTK/Gnome apps are happy with the way things are (ie... they have a consistant desktop already perhaps?) more than anything else?
In order for this to work you have to link against kdelibs and Qt, which means your software must be made available under a GPL compatible license. Therefore this isn't an option for proprietary software, unless you buy licensing from TrollTech.
Yeah yeah, I know the standard argument..."but Qt is so great it justifies the license fees and we all get paid so much anyway it doesn't really matter", but the fact is that it does discourage people - only a few days ago I was reading somebody on the GTKmm mailing list saying that he simply couldn't justify the cost of Qt for his development team (ah here it is - edit). My father runs a cottage software business. He can't justify the cost of Qt either. So, this is still problematic.
However, that doesn't matter for free software, which is like 99.9% of most Linux desktops anyway. A slightly more practical problem is that apps have to be ported to use this stuff, ie you can't just install QtGtk and have all your apps use the KDE dialogs overnight (nice though that'd be).
Still, I expect it will help in the short term.
Long term I'm really not sure how to solve this one - QtGTK is a nice hack but ultimately dialogs are currently a part of a widget toolkit, and especially considering things like customization etc it's really not trivial to abstract it.
Worse, it's really not easy to dlopen/dlsym C++ stuff like this, so you will end up with multiple builds of programs - one that depends on kdelibs and uses the dialogs, and another virtually identical one that doesn't. Having multiple builds of software for features like this is exactly what we are trying to get away from now - it only complicates the already overcomplex software installation process on Linux.
If we go down this route then we'll end up with loads of software with lots of duplicated dialog code. It's not so bad for just common file dialogs etc, especially considering that KDE offers more types of dialog than GTK does anyway (though i'd note not gnome libs et al), but it sets a worrying precedent.
A better solution IMHO would be to do the following:
Sort out the VFS mess. The problem with KIO (and to a lesser extent gnome-vfs) is that it's so easy to write VFS plugins that people do it lots. This is bad. Rarely have I seen a program that is implemented better as a VFS plugin than a normal app. VFS systems are useful for some things, like network transparent file access - though you have to be careful about breaking POSIX filing system semantics in, for instance, httpfs - but they are a disaster when people start writing things like kamera:/ or audiocd:/
The solution here is probably either to work on a shared desktop VFS system, or (politically somewhat harder) deprecate KIO and gnome-vfs in favour of lower-level systems. I've already been advocating doing the same for sound servers for some time now - this problem is simply not the desktops to solve.
Yes, that will mean that people on HPUX or whatever probably can't get network transparent file access. Boo hoo. Use a better OS if this really bugs you. Duplicating this functionality at a higher level simply causes fragmentation and people re-inventing the wheel.
I think the new GTK file picker is pluggable. The KDE one could probably be made so without too much disruption. Do what Red Hat did for bluecurve and design a commonly designed set of common dialogs which Qt and GTK can both use. They don't actually have to be the same, as long as they look the same. Combined with unified theming and having the VFS at the kernel level, this would provide "good enough" consistancy without having to maintain dual builds of every single app out there.
This situation is complicated by the fact that KDE and GTK/Gnome don't share a HIG. Realistically speaking, this is a problem that needs to be solved on KDEs end - the current HIG is entirely non-descript and apps that comply with it simply resemble your average Windows app. It might not be a big issue, I don't know....
Or, you could distribute your application as a proprietary application and require the USER to link them together, which while not completely kosher, doesn't appear to violate the letter of the GPL license.
Well, you are pretty clearly violating the wishes of the respective owners of the software involved if you do that - guys, please, let's encourage people to act with honour ok?
The legalities of it are somewhat more involved I guess. I'd definately not advise anybody to do that, as it probably just shifts the copyright infringement from the software developer to the users. GNU software has been around for decades, if it was that trivial to work around it somebody would have tried by now.
Slashdot Mirror
The original question was rhetorical - the reason many large C++ projects like Mozilla don't use these features is because they aren't sufficiently portable between compilers: writing a good C++ compiler is so hard that almost nobody does it right. While the latest compilers for the major platforms (MSVC++7 and gcc) get it mostly right many others do not.
It has nothing to do with the way C++ is taught, sorry, and everything to do with the language itself.
Having said that of course, gcc is available everywhere so I don't have too much sympathy....
There's a huge stack of excellent code on the typical desktop, yet nobody else requires the sort of licensing TrollTech do. If you're going to take that position for Qt, why not also take it for the Linux kernel, glibc, libpng, Xlibs, Cocoa, Java, .NET etc.
How do you obtain the MS API, core libraries, and development environment without buying a license to use at least soem flavor of Windows, and probably VB, or another MS-compatible IDE as well?
You can get the Platform SDK for free (with free updates) here.
Yes, you need a license to use Windows (not much use otherwise, is it?) but that's different to needing a license to develop for the platform which Microsoft has never required.
Having said that, Windows is not a good development platform out of the box, so they still make money by selling some rather spiffy tools to make developers lives easier.
Hahah, no, Mach sucks donkey ass. The slowdown in performance given heavy IO based benchmarks (like compiling things) is noticeable. Mach-O is one of the most primitive binary formats around.
No, the reason the MacOS X GUI feels fast is that it's entirely double buffered and given priority over practically everything else on the system. The freedesktop.org X server has double buffering working nicely, but it's not ready for wide-spread usage yet.
In fact this is one big reason to use glib: it makes it very easy to support UTF-8 and other things in a portable (to windows) way.
Er, do you know how much software out there is OOM safe? Almost none.
Though FWIW DBUS bucks that trend and actually is OOM safe.
Nonetheless, failing cleanly (with an understandable error message) instead of a segfault is waaaay better than simply dying at some random later point because malloc returned null when you assumed it didn't.
Great for building toy programs, but absolutely terrible for building a production quality system.
I really don't see what your problem is. Can you give examples of where glib "lacks error handling" sufficient for "production systems" (which almost invariably aren't fully OOM safe anyway).
How would they do that? Linux costs nothing. It's already available to them for free.
It could be that Red Hat would donate free support but that is very different, especially considering that people can and will either support themselves or go elsewhere if Red Hat were to go bad.
So basically the two aren't in any way related.
KParts isn't really anything like CORBA, it's far less ambitious for starters and is essentially little more than a glorified wrapper around a C++ class loader.
In particular, KParts must be written in KDE/Qt C++, ie they are tied at a fundamental level to KDE and Qt. You can write them in other languages if you can somehow export your languages classes via a C API (for instance Python) because you can write a code generator that builds a C++ wrapper around it, but if that isn't the case, for instance with Java/gcj, D, or whatever, then you're basically SOL. You have to be able to access your objects from C++ and you have to be able to link against Qt. It's obviously also in-proc only.
Now, for the purposes it was designed for, KParts has been a large success, but partly only because KDE has a tendancy to reinvent lots of applications internally to make them K enough, so obviously there are no problems using KParts.
Usage of KParts is non-existant outside of KDE apps, for obvious reasons, unlike Bonobo which is an optional dependency for some non-Gnome apps like AbiWord. That's not necessarily a bad thing, mind.
Having said that, I'm not sold that KParts is even a good thing. It was designed back when OLE and OpenDoc were fashionable, and a platform without the ability to do in-place editing of documents just wasn't cool. Since that time almost all major desktops have dropped or de-emphasised these features, except KDE. For instance, MacOS X doesn't appear to have one at all, and on Windows the traditional role of OLE has been blurred by initiatives like OLE Automation and ActiveX which bear little resemblance to traditional uses.
While KParts are used all over KDE, I see little evidence that this makes it a better, easier to use desktop. If anything it's harmful - Konqueror is the very definition of jack of all trades but master of none. In the few cases where document embedding is useful, specialist integration is the way forward for free systems I feel.
This has nothing to do with X and has everything to do with a long standing bug in Mozilla, which fails to use the X clipboard correctly. Mozilla on X has always been secondary to Mozilla on Windows/GDI, and unfortunately it shows here badly.
Here is the buglink: http://bugzilla.mozilla.org/show_bug.cgi?id=56219, you'll need to copy/paste to stop bugzilla being Slashdotted (don't bother if you aren't interested or able to understand the technical details).
Basically Mozilla does not properly support the ICCCM protocols and as is often the way with Mozilla the bug has been blocking on one or two overworked people for a very long time.
An object lesson in why inventing your own toolkit is a silly idea, IMHO....
Sure, but most people don't use Konqueror remember, and dragging in the whole of kdelibs just to embed MPlayer is too heavyweight for most desktop users. I also can't really fathom how that works, unless you're using a much newer version of mplayer than me - I gave it the URL and it simply couldn't grok the reference media.
Care to back that up with evidence, or are we supposed to take the word of an anonymous slashdot poster?
I'd consider crashing at all a serious problem, aking to a kernel panic in terms of badness. Fortunately X is pretty stable. Crashes in it are normally XVideo related in my experience.
Also, Desktop and icons must be files, and not stupid complex data-files, which is pretty hard to modify.
At least in Gnome 2.4 the "virtual" icons on the desktop are overlayed by the file manager and do not actually exist on the filing system (home, start here etc). The desktop is then made up from the files in ~/Desktop
That's just a random subset of things that we need in order to provide a quality desktop that most non-trivial/non-grandma users do. There are a million and one other things we need as well.
In short while a huge amount has been accomplished, there's still a huge pile left to do. Still, it's not as hopeless as it looks - the distance Linux has come since I started using it only 2 years ago is incredible. Beautiful fonts, cleaned up desktops, hugely improved artwork, maturing applications and powerful media players are just a few of the achievements I can think of.
Your problem is solved by virtual desktops. MDI is not supported by most windowing systems that Gimp is run on (X, Quartz) .. in fact only Win32 does support it. MDI is a hack that doesn't allow you to use standard windowing widgets like the window list to switch between them. It's hard to implement. It's a limitless source of bugs. It's got terrible usability - even Microsoft doesn't use it anymore.
In short, if you want to have many windows open at once and manage them all, use virtual desktops - use many of them, if you like. Have each image you are working with on a different desktop. I've done this and found it works nicely, much better than MDI ever did.
I guess that's why I don't use it then.
Or what - did you really think that Unix was so great it could be loved? A 20 year old design that has been surpassed by grad students a hundred times over? An OS that has no desktop infrastructure at all, so it has to be painstakingly built up one piece, one argument at a time?
Only a crazy fool would love Unix. Don't get me wrong. I like Unix, I like the command line and the things I can do with it, I like X and the things I can do with that, but there is also plenty I dislike about Unix too like the stupidly cryptic and overshort command/function names (creat, mbstowcs .. ?)
Linux is for those that hate Windows.
Only a crazy fool would hate Windows. For all its faults, it has a lot of neat features, and despite over a decade of monopoly the latest versions do basically work pretty well. It has unrivalled backwards compatability - though the measures they use to get it make me sick.
Still, I dislike Windows. It's internal design is gross and the only official solution is .NET - yay, just what we need, another performance hog of a VM, yet more variants on the PE format. I dislike what it stands for more to the point - if the open source world had turned out Windows I wouldn't be disappointed, in fact I'd be impressed, but the fact remains that Windows is the figurehead of the proprietary software world. And I dislike that.
You know what I dislike most of all though? Trite sayings like that one ;)
We need something like the old loadlin that overwrote the in-memory DOS image on DOS/Win9x systems, so you can boot up Linux direct from your Windows desktop.
Of course, this is the very definition of Not Trivial. Windows is a highly complex OS, if you simply load a driver and proceed to boot into Linux you run the risk of permenantly damaging the machine, possibly destroying the registry or the file systems.
OTOH we have some seriously smart hackers working on Linux these days. I'm pretty sure it'd be possible to build a program that suspended Windows and passed control to Linux that could be launched from the desktop, to get around this problem of needing to fiddle with BIOS settings etc.
Why is this relevant? Yacc and Bison are used by software developers, not end users. ANTLR isn't even a program, it's (iirc) a type of grammar.
If you're going to try and pick examples of bad software naming, go ahead there are plenty of them (Excel, Access, Windows ;-), but at least choose ones which are used by end users.
You don't know what you're talking about. GLib and GObject don't even depend on X, let alone a widget toolkit. GTK is built upon these libraries, but to say GStreamer depends on a widget toolkit is flat out wrong.
To be honest, the two don't really compete... mplayer is purely playback focussed. It has no pretensions as a multimedia framework, or anything of the sort. GStreamer is all about being a powerful multimedia framework.
It's easy to forget how much code sharing goes on between these projects. They are all liberally licensed, all import each others code all the time and swap codec implementations etc. This isn't like standard capitalist competition where people constantly reinvent the wheel in order to stay ahead - if mplayer has a codec the GStreamer guys want, licensing issues nonwithstanding they'll go and take it.
In fact, there is little out there to compete with GStreamer, at least on Linux. The nearest equivalent would be DirectShow on Windows which has nowhere as nice an architecture.
You're probably thinking that GStreamer duplicates Xine and MPlayer (though mplayer isn't really a library). To a certain extent it does - they all allow you to play back files, however GStreamer allows you to do a whole lot more.
Having said that, at the moment XineLib is more robust than GStreamer is, but the competition actually is spurring them forwards.
Seems smart to me...
I think you should compare the UI of Sound Juicer (an application dedicated to CD ripping) to the UI of audiocd:/ and then perhaps you will see what I mean. The file manager is not a generic catch-all UI for programs, it's for managing files. Abusing that to turn it into a CD ripper is just asking for sub-par UIs
So, why are more apps written using GTK/Gnome? I don't know. FWIW I feel the KDE framework is better too, but ultimately they are both pretty good. In particular GTK stands on its own more than Qt does on the Linux desktop - for apps that wish to remain desktop neutral it seems a more natural choice (and to be honest GTK vs Qt is a pretty even match, you can argue about the corner cases all day but I'd say they're just as good as each other).
Whenever I read the KDE API docs I can't help thinking what a shame it is - if the original developers had cared more about licensing we'd probably only have one desktop, and everybody would use these great frameworks. There'd be no problems with desktop neutrality, no need to slowly reinvent everything in order to make it desktop neutral and so on.
A lesson learned hard, and one I hope future developers will respect..... those who don't take community concerns over platforms seriously can seriously damage things.
So if nobody cared enough to integrate the KDE dialogs into GTK, doesn't that indicate that the people using GTK/Gnome apps are happy with the way things are (ie... they have a consistant desktop already perhaps?) more than anything else?
Yeah yeah, I know the standard argument ..."but Qt is so great it justifies the license fees and we all get paid so much anyway it doesn't really matter", but the fact is that it does discourage people - only a few days ago I was reading somebody on the GTKmm mailing list saying that he simply couldn't justify the cost of Qt for his development team (ah here it is - edit). My father runs a cottage software business. He can't justify the cost of Qt either. So, this is still problematic.
However, that doesn't matter for free software, which is like 99.9% of most Linux desktops anyway. A slightly more practical problem is that apps have to be ported to use this stuff, ie you can't just install QtGtk and have all your apps use the KDE dialogs overnight (nice though that'd be).
Still, I expect it will help in the short term.
Long term I'm really not sure how to solve this one - QtGTK is a nice hack but ultimately dialogs are currently a part of a widget toolkit, and especially considering things like customization etc it's really not trivial to abstract it.
Worse, it's really not easy to dlopen/dlsym C++ stuff like this, so you will end up with multiple builds of programs - one that depends on kdelibs and uses the dialogs, and another virtually identical one that doesn't. Having multiple builds of software for features like this is exactly what we are trying to get away from now - it only complicates the already overcomplex software installation process on Linux.
If we go down this route then we'll end up with loads of software with lots of duplicated dialog code. It's not so bad for just common file dialogs etc, especially considering that KDE offers more types of dialog than GTK does anyway (though i'd note not gnome libs et al), but it sets a worrying precedent.
A better solution IMHO would be to do the following:
The solution here is probably either to work on a shared desktop VFS system, or (politically somewhat harder) deprecate KIO and gnome-vfs in favour of lower-level systems. I've already been advocating doing the same for sound servers for some time now - this problem is simply not the desktops to solve.
Yes, that will mean that people on HPUX or whatever probably can't get network transparent file access. Boo hoo. Use a better OS if this really bugs you. Duplicating this functionality at a higher level simply causes fragmentation and people re-inventing the wheel.
This situation is complicated by the fact that KDE and GTK/Gnome don't share a HIG. Realistically speaking, this is a problem that needs to be solved on KDEs end - the current HIG is entirely non-descript and apps that comply with it simply resemble your average Windows app. It might not be a big issue, I don't know....
Well, you are pretty clearly violating the wishes of the respective owners of the software involved if you do that - guys, please, let's encourage people to act with honour ok?
The legalities of it are somewhat more involved I guess. I'd definately not advise anybody to do that, as it probably just shifts the copyright infringement from the software developer to the users. GNU software has been around for decades, if it was that trivial to work around it somebody would have tried by now.