Yep, still got time to kill, so I’ll tell a story. This is the story of what it takes to ship a gtk+ 2.4 based application that will run on RedHat Linux 7.2 out of the box.
If you think that’s a frightfully masochistic thing to want to do, you’d be right, but the old gtk+ 1.2 UI was looking pretty ratty and unimpressive when we released 4.5, so there was no question that 5.0 would be 2.x based.
Now, deciding that you’re going to require a newer version of gtk 2.x than is present on the system without requiring the system to be upgraded is a chore in and of itself, as you have to override a bunch of obscure envrionment variables, otherwise your private gtk libs will be busy trying to use the system’s old theme engines and pixbuf loaders to no good effect. But when you decide that you want to run on a pre-gtk2 distro like rh72, you’ve suddenly got a lot of dependencies you can’t rely on anymore.
It seems an awfully long time ago but back in those days, there was no fontconfig, Xrender or Xft; it was good old X server-side fonts and you felt grateful if you could use a truetype font at all 🙂
I’m sure you can see the implications of this difference: we realised we’d have to ship all of those libraries along with the program, if gtk2 was going to work at all. And so began a labourious process of building all of our dependencies in a specially crafted virtual machine (of course) where things like glibc were the right version to ensure that the end result would work on rh72 and newer distros. And amazingly, it actually works. Nevertheless, I miss being able to just state what the requirements are and let the user worry about satisfying them. 🙂
Ironically, the biggest inconvenience didn’t come from the pre-gtk2 distros but from the gtk2 < 2.4 distros. The problem is theme engine versioning: Our shipped copy of gtk 2.4 cannot use the 2.0 and 2.2 theme engines, so when the user specifies a theme that relies on one of these engines... We attempted to mitigate the problem by providing our own gtkrc that always requests the default theme. But, this one wasn't going to have a happy ending because of that wonderful tool: gnome-settings-daemon. gnome-settings-daemon has the characteristic of forcing a theme on all gtk apps and as far as we can tell, there's no way for an app to override it and use another theme. The sad result, is that if your gnome destkop is using a theme with a theme engine, Workstation won't be able to load that theme engine and things can get pretty ugly. Things are, of course, better with newer distros where we can use the system gtk libraries and themes, but it's going to be a long time before the minimum requirements for Workstation are a gtk 2.4 based distro! So, the moral of the story is that you can actually ship a private gtk environment that depends on nothing more than glibc and X but you may legitimately wonder what the hell you're getting yourself into if you try.
{ 5 } Comments