Re: Makeing librsvg work (bizp2.dll missing)

[Tor Lillqvist <tml iki fi>]

> On Linux, the PATH is system-wide to include one GTK+ runtime. This is
> common practice. Why should there be any need to handle this different
> on Windows?

Because Windows is not Linux, and GTK+ is not provided by the operating system.

Here is an excerpt of a mail I sent just 9 days ago in a thread which
was (wrongly) in gtk-devel-list:

    > And what about the GTK+ apps bundled with their own gtk in their
    > own folders.

    That is the how it should be.

    > And wich gtk library does a certain application use when i start
    > it now.

    Unless some badly written application installer puts the GTK+
    stack DLLs in the system32 or system folder under the Windows
    folder, each application uses the GTK+ stack bundled with
    it. Either by having the GTK+ stack DLLs in the same folder as the
    application's exe file, or by using a Registry entry that makes
    the application's exe files use GTK+ from a specific location.

    As there is no centralized package management (as in a Linux
    machine running a specific distro), each application packager in
    effect is a different "distro" that distributes the version of
    GTK+ (and other 3rd-party libraries) that they know fits their
    application. GTK+ is from Windows's point of view a 3rd-party
    library.

    > From the view of a user this is realy confusing.

    Huh? A typical Windows user of a GTK-using application does not
    and should not need to know what GTK+ is, and that the application
    uses it, or that on a Linux box there is just one system-managed
    GTK+ installation.

    It's people with some experience of Linux that have the misguided
    conception that Open Source packages on Windows should somehow be
    installed like they are on Linux, i.e. system-wide, and thus find
    it confusing that there can in fact be several installations of
    some 3rd-party library, one per application that bundles it.

    > It would be really nice to have a standardized gtk installer.

    Why not start the discussion with something more basic, like zlib?
    How many copies of zlib code do you think exist on a Windows
    machine with a typical mix of freely available software installed?
    Firefox includes it, it's in OpenOffice.org, and surely in a bunch
    of other widely used software.

    (Presumably it is in some disguise also in Windows itself, even if
    the zlib API as such is not offered as a public documented API by
    Windows.)

    Ditto for libjpeg, libpng, expat perhaps, etc. Now, once you have
    convinced these projects to have a standardized installers for
    these libraries, let's get back to GTK+...

    > And if an application bundles it's gtk library with it's
    > installer, the installer should be able to check if there is
    > already a library installed and which version.

    Trust me, this just doesn't work. It is less pain if each
    application (or each person/company having control of their own
    installer(s)) bundles an own copy.

> If every application bundles its own copy of the GTK+ stack, the user
> will experience problems (beside of the waste of space): themes have to
> be configures for each GTK+ applications separately -- if they delivery
> themes at all.

Sure. Why is that a problem? Users (and I mean *real* end-users, not
"sophisticated" people who have used Linux) should not even need to be
aware that there is something called "GTK+" and that some app in
particular uses it. And the waste of space argument is so last
century.

I might well imagine that if various non-related GTK+-using apps
shared a GTK+ installation and theme setting, users would be very
confused why these, in their impression, totally unrelated
applications, are all affected by some mysterious "GTK+ theme setting"
thingie.

The situation is very much different on a GNOME desktop where it makes
sense to have theme settings shared between the desktop environment
and all apps using the same toolkit.

> This includes at least the uninstataller information. This is common
> usage on Windows and AFAIK required by the Winodws Programming Guidlines.

Yeah, but if there is no shared installation of just GTK+ as a
separate entity, there obviously is no need to uninstall it separately
either;)

--tml