Quoting "Stephen George" <[email protected]>:
Now days most people start GRAMPS with a batch file that puts the
bin directory of GTK rutime GRAMPS wants to use on the path in
front of all others - therefore the path modification is only valid
for the duration of the session, and isolated to that one process.
I've been using that solution myself for some years now (I no longer
tolerate any package that uses gtk+ to change PATH on my system, so
there's a couple of bat files I use for monodevelop, glade, ...)
<whinge>
Personally I have a lot of problem with GTK applications that ship a
local copy of GTK putting their copy on the path for all to see.
I don't see that problem with GIMP, .. while they ship a local copy
of GTK, they don't put themselves on the path, and I think that's a
model other shipping gtk apps could follow.
Yeah, gimp is one of the few that actually gets it right on windows...
It's no wonder a globally installed gtk runtime, is so problematic
when it's got to fight with various local gtk installs getting in
the way.
Yep, changing PATH should never have been advertised as a way to
get software using gtk+ working on windows. It's all great as a trick
used by developers, but in the end it bites users. Hard.
In fact now we are starting to find something has installed some
DLL's ( i.e. intl.dll, iconv.dll) to windows\system or
windows\system32, this causes a major problem as this path gets
checked BEFORE the path, so even you put your global gtk-runtime
first on path, it will still find the wrong copy of intl.dll.
I encountered that problem last year. Don't remember what package did
it... As you said, the PATH problem can be handled but system/system32
simply breaks everything...
mvg,
Dieter
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
