Slashdot Mirror
Harsh Words From Google On Linux Development
jeevesbond writes "The alpha version of Google Chrome is now available for GNU/Linux. Google Chrome developer and former Firefox lead Ben Goodger has some problems with the platform though. His complaints range from the lack of a standardised UI toolkit, inconsistencies across applications, the lack of a unified and comprehensive HIG, to GTK not being a very compelling toolkit. With Adobe getting twitchy about the glibc fork and previously describing the various audio systems as welcome to the jungle, is it time to concentrate on consolidation and standardisation in GNU/Linux in general, and the desktop in particular?"
They argue, and I would not say that they are wrong, that GTK+ even so does not give the necessary functionality to allow all the Chrome features.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
I will squirt it up for you: here. Alternatively, you could have binged it.
Ezekiel 23:20
Taking two seconds to skim the article you can find this link to the actual discussion board thread.
God, schmod. I want my monkey man!
This reminds me of something that I read a while ago, when world of goo was released for linux, the developers had some trouble as well, but that time the culprit was pulse audio.
Follow the discussion, and you'll find it's not about complaints at all, at all, at all. Google is trying to figure out the best way to do Chrome for Linux, while making it something that Linux users will actually like, and that means more choices. That's all. No, it's not about needing to standardize, so could someone at Slashdot quit with that FUD? GNU/Linux is about choice, and it always will be.
Well, then, make a standard that doesn't suck. That is what I was saying.
What they are talking about (HIG) is only a "guideline" for programmers to follow. You know, for programmers who would otherwise get it wrong (using dropdowns when radio buttons would be more appropriate, using editable textboxes just for displaying information, etc.). It is not supposed to be a concrete "thou shalt do it this way or else" document.
Otherwise, you are not leaving the "user experience up to the users" anyway... you are leaving the user experience to programmers who don't know how to do interfaces.
I guess the guy that used to be the lead developer of Firefox may know better than you and me.
Perhaps the problem is that the lead developer of Firefox ignored that HIG in making Firefox. From Wikipedia: "Mozilla Firefox's user interface, for example, goes against the GNOME project's HIG, which is one of the main arguments for including Epiphany instead of Firefox in the GNOME distribution." No doubt there were reasons for the choice taken in Firefox development, but the consequences include a lot of bloat and reinvented square wheels.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
What is really going on is that they have wrapped a new layout engine ("views") and other tools around the "impoverished" (their words) Windows toolkits. Then, they started depending on their wrapper for features they added to Chrome. Now, when porting to Linux, they are suddenly discovering that, geez, both Gtk+ and Qt already does what "views" is doing, they just do it differently and in a way that doesn't connect well with the rest of Chrome. That's what they are complaining about.
Ben Goodger, here's a hint: pick Gtk+ or Qt as your toolkit, Linux users really don't care that much. And both of them are much better toolkits than what Windows offers. I'm sorry that the completeness of Linux GUI toolkits inconveniences you, but, well, too bad.
Or, if you like, don't port to Linux; we don't really care all that much, since there are several great browsers on Linux already that pretty much do what Chrome does.
They're two very different things. One is the open source PART of the chrome browser, the other is a browser binary, built in part on the Chromium source, that reports usage information back to Google, one subset of this being non-optional. Please don't get these two confused, no matter how much clueless reporting there is on the relationship between the two. The latter is, in my opinion, a privacy leakage too far.
Resistance is futile. Reactance buggers it up.
If only the Linux Standard Base existed! Oh, wait, it does!
http://www.linuxfoundation.org/collaborate/workgroups/lsb
That is why Skype can build a distro-agnostic package with static linked libraries that just works on every distro, even though they also make distro-specific packages as well.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Dude, Qt is _way_ more than a "widget toolkit". In fact, "linux" could do far worse than standardizing on it. Do not compare it to gtk, they are not in the same leauge at all.
There simply is no benefit because PCs without Windows on them won't sell very well. Most people who buy computers barely know where to click and are totally confused by new operating systems. All they know is Windows, so that is what they will buy. It's very hard to get past that.
-- Cheers!
GNOME has human interface guidelines and has had them since 1.0. If Ben Goodger is bitching about GTK+/GNOME not having consistent UI guidelines, it's because it's not consistent with whatever his vision is. In my opinion, GNOME is a heck of a lot more consistent than MacOSX's Steve-Jobs-whim-of-the-day, and-- let's not even get started on the Windows UI fustercluck. Of course, if he's talking about KDE... well, OK. KDE's interface is... odd.
I have an old GTK book somewhere that says that the developers based their HIG on the original Macintosh HIG (that the MacOS now no longer follows), which was actually based on user-feedback and also based in part on the Xerox Star. That's a pretty long lineage when it comes to GUI.
The complaint about Mozilla having a functionless 511MB executable after switching to GTK+ has nothing to do with GTK+. GTK+ is not exactly lightweight, but it ain't exactly a bloated beast either.
Complaints about audio are well-founded, though. Audio in Linux still sucks.
> Chrome should have been built on top of Qt from day 1.
RTFA.
He did call for it to be built on top of Qt, not KDE. I know better, and honestly can't tell you why I typed KDE instead of Qt.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
A standardised API doesn't mean that there can only be one operating system, it just means there's a generally accepted way of making the operating system do what you want without having to alter your code for every different platform.
How many people can read hex if only you and dead people can read hex?
... that means binary compatibility must stop being broken from OS update to OS update.
It's simply the arrogance of Linux developers that have crippled Linux adoption.
IMHO, this is the biggest barrier that keeps commercial development out of Linux. Basically, the Linux philosophy assumes that all applications are open source, so it doesn't matter if the ABI changes with every point release of the kernel, since the distros can just recompile all their binaries when packaging. This philosophy is incompatible with the commercial software method of distributing apps as binary blobs.
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.
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.
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
I have to agree with you.
Gnome came in existence because the purity police didnt like the non-free Qt widget toolkit. (how ironic is it that its founder Icaza is now on the other side and being attacked for his hardon for mono in the same way? Poetic justice.)
It seems that even though QT is now under a free software license, a lot of the old bias still exists.
I like the fact that we now have the best of both worlds with QT, both a free software license and
that the phone leader Nokia bought Trolltech because it wants to use QT for cross-platform software for mobile devices as well as desktop applications,..
You can use Qt on platform like X Window Systems,
Mac OS 10, Java, Windows and CE, embedded platforms like smartphones.
Just looking at my sytem quickly, here are few apps that are using QT: Skype, VLC, Opera, Virtualbox, Scribus, Avidemux, Mythtv, Google Earth, Xconfig and Launchy.
Its all a question of taste, opinion and choice.
I might not agree with your versions of the first two but the third one is the reason why i work develop free software on my own dime/time.
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.
That's a pure twisted view of reality. First, the *nix environment was never supposed to go PC. Besides, the forkings were a pure necessity as you were dealing with systems for specific tasks. It was a hardware/software symbiosis and not selling computers to every freak on the street.
Windows came into force not because it was the attractive place to develop but the only one. IBM made a pretty good mess out of its OS/2 to be something workable for the lay user (not without the help of M$ btw).
Linux rose up in the end of the 90's, when Windows had the total and absolute monopoly on everything PC. So, in fact Windows IS loosing its position, not winning it. Yes, it lost 1%. But lost it and Linux is still here.
About binary compatibility... That's pretty heavy one. Frankly, have you ever used Linux in a working basis? I haven't had no binary compatibilities for years and I am a Linux user since 1998 (and admin since 1994). What compatibility are you talking about?
Really I don't use Windows anymore, except for some pretty rare games I play once in a while. But just an year ago I had to deal with a horrible mess on a Windows server. I was pretty amazed to see the same problems, the very old same way, as I saw several years ago - upgrade and we go boom.
I don't know, maybe Microsoft finally solved this 20-year old problem for the last year I have not been touching Windows? Really? I doubt.
the root of the issue is necessity. The point of linux is the definition of what linux is. If you run software on a Linux kernel, its Linux. That's why no one standardizes anything more than that. now if you thought standardizing anything in userspace is necessary, join the LSB, otherwise, stop bellyaching and pick one. If you can't choose, you're thinking about it. My primary example is that somebody has already made chrome for linux.
We already have this universal coordination - we all use the same kernel, even if some people use a slightly out of date version. The filesystem APIs are the same too. similarly, we all write sockets in the same way.
There's no reason why we can't have similar interfaces to an underlying GUI framework API (that is a bit higher-level than X)
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.
Live today, because you never know what tomorrow brings
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
Qt actually runs the glib event loop these days. You can easily verify this by kill -ABRT'ing a kde app and checking the core dump; this just in from kate:
#8 0xb5df874b in IA__g_poll (fds=0x9c225c8, nfds=6, timeout=25243) at /build/buildd/glib2.0-2.20.1/glib/gpoll.c:127 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2761 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2511
#9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at
#10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at
#11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323
Save your wrists today - switch to Dvorak
You obviously don't know jack shit about Operating Systems.
The UI is a layer of abstractions on top of the OS. Once a UI is ported to an OS, the differences between OSes are (hopefully) concealed from the end user. They are still there though. If you use GIMP or Pidgin on Windows, did your computer become Linux because you now have GTK libs? No. And a ton of effort (years in fact) went into making GTK work on Windows seamlessly. VLC moved from GTK to Qt, did the OS change any at all? No... because the UI is not the OS.
And this is the problem, multiple OSes using multiple toolkits, witch each element having it's own quirks. For each platform you have to work around differences in the OS, differences in the toolkit, and differences in the toolkit for each OS because of their workarounds.
But the fact is that if you use it on a GTK desktop, people will notice, and such is life that GTK is the de facto standard.
Qt apps actually look like gtk apps on Ubuntu Jaunty (Qt 4.5). This is a relatively new development, so you are forgiven for making the false assumption here ;-).
Save your wrists today - switch to Dvorak
Win32 is the Windows API. MFC is a library consisting of shortcut functions to do larger things with the Windows API. .NET is a framework for languages like C# and Visual Basic that ultimately translates everything to the Windows API.
Hence there's still one standard: the Windows API. Everything else just builds on top of it.
I mean if I am a hardware manufacturer it takes just three drivers if I want to support Windows past, present, and future with a binary driver. Four if I want to cover the niches. I just have my developers write a Win98/ME, A win2k/XP, and a Vista/Win7. I add a WinXP64/Vista64 and since Win7 can use Vista drivers I have everything from 1998-2014 completely covered with just four binary drivers and no more out of pocket. There just ain't a way to do that in Linux.
There's a much easier way. Send a message to the kernel list saying, "I am a hardware manufacturer. Here are the docs for my hardware under NDA, and here's some samples." Ta-da! You get drivers written for free (or significantly reduced), and every subsequent distro release will support your hardware by default.
Pirate Party UK
Now you're clearly trolling/FUDing. There are plenty of proprietary apps for Linux, either as drivers (Nvidia) or as userland software (mostly for servers), and if you are merely using FLOSS there are hardly any restrictions at all. When was the last time you saw a EULA when you installed a FLOSS application?
The reason companies don't target desktop Linux is because it's only a tiny fraction of the market. The GPL has nothing to do with it. It's business, plain and simple.
This sig is intentionally left blank
Yes, when distributing binaries one must target not only a specific distribution, but a specific release and a specific CPU architecture as well.
This is not true. If you make a binary installer with your own link libraries for all of the dependencies you need, you can successfully make a closed-source release which works on just about any kernel since 2.6 with the correct architecture. The Linux userspace ABI is very stable.
If you want to use open-source libraries that would make such a binary blob legally difficult, that's your choice.
Pirate Party UK
So far, Ubuntu has the fewest questions, without sacrificing any flexibility.
The only time I use Windows is when I have no other choice.
original thread
Simple things like playing an AVI or a VOB file?
There are plenty of little things to get bogged down with
on a Mac simply because the developers didn't think of them
or they're fixated on their particular way of doing things.
The Mac is good for being a complete package, that's sold
by some sort of PC OEM. It's also good for not being a
menace when it comes to security.
Beyond not being the Microsoft-style malware playground,
the whole UI niftiness thing is remarkably overrated.
The context menu on a network drive in Windows gives me
the option to map it to a local drive so it will be
remounted on the next reboot. The Mac equivalent lets me
pick a tink color for the icon.
A Pirate and a Puritan look the same on a balance sheet.
Won't happen, because either some free software believer will "leak" the docs to some place like wikileaks, or you will see half the software developers scream in true RMS style "NDAs are the devil! Information wants to be free!" or some such rot. Most companies are NOT going to give their specs and docs to anyone outside the company-period-full stop. If that is what it takes to have a driver for Linux? Then you simply won't have drivers. Kinda like now.
What they WILL do is be quite happy to write you a binary driver if they know they can "write once use forever" like they can with Windows. The last all in one I picked up had a Win98 driver, as well as 2K,XP, and Vista. looking at the dates on the Win98 driver they are from 2001. Hell the XP drivers are from 2003. Can anybody here even imagine a device driver circa 2003 working without ANY need for tweaks, hacks, updating, or recompile in Linux?
And THAT right there is the problem in a nutshell. It isn't the big bad MSFT, who boned themselves real good with fucking up backwards compatibility in Vista, it isn't the OEMs like Asus who are dropping Linux, it ain't the mom & pop shops like me that would be happy to carry Linux boxes if it wasn't a support nightmare from hell. it is the fact that the margins on all those little devices that everybody seems to have sucks, and spending money constantly having to have developers tweak or recompile them for Linux isn't money well spent. If they only support Windows they can have developers only write four drivers and then put them on other projects while selling that device for years. With Linux everything from the kernel up is in a constant state of flux and things are getting broken pretty much constantly. Just go to the Ubuntu forums after a release and see how many "The update totally broke device Foo" posts there are.
So to me it seems pretty simple. The Linux users and developers need to get together and ask themselves a single question: do you WANT to have decent marketshare? If the answer is yes then you HAVE to support all those doodads being sold out of Best Buy, Walmart, Staples, etc. You can't write all those yourselves, it would be too costly. you NEED the hardware manufacturers to support your OS. And they will never do so until they can have a "write once, use forever" driver model like they enjoy on Windows. So get together and decide on a stable, backwards compatible undercarriage that anybody can write a binary to and be done with it. Do that and you'll have OEMs and mom & pop shops like mine selling Ubuntu boxes right next to the Windows ones. But without those manufacturers on your side you will never get any marketshare, and right now writing drivers for Linux is like trying to hit a dartboard with a live bumblebee. Is it any wonder why guys like Asus have stopped trying to sell Linux to home users?
ACs don't waste your time replying, your posts are never seen by me.
Somebody didn't RTFA (I know who expects you to, really). I will distill it down for you:
Chrome on Windows: Hacked to be funky and unique, non standard libraries for rendering, etc.
Chrome for Mac: Easy to replicate windows experience using standard OSX API's.
Chrome on Linux: Clusterfuck, standard API's are not standard, and not good enough. Hacks will not be cross platform, difficulties everywhere.
Basically the question was posed: Do we even bother to try and replicate the windows chrome experience? Or simply put our fast little engine inside a totally different visual experience?
Firefox and Opera use their own.
Opera uses Qt.
Programming on Windows is easier? Seriously, I just can't let that go.
At work, we have a codebase that compiles on Sun, Linux, and SGI fine, and mostly compiles on that monstrosity known as Windows. I'm sure that most of our issues working with Windows stem from the fact that the system started its life on UNIX and was ported to Windows, but that's no excuse for some of the issues we face:
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Yes, because the NT kernel is functionally identical to the Linux kernel. If anything, it's more advanced in some areas. For instance, the kernel used in Vista can relaunch video drivers on-the-fly.
Vista is not just the kernel - the kernel is tightly tied in to the user space code. For example, the video driver relaunching? That's not the kernel... the bit of the video driver being relaunched is a user-mode program, communicating with another program that does the graphics rendering, window management, etc. (This is the main difference from Linux - it can restart the video card driver if it crashes, but it takes down the desktop and all the apps you have running on it too.)
Sure, the Vista kernel may be quite nice... but there's no way of using it without dragging along the entire Vista userland and GUI. (I'd call the Vista/XP/NT kernel overdesigned rather than good, myself. Lots of unnecessary complexity.)
For all practical purposes, KDE on Windows is indistinguishable from KDE on Linux. Notice that word: "practical".
Nope. KDE on Linux has the KDE window manager (with different window management behaviour, title bars, effects, etc) and the KDE desktop. KDE on Windows uses the Windows window management and desktop.
a) Decide once and for all; client or server? If client, (which is what the desktop is) embrace that completely. Tell anyone who wants UNIX that they need to move to *BSD.
b) For sound, return to OSS. v4 is under the GPL now, so there's no reason not to. ALSA is over-engineered, unstable garbage. Get rid of it.
c) Standardise around GNOME. For my money it's the least bloated of the big two. In terms of features, truthfully I probably like KDE more, but it needs to lose weight before I'd advocate it.
d) Stop standardising around Debian, and stop listening to whoever keeps telling everyone to do so. Debian/Ubuntu are the two most poorly designed Linux distributions in existence. If fanboys want to respond to that, fine, but if I list my issues with Debian, I expect you to respond to me on those issues specifically, without simply resorting to the old standby of telling me that I'm ignorant.
e) Standardise around pkgsrc for package management. It's portable, it's solid, it has a lot of features, and it's written by people who, unlike many Linux developers, both care about design quality AND can actually code their way out of a wet paper bag. Do not listen to Debian fanboys who attempt to say otherwise.
f) Stop caring AT ALL about what the FSF thinks. If nVidia only distribute binary drivers, people are going to want them, period; and are going to use them, irrespective of what the cult decrees. I also don't want to hear from FSF cultists in response to this, either. I don't agree with you now, I'm not going to in the future, I think your organisation is a disease, and is the single worst thing about Linux, and I'd be much happier if it didn't exist, putting it bluntly; so don't bother.
g) If money is what it takes to cause FOSS developers to get serious, then so be it. Relicense under more commercially friendly licenses, (like the BSD license, for instance) and form companies around the relevant applications.
h) If the desktop is where the Linux community has decided it wants to go, Linus needs to be brought into line with that vision. At the moment, he is primarily concerned about big iron, because that is what the corporate hands that feed him primarily care about. If you want the i386 client desktop, that is where you need to put the entirety of your focus. Forget portability, forget the server, and focus purely on being an i386 client desktop. You're not going to get there any other way.
There is no universal standard GUI toolkit on Windows either. Firefox and Opera use their own.OpenOffice.org uses its own. Even Microsoft Office uses its own.
There is a universal standard GUI toolkit on Windows. You just happened to cherry-pick applications that don't use it.
On the Mac, there is even more GUI dissonance. Current Macs make the typical Linux environment look downright uniform.
WTF? Seriously. WTF? Either you've never used a Mac, or you've never used Linux-- I'm not sure which.
Why is this always considered a problem on Linux but not on Windows or on the Mac?
Because your first sentence was wrong. Windows and Mac have universal standard GUI toolkits. They both have visual IDEs that'll set up the menus and controls to be positioned correctly by default. (Does the Linux world even have visual IDEs for window layout... at all?)
Comment of the year