Webkit

[John Ralls]

On Mar 3, 2010, at 5:18 PM, Phil Longstaff wrote:

> On Wed, 2010-03-03 at 16:56 -0800, John Ralls wrote:
>> On Mar 3, 2010, at 7:02 AM, Derek Atkins wrote:
>> 
>>> John Ralls <jralls at ceridwen.us> writes:
>>> 
>>>> You might recall that I filed a bug against WebKitGtk on this last
>>>> summer, and got the rather tart reply that "we don't support Quartz
>>>> for plugins" and a changeset that removed the distinction between
>>>> MacOSX and other Unices in the file that caused trouble. I managed to
>>>> patch around that (which is why I'm able to ship with WebKit
>>>> 1.12). They've done more work, though, to extend the exclusion of
>>>> Quartz and my patch doesn't apply against 1.1.15 (nor git master).
>>>> 
>>>> I could probably write a new patch to get 1.1.15 working, but it seems
>>>> to me that it's not really a viable long-term strategy.
>>> 
>>> Hmm...  I wonder why they refuse to accept it?
>>> * grumbles at devs that wont accept reasonable patches *
>>> 
>>> How hard would it be to up-port your patch to 1.1.15?
>> 
>> Dunno yet. Also don't yet know what else I need to do to get it to build. At the very least, the configure test for libXt has to be disabled, and whatever is in the code that uses libXt will need to be either removed or rewritten, depending on how important it is.
>> 
>> The problem isn't so much that they won't accept a patch, it's that they don't want WebKitGtk to support quartz. 
> 
> The webkit issue I'm looking at is that file:// images won't load.  It
> has to do with the fact that on win32, a glib routine they use returns
> the file type ".jpg" whereas on linux, it returns the mime type.  I
> currently have a library based on 1.1.22 built with gcc 4.3.3.  Your
> patch would need to be applied to 1.1.22, and we would then need to
> figure out how to build properly.  The closest I've come is using the
> mingw32 cross-development packages on a vmware vmx running fedora.
> Unfortunately, webkit is so *damned* bleeding edge when it comes to
> gnome/glib dependencies.
> 


OSX would need to build against 1.1.22 only if you're calling functions which aren't available in earlier versions. This wouldn't be a good thing, because you've already gotten a couple of complaints from Linux users whose distros are still on 1.0.1.

At the moment, everything is working fine with OSX and WebKit 1.1.12, and the only reason to upgrade to 1.1.15.4 is because that's what the WebKit project has declared to be a quasi-stable release until they get the actually stable 1.2.0 out sometime this summer. Even then it will be a year or three before 1.2 is present in the latest of all Linux distros, so we'll still be in the position of being locked
in to older versions regardless of what we provide for the OSX and MSWin binaries.

Another way of looking at it is that we require (sort of) that Gnucash work with Gtk+-2.12. It would be absolutely pointless for me to ship that for OSX, because it has no quartz support at all. I ship the latest Gtk+ stable release (or reasonably close -- I update about every 6 months) because there's ongoing work improving the quartz support and the newer Gtk+ I ship the better the experience for our users. I imagine there is (or should be) a similar dynamic for MSWin. That has nothing to do with the *minimum* supported library versions, which should be based on the oldest releases in current Linux and BSD distributions (and nothing older, IMNSHO).

Regards,
John Ralls