●Stories
●Firehose
●All
●Popular
●Polls
●Software
●Thought Leadership
Submit
●
Login
●or
●
Sign up
●Topics:
●Devices
●Build
●Entertainment
●Technology
●Open Source
●Science
●YRO
●Follow us:
●RSS
●Facebook
●LinkedIn
●Twitter
●
Youtube
●
Mastodon
●Bluesky
Follow Slashdot blog updates by subscribing to our blog RSS feed
Forgot your password?
Close
This discussion has been archived.
No new comments can be posted.
Load 500 More Comments
Full
Abbreviated
Hidden
/Sea
Score:
5
4
3
2
1
0
-1
More
Login
Forgot your password?
Close
Close
Log In/Create an Account
●
All
●
Insightful
●
Informative
●
Interesting
●
Funny
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
byedivad ( 1186799 ) writes:
Choice, many times becomes really fast synonym of fragmentation and lack of standard.
And this is just a bright example. The situation described is 100% conforming to reality, as far as UI kits and sound infrastructure.
byiYk6 ( 1425255 ) writes:
Here is the great thing about having dozens of GUI toolkits, multiple libc, and several audio APIs. You only have to choose 1! Every time somebody complains about the "mess" of GUI toolkits, it just comes off as senseless whining. Where are the downsides? There are only 2 major ones, and if you don't have experience in either, just pick one.
The only downside I can think of is that end-users need several GUI toolkits installed, for their multiple programs that use different toolkits, but a) Linux still has a better features/size ratio than any other major OS, and b) Windows and Mac have the same problem (SDL, GTK+, etc, and the dlls have to be included with the binary downloads because Windows/Mac don't have an easy to use package manager).
Parent
twitter
facebook
byEnderandrew ( 866215 ) writes:
Correction, there are THREE major GUI toolkits for Linux. Qt, GTK and Wxwidgets.
byCarpetShark ( 865376 ) writes:
There are two majors: GTK+ and Qt. If you start counting WX, you also need to consider Fox, and fltk, and GNUStep, and EVAS or whatever Enlightenment uses, and probably some others I've forgotten about.
bygbjbaanb ( 229885 ) writes:
one of those will be Clutter - as used by Intel/Moblin. It looks good, but it based around Gnome libs.
byChunderDownunder ( 709234 ) writes:
Swing. While it's not a popular choice for Linux distros, I'd hazard a guess that there are as many in-house corporate desktop apps written in Java as those 'also-ran' toolkits.
byadamkennedy ( 121032 ) writes:
wxWidgets is mainly just a wrapper around GTK.
You use Wx when you specifically want your program to "look native" (without having to emulate it) across all three Win32/GTK/Mac platforms.
Yes, that means it has the idiosyncrasies of all three platform. And if your open source application doesn't have a development team large enough to deal with three separate applications sharing backend components, then it's a fairly cheap way to achieve both platform support and native look and feel.
I've used it a couple of times for exactly that purpose.
But if you're Google, and you can afford the programmers to support three forks with common components, then you don't pick Wx. You go straight to lower layer source and use GTK.
Parent
twitter
facebook
byEnderandrew ( 866215 ) writes:
wxWidgets has existed far longer than GTK. It isn't simply a wrapper around GTK.
bypdusen ( 1146399 ) writes:
It is when used on GTK systems.
From wxwidgets.org [wxwidgets.org]:
wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them.
byzsau ( 266209 ) writes:
In fact, wxWidgets lets you create a program that has a native look and feel on one platform, and a strong foreign accent on the other two. Now, that's better than using XUL on Linux or Gtk on the Mac, but it's not the same as native/native/native, and if you have a choice between the two, the best option is always to write the GUI three times.
(If it were native three times, then your conclusion—that you should write the GUI three times, if you have the resources—would be false.)
byNarishma ( 822073 ) writes:
wxWidgets is not a major toolkit in any way, especially compared to GTK and Qt. Very few applications use it (I can only think of Code::Blocks and the official bittorent client). Some like VLC recently ditched it in favor of Qt.
byProfane MuthaFucka ( 574406 ) writes:
It's also buggy as shit, and if you get into the code it's a less than easy to fix a problem.
bybelmolis ( 702863 ) writes:
I wouldn't omit Tk. It isn't used so much from C/C++, but is pretty widely used from Tcl, Python, and Perl.
●nt threshold.
byAnonymous Coward writes:
Does apt-get count as a relatively easy to use package manager? I've used it on both OS X and Windows machines.
The problem with having several GUI toolkits is that then you fragment the user experience. I use GIMP on OS X, and having X11 running makes it a very awkward, sometimes annoying experience - not only do I have to make sure I'm properly in GIMP rather than X11, but all the keys change command button to control button depending on which one you're in. It's really pretty awful, and I expect non-techy users to find it more confusing than I do.
Consistency is important to a user experience. Learning how to complete tasks in an OS is very much like a language skill. When you force people to learn different sets of hot keys, different ways of achieving the same task, then you're burdening them with another language. The only good reason to break away from having a single HIG standard, as far as from the user's perspective, is if you're writing a really novel application where you're trying to provoke a different mindset; writing yet another average GUI toolkit doesn't come close to qualifying.
Parent
twitter
facebook
byjedidiah ( 1196 ) writes:
It's better to have a robust tool than a pretty one.
That's what this ultimately boils down to. One set of users would rather
that the tool be robust. Another would prefer that all of the minor details
conform to all of the other apps you're likely to find.
The crude redeye reduction tool in iPhoto when compared to the redeye plugin in GIMP is an excellent example of this contrast.
bynomadic ( 141991 ) writes:
Where are the downsides?
Are you smoking some form of new, experimental, highly-potent form of crack? Are you seriously asking this?
It's not an issue of "omg too many choices," it's an issue of lack of standardization. Want to download software you need? Better hope it supports your package system, and better hope it was made for Gnome or GTK or whatever you're using. The messed up patchwork of packages that constitutes sound on linux is an embarassment, and sure, pick 1, then hope the software yo
byPeterBrett ( 780946 ) writes:
Want to download software you need? Better hope it supports your package system, and better hope it was made for Gnome or GTK or whatever you're using.
Usually, when I download software I need, it comes with some clever bash scripts that detect my compiler and what versions of libraries I have, and configures a custom build of the software for my specific needs. It's quite remarkable!
Snarkiness aside, I happily run KDE apps on a GNOME desktop & GNOME apps on my KDE desktop. What's the big deal?
bynomadic ( 141991 ) writes:
Usually, when I download software I need, it comes with some clever bash scripts that detect my compiler and what versions of libraries I have, and configures a custom build of the software for my specific needs. It's quite remarkable!
Astounding! Your experience is diametrically opposed to that of myself and many, many other linux users. On many, many, many occasions I have seen ./configure fail because the libraries gcc needs have a slightly different version number. And even when autorun successfull
bywalshy007 ( 906710 ) writes:
I think you mistook what your parent meant, in regards to pick one he was meaning for the developer to pick one, not the user. The user could have them all installed if they like.
Better hope it supports your package system, and better hope it was made for Gnome or GTK or whatever you're using
gtk and qt applications can run on the one machine simultaneously, so not an issue. As for sound if the distro has it's shit together it should support pretty much all of the different standards out there out of the box.
creating a simple tarball or zip file which has a linux program that runs on almost any distro that has the same
byAnonymous Coward writes:
So whats the difference between an msi and a package manager? They both copy files and check versions?
Hell, Chrome runs portable without an installer even.
As a GUI developer who's lived in both worlds Google has a serious point, linux lacks some solid fundimentals even with the alternatives.
byc_g_hills ( 110430 ) writes:
The closest thing Microsoft Windows has to a package manager is software deployment through group policy, which is only available in an active directory domain. It provides for a central place to both push out software to groups of computers and users, and allows users to install packages for which they have been assigned privileges. The latter I have not seen implemented by any Linux distribution yet. It is a case of having the privilege to install any software, or none at all. In comparison, Linux distrib
●ent threshold.
byKjella ( 173770 ) writes:
Here is the great thing about having dozens of GUI toolkits, multiple libc, and several audio APIs. You only have to choose 1! Every time somebody complains about the "mess" of GUI toolkits, it just comes off as senseless whining. Where are the downsides? There are only 2 major ones, and if you don't have experience in either, just pick one.
I don't know if it's just me that keeps running into these wtfs, but if all of them worked from the user POV then I'd agree with you. Reality is that sometimes pulseaudio works, sometimes it works if I redirect it to ALSA, sometimes for no good reason I have to pick OSS output - that on modern Linuxes maps to ALSA, but for some reason that works and ALSA doesn't. Sometimes if I'm running multiple sound-using apps I get complaints that it can't open the audio device and so I have to close something else, even though everything should support mixers since many years ago.
It usually runs decent if you run say only KDE apps, probably the same for Gnome - but if you start mixing kde and gnome apps, virtualbox, wine and closed source then my experience is really bad. Still, it looks like a decent toolchain is emerging:
Phonon - high-level cross-platform API - "Play me this MP3 file"
GStreamer - plugin layer for all the good/bad/ugly formats, not the one true decoder - "I took the MP3 and decoded it, here's the sound"
PulseAudio - sound (re)direction to speakers, headphones, network+++ - "Preferences say this sound should go on the headphones"
ALSA - actually deal with the hardware and reveal playback/recording capability - "Headphones - play this"
It's not like all these pieces of the audio system does the same thing, when they're trying to show that it's so very confusing they overcomplicate a bit. There's a fairly one-directional workflow from the application towards the hardware, and if you displayed them as a layer diagram (with some blocks possibly covering several layers) then it wouldn't look nearly as bad.
Parent
twitter
facebook
byXabraxas ( 654195 ) writes:
The sound issues everyone bitches about are purely distribution issues. I have been using alsa/dmix for years now with no sound issues. I don't have pulseaudio or any other sound server installed. Sound mixes properly without blocking other applications. The real problem is pulseaudio. Not everything supports it and it is buggy as hell. Unfortunately a lot of distributions include it as the default sound server. The only advantage it seems to have for average users is the ability to adjust applicatio
byMLS100 ( 1073958 ) writes:
Unless what you mean by 'distribution issues' is that there is more than one distribution, then it is certainly not just a distribution issue.
The real issue is when a developer goes to develop a sound application for Linux, and he has absolutely no idea what sound interface his users may be using. So he either attempts to support them all, which is a nightmare when he's getting bug reports from users of 5 different sound interfaces which have 3 different major revisions possible each, that have 30 different
byXabraxas ( 654195 ) writes:
Maybe you missed what I said. ALSA works without a hitch. All modern Linux application support ALSA. OSS can also be emulated with ALSA but OSS hasn't been used seriously in Linux for years. The issue is PulseAudio. Distributions depending on Pulse use it to mix and that becomes a problem when an application has only an ALSA interface and not a Pulse interface. Audio blocking is the result of this conflict as an application attempts to take control of ALSA over Pulse. EVERYTHING that I have used in t
byKjella ( 173770 ) writes:
The sound issues everyone bitches about are purely distribution issues.
Because you've found a setup unlike anything in a mainstream distro and tagged it WORKS4ME, it's purely a distribution issue. *adds another decade to my "Year of Linux on the desktop" estimate*
byXabraxas ( 654195 ) writes:
Maybe I'm out of the loop because I don't distro hop but do all of the major distributions really ship PulseAudio as the default? I say this because ALSA has worked quite well for a long time now and I've been using it consistently since before PulseAudio was the default in any distro. I still contend this is an issue with distributions. It's not a "works for me" argument. ALSA works and it works well, the distro's that default to PulseAudio are fucking things up. This isn't a Linux issue in general.
byjedidiah ( 1196 ) writes:
No, it sounds like YOU have found a setup like anything in a mainstream distro
and tagged it "doesn't work for anyone". ALSA has ruled the roost for quite some
time now. Some distributions are migrating to pulseaudio but it's still not clear
where the real problems (if any) really are.
There's a lot of FUD and noise surrounding pulseaudio but usually not much if any details.
Linux Sound is something that people like to whine about without providing actual
examples, actual problems, use cases or test cases.
People
bywalshy007 ( 906710 ) writes:
I also used dmix with alsa for quite a long time, waited about two years after pulseaudio was introduced to my distro to switch to it, and I think my timing was about right, they seem to have solved most of the issues.
while I agree pulseaudio can be retarded at times, I don't see why people are having so many problems in general.
byElrond, Duke of URL ( 2657 ) writes:
The reason PulseAudio is important is that it is a user space solution and this is important because audio choices have expanded considerably in the past ten years. There needs to be a simple(ish) GUI method of handling this nest of connections.
For example, on my PC I've simple on-board audio (intel-hda, I think) with four speakers and a pair of headphones. That's not hard to manage and I can actually do well with just ALSA (though ALSA isn't smart enough to handle speaker muting when I plug in the headph
byalexandre_ganso ( 1227152 ) writes:
again: http://img46.imageshack.us/img46/4962/linuxaudio.png [imageshack.us]
byfsterman ( 519061 ) writes:
This sounds like trolling, I know, but neither does Ubuntu. The package management system sounds great until you put someone in front of it who can screw it up- namely me!
Which is why I am a usability engineer [mozilla.org], and tried applying for the Ubuntu Add/Remove [openusability.org] usability testing internship : )
byapoc.famine ( 621563 ) writes:
As an addendum to this good point:
The reason we have so many choices is because....the users and developers want choices. OSS choices exist almost by definition because people are choosing them. To say, "your choice sucks, choose a better one" is ridiculous. Google is showing off the corporate mentality here. If you're not paying the thousands of developers of the toolchains for the major (and minor!) distributions, you don't get to complain about what they're producing. If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.
There are choices because they all have something to offer to someone.
Parent
twitter
facebook
bySirLurksAlot ( 1169039 ) writes:
If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.
Therein lies the problem. What defines a platform as "superior?" Does superiority simply mean that it does A, B, and C extremely well? If that is the case then you will ALWAYS have someone that says "Well yeah, it does A, B, and C, but what about D, E, and F?", and they'll go out and try to make their platform superior (Because, you know, D, E, and F are really important to them, and
byBurz ( 138833 ) writes:
The reason we have so many choices is because....the users and developers want choices.
But the userbase has not moved much beyond the sysadmin and system developer circles. These developers are mostly doing wheelies trying to impress their peers, not their potential novice end-users. They code for themselves and take great care with, for instance, APIs used among their peers--- but UI's are handled very sloppily and they squirm out of maintaining UI feature stability for the user by calling for "freedom".
Funny that... When you get below a certain level (say, to the kernel + GNU) then preventi
bybwashed75 ( 1389301 ) writes:
Quite a few of the choices are there because any application developer is forced to make choices from all the choices already out there.
Lets say I want an application with features XYZ. I go looking and find a large number of application with feature X, a large number of application with feature Y, a large number with feature Z. However, as the applications are spread out across different framework, GUIs, distros, personal coding styles and whatever, and since standarization is for suckers, I have a ha
byMgccl ( 1380697 ) writes:
http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html [ted.com]
funny, because most of the time, choice only make people less happy...
People think when they chose something, they become more happy, when it is likely... completely the opposite.
byCrystalX ( 1299317 ) writes:
If you want standardization, you don't bitch about it - you make your platform of choice far superior to the other options.
An an individual (of the normal or the corporate variety) it is difficult to muster the effort needed to make a superior platform when you have to do it without compensation (i.e. for free).
This is especially the case for near OS-level services such as GUI toolkits and global sound APIs, which require an incredible amount of effort to develop and maintain.
byWrath0fb0b ( 302444 ) writes:
SDL, GTK+, etc, and the dlls have to be included with the binary downloads because Windows/Mac don't have an easy to use package manager.
Please, please, please stop with this stingy attitude towards distributing libraries. We have megabits of bandwidth and terabytes of disk space and yet there is an almost herculean effort made to economize a few GB by using dynamic linking where it's not strictly needed. The time and effort spent on these measures dwarfs the extra download times associated with statically linking as much as humanly possible.
As much as possible, every application should be entirely self-contained and reliant only on system c
byturbidostato ( 878842 ) writes:
"Please, please, please stop with this stingy attitude towards distributing libraries. We have megabits of bandwidth and terabytes of disk space and yet there is an almost herculean effort made to economize a few GB by using dynamic linking where it's not strictly needed."
For the most part you don't "reuse" libraries because of storage space but in order to reuse the code.
"I will gladly sacrifice any amount of diskspace not to deal with my package manager and insane requirements."
But would you gladly sacrif
byWrath0fb0b ( 302444 ) writes:
For the most part you don't "reuse" libraries because of storage space but in order to reuse the code.
Then distribute the library with the application or statically linked into the binary.
But would you gladly sacrifice having a security hole and instead of correcting at one place and then have corrected all apps that use it having to upgrade each and every program that happens to use it and then not knowing if per chance there's still another copy hidden overthere?
Most apps are updated fairly often anyway. Let them reuse the Firefox updater, which I think is the perfect example of usability and transparency -- if there's an update, grab it and apply it on next launch. No problems whatsoever.
byBlakey Rat ( 99501 ) writes:
The Firefox updater is a pain in the ass.
When I double-click the FF icon, it's because *I want to browse the web*. What FF has created is a program where double-clicking the icon will, 98% of the time, allow me to browse the web in seconds, but 2% of the time it takes several minutes to begin browsing the web.
That sucks.
●r current threshold.
byspitzak ( 4019 ) writes:
Thank you.
This is in fact why "installation" works on Windows. It has nothing to do with Windows itself, it is because programs include all the libraries they need!
There is a switch to the linker that makes a linux executable act as though LD_LIBRARY_PATH starts with the directory the executable is in. This should be turned on ALL THE TIME by EVERY PROGRAM IN THE WORLD (in fact it should be the default). If you want to say something technically correct about Windows, you can say that it does act this way by
byAnonymous Cowpat ( 788193 ) writes:
mod up! mod up!
When I download X piece of GPL software, I don't expect the documentation to tell me that it depends on Y piece of GPL software which they want me to go download myself.
byAmorya ( 741253 ) writes:
Wow! Someone gets it!
Statically linking libraries means I know that the vast majority of Mac apps will work without me needing to install anything else. (If an app needs support files, it is official best practice to bundle the files inside the app and have it install them on first run.)
I have no such guarantee on Linux.
byturbidostato ( 878842 ) writes:
"I, for example, prefer using Awesome WM for my window manager. However, if I want to run the majority of useful software out there, I need to install a good portion of Gnome and/or KDE."
So what? That's nothing more than cheap disk space.
"You can tell me to settle on one, but then I'm giving up functionality I want or need. I need to have at least three in order for the OS to be useful. "
So what? Using some toolkit, WM, etc. was not your choice but that of the developer. Maybe he chose what he chose for a
byThe Spoonman ( 634311 ) writes:
So what? That's nothing more than cheap disk space.
A) I have a Netbook with 8G of flash drive space. It's neither cheap, nor spareable. B) No, it's not just drive space. When you launch a KDE app, for example, kdeinit, dcopserver, klauncher, kded will launch, too. So, now it's impacting my memory and performance.
So what? Using some toolkit, WM, etc. was not your choice but that of the developer.
Not just his, but the choice of the toolkit developer who decided that they didn't like the way the
byturbidostato ( 878842 ) writes:
"So, now it's impacting my memory and performance."
I'll give you that point.
"Not just his, but the choice of the toolkit developer"
Not at all. The fact that Gtk+ exists doesn't force any developer to use it.
"who decided that they didn't like the way the others did it"
Even given that, maybe they did it for a reason. Are you in the position of validating their reasons better than them?
"GTK, Qt...they all do exactly the same thing: put widgets on the screen. There's no reason to have so many aside from a fal
bySycraft-fu ( 314770 ) writes:
There are issues any time you make a choice. As an example, take audio on Windows which is in a vastly better state, and something I understand quite well. Windows itself provides APIs for audio you can use. Any soundcard with a Windows driver will by definition support these. However Windows allows for other APIs to be installed. There are two major ones you'll run across:
1) OpenAL. This was developed by Creative Labs because they wanted better support for hardware sound acceleration, which is something th
byAndreas Mayer ( 1486091 ) writes:
Hand b) Windows and Mac have the same problem (SDL, GTK+, etc, and the dlls have to be included with the binary downloads because Windows/Mac don't have an easy to use package manager).
Not quite sure what you are talking about, but ... applications on Mac OS X generally do not need to include any GUI toolkit. The toolkit is part of the OS.
That's also the reason there is no package manager - because you don't need one.
(Applications that use a non native GUI toolkit - like GTK+, wxWidgets etc. - will run into the problems you described. But those are not the norm on OS X. And they stick out like a red headed stepchild anyway.)
byAlexanderTe ( 1557041 ) writes:
[start of senseless whining]
You got modded insightful for this? It bugs me a lot when there's a post like this in a discussion, it gets modded high, and people swallow it without even thinking. Here's your very own arguments, rephrased:
Pros:
You only have to choose one.
Cons:
End users need several GUI toolkits installed.
Discussion:
If there's a standard, you only have to choose one as well. Your only valid point is about the end users that needs several GUI toolkits installed, which you categorized
●ur current threshold.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Slashdot
●
●
Submit Story
It is much harder to find a job than to keep one.
●FAQ
●Story Archive
●Hall of Fame
●Advertising
●Terms
●Privacy Statement
●About
●Feedback
●Mobile View
●Blog
Do Not Sell or Share My Personal Information
Copyright © 2026 Slashdot Media. All Rights Reserved.
×
Close
Working...
Working...