Three Monkeys, Three Typewriters, Two Days

January 27, 2008

The march of progress strikes again

It looks like we now support using the GTK print dialog on Linux. The only catch is that this imposes GTK2 2.10 or higher as a hard build-time requirement. It's still possible to run trunk nightlies against a lower GTK2 version, as long as you don't try to print or print preview or open page setup, or call window.print() in JavaScript. If you do try any of these, you get a nice

symbol lookup error: libwidget_gtk2.so: undefined symbol: gtk_print_settings_new
followed by the program exiting.

What this means in practice for me is that I can no longer compile on my slow (performance testing) machine, and can no longer run trunk builds for my day-to-day browsing. I might be able to work around the former by building on my development machine and then copying the builds over, as long as I don't do any performance testing on printing code.

I did look into upgrading GTK2, but it looks like going from 2.8 to 2.10 involves one of these fun "we'll rearrange which files are in which RPM" things Fedora/RedHat love so much. The GTK 2.10 RPM one gets after compiling the FC6 SRPM conflicts with the redhat-artwork RPM, and it looks like half the world depends on redhat-artwork, so it can't be uninstalled. I did try installing the GTK2 2.10 RPM with --nodeps --force on my development machine, and that sort of works. There are various of cosmetic issues (e.g. completely invisible menuitems) that I'm willing to accept on the devel machine, but not on the box I actually use for most of my work.

And yes, I could try to do an OS upgrade on my desktop machine. I'll do that right after I finish my thesis, probably. So in May or June.

It's too bad that the GTK situation is what it is on Linux, or at least on Fedora-based distributions. For comparison purposes, Fedora Core 4 was released a little after OSX 10.4, yet it's clear that even Fedora Core 5 was nowhere close to being "good enough for the desktop", since we're requiring a version of GTK2 that didn't make its appearance until Fedora Core 6. Or maybe it was good enough, and the API changes that enforce the version dependency we have now are just gratuitous. Sucks to be a Linux user either way.

It's almost certain that my next computer will be a Mac. At this point, OS X offers most of the features I want out of Linux, with none of the hassles. One of the few things it still doesn't do is let me configure my window manager exactly the way I like it, but doing the research to get that to happen on a "modern" Linux might be more trouble than it's worth too.

Posted by bzbarsky at January 27, 2008 2:47 PM | TrackBack
Comments

It appears like you mistyped the (first) anchor's closing tag (</> instead of </a>)

Posted by: Justin Wood (Callek) on January 27, 2008 4:11 PM

Indeed. Fixed.

Posted by: Boris on January 27, 2008 4:25 PM

='( My poor GTK...

Good night, sweet prince.

Posted by: MOnk on January 27, 2008 5:55 PM

The main failing I see is that we need to make major version upgrades easier. Significantly easier. There's work ongoing for this in Fedora, might land in the Fedora 9 timeframe.

Realistically though, I imagine enterprise OS vendors which ship Firefox are going to really want to readd conditional compilation against older GTK+. Mozilla doesn't have to do that patch, but my guess is that it will get written.

Posted by: Colin Walters on January 27, 2008 6:20 PM

Colin, if major version upgrades didn't break so much stuff this would all be much less of an issue, indeed. Anything that gets us closer to that would be very much appreciated!

Posted by: Boris on January 27, 2008 7:16 PM

Hi bz, sorry about the crashing as I thought I had that covered:

http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsDeviceContextSpecG.cpp#492

I'll try and make a patch to fix that.

Posted by: Michael Ventnor on January 27, 2008 9:11 PM

Michael, not sure how much it's worth worrying about it, to be honest. It's not that big a deal, so if it's too much pain to fix, don't bother. Printing not working is just as much of a showstopper for me using trunk builds as printing crashing, in any case.

Posted by: Boris on January 27, 2008 10:05 PM

How difficult would it be to develop inside of virtual machines? With Virtual Box, I can access the host file system from the client OS, and I can copy and paste between host and client. I'm sure other software like VMWare would have something similar.

Posted by: James Justin Harrell on January 27, 2008 10:40 PM

James, developing in a VM isn't so bad. Performance testing, however, is all screwy in a VM. Disk access, display access, CPU access, all have different characteristics all of a sudden, and there is the (variable) overhead of a VM as well.

The box in question is the one I use for performance testing and my day-to-day browsing, and using a VM doesn't make that much sense for either task.

Not to mention that a VM is by definition slower than the host machine, and this is a P3-733 to start with.

Posted by: Boris on January 27, 2008 10:46 PM

Hey, this is your blog and you're entitled to your opinions and all. On top of that, I certainly thank you for your work on Mozilla.

Now, what I don't understand are all these rants on planet Mozilla about Linux and its infrastructure which are, after all, free software like Mozilla, you know, the kind you don't get from Apple.

Of course the user experience on OS X is a lot smoother, they don't have to support a gazillion of hardware and they can dictate policy top-down on their software stack since they control it all. That's always been very difficult on open platforms because people can't get their heads out of their project and see the big picture. Colin Walters just had a very good post about this[1].

[1] http://cgwalters.livejournal.com/12380.html

Besides the specific case you describe here could just as well happen on OS X. Suddenly one of Mozilla's developers checks in a feature dependent on a 10.5 only API. Hmm, now you are getting symbol look up failures there too simply because you're running bleeding edge software which is prone to have unfinished code in it. Go whine on the planet about how much OS X sucks, hurry!

Yea, go and use OS X. But you know what? When it breaks, go whine on Apple's hears and see if they listen to you.

Posted by: Rui on January 28, 2008 7:24 AM

Is the code for using the old print dialog still there? I presume it is since other OSes still can use it. If that is the case, why not have a pref or application switch that can enable that. I believe there are similar options for other dialogs -- like the file->open dialog.

Posted by: Aaron on January 28, 2008 9:33 AM

Rui, you can view my comments as a rant, or you can view them as user feedback on the frustrations of actually using desktop Linux (as I have been since 1996). I understand the challenges involved quite well, thank you.

You're right that this specific case could happen on OS X. In does happen, in fact -- Gecko 1.9 dropped support for OS X 10.2 and 10.3 because it's using APIs that didn't get introduced until OS X 10.4. It might even be that the failure mode is just as bad (run along fine, then crash when the user tries to do something).

But in practice, the OS X APIs are a bit more mature than the Linux ones, and their support cycle is longer than most Linux distributions. Not only that, but even their hardware support cycle is longer in some cases, which is admittedly easier with more uniform hardware. My wife just upgraded to OS X 10.4 on her 7-year-old Mac, and it's all working fine. Both OS upgrades (OS 9 to OS X 10.2 and 10.2 to 10.4) went smoothly and without a hitch. My last Linux upgrade on a similarly aged machine (two years ago) made my sound card stop working. Note that this isn't the usual Linux issue (which I understand perfectly) of "no one's written a driver for this yet". There used to be a driver. It got dropped. Quite apart from that, it took me over a week of tweaking to fix the various things that got broken (locating various rpmnew/rpmsave files, etc, etc).

As for Apple ignoring feedback about things being broken, that would pretty much match my experience reporting Linux bugs to Fedora/RedHat, the kernel, and ALSA. So not much of a difference there, really.

I like Linux, I really do. But I have a lot less free time than I did as a college freshman, and the desire to have things "just work" is very strong.

I might try Ubuntu instead of OS X, of course. Maybe it'll be a lot better than Fedora. We'll see.

Posted by: Boris on January 28, 2008 10:53 AM

In my experience, Ubuntu has been a lot better than Fedora. I used Redhat and then Fedora from 5.2 through FC5, and one of the biggest frustrations with that OS was upgrade bustage, in particular video, audio, and networking.

Since switching to Ubuntu, I've upgraded thrice, from 6.06 to 6.10 to 7.04 to 7.10. And things have broken, particularly in the last upgrade (cupsd crashes, and Pidgin wouldn't show my contacts on startup until I disabled and reenabled my acounts), but nowhere near as frequently as they did with Fedora (exponentially less! ;-)).

But the general point is well-taken. Things do "just work" on Macs more often. Nevertheless, I still spend most of my time in an Ubuntu VM on my MacBook Pro, because it gives me the kind of window management that makes me more productive, which ironically is actually simpler and dumber than the management Mac OS X provides.

In particular, there are either one or two (with desktops) ways to switch windows with the keyboard on Linux, while there are two or three (with spaces) on Mac. And "maximize window" on Linux always means the same thing and doesn't violate Fitt's law around window edges.

So I'll stick with Linux, hope it stays on its trajectory of continuous linear improvement, and look forward to the tipping point.

Posted by: Myk Melez on January 28, 2008 4:24 PM

Myk, that's great to hear; the upgrade pain is the thing that bites me the most on RedHat/Fedora! Maybe I'll try Ubuntu come summer.

Posted by: Boris on January 28, 2008 6:01 PM

Shouldn't the print.use_native_print_dialog preference resolve your issue with Linux print dialogs?

Posted by: Bill Gianopoulos on January 30, 2008 6:12 AM

Bill, that pref does nothing other than take up space in memory, as far as I can tell. Certainly the GTK printing code doesn't pay attention to it.

It should probably just be removed so people don't get confused into thinking it has an effect...

Posted by: Boris on January 30, 2008 8:52 AM
Post a comment