Eugene Morozov writes: > Unfortunately, there's no support for SVG in win32 version of GTK. There is precisely as much "support" for SVG in GTK on Win32 as there is on X11 (Unix): None. The "support" on Unix comes from an independently developed dynamically loaded module, that is registerd in the gdk-pixbuf.loaders file. At least in OpenSUSE and Ubuntu, the svg loader is in a different package than GTK+. Nothing prevents somebody for distributing a similar librsvg package for Win32. One slight problem would be to think of a way to make sure the gdk-pixbuf-query-loaders program is executed to update the gdk-pixbuf.loaders file after installing the librsvg package. In case of bundle-everything -type executable installers, that is of course not a problem. (Personally I don't use such installers, as they give so little control and bundle stuff from different sources and with different release schedules together. But for end-users, they probably are the only realistic alternative.) In case of "dumb" zipfile-type distributions, there would have to be instructions to the end-user to run gdk-pixbuf-query-loaders manually. Unfortunately there is no middle ground. There is no intelligent package management system a'la RPM or dpkg for Windows. At least I haven't found any. (If there was, I would stop distributing zipfiles and switch. Executable installers for end-users could then be essentially wrappers around the package management system.) Porting either RPM or dpkg is feasible, but not easy. Both have their problems. RPM is huge, dpkg's code is written in an, eh, "interesting" style, and performs some very Unixish fork/dup/exec acrobatics. To really be usable on Windows, such a port (of either) would have to be enhanced to fill one essential requirement: freely end-user selectable installation prefixes. Using fixed configure-time paths like on Unix is *not* acceptable on Windows. Another requirement is high on my list, too: It should be possible to install different (conflicting) versions of the same package in different prefixes, and still have both instances recorded in the same package management database. These different versions of the same package should then both be able to depend on some common lower-level package, of which (one or several) versions are installed in yet a third (fourth, etc) prefix. (I.e. it should be possible to have both gtk+-2.8.3 and gtk+-2.6.10 installed, both depending on the same installed version (or one of several compatible installed versions) of libpng. Etc. But I have been digressing far from the subject now, better stop... --tml _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
