RE: [Inkscape-devel] Inkscape on Windows
I have GTK 2.2.4-2 (from the Gimp web site) installed, which is the official version for Windows. However, when I try to install Inkscape, it quits the installer, asking me to install GTK2.
Are you using 0.36 installer? If so wait for 0.37, or grab a recent build here:
http://troi.lincom-asg.com/~rjamison/inkscape/
These new builds do not require any external libraries. Just unzip and run.
_________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
bulia byak wrote:
I have GTK 2.2.4-2 (from the Gimp web site) installed, which is the official version for Windows. However, when I try to install Inkscape, it quits the installer, asking me to install GTK2.
Are you using 0.36 installer? If so wait for 0.37, or grab a recent build here:
http://troi.lincom-asg.com/~rjamison/inkscape/
These new builds do not require any external libraries. Just unzip and run.
Exactly! A good example of why it is best to supply your own dependencies. I would suggest, that as long as the download is not too large, that we continue doing it this way, to -forever- avoid version mismatches and "dependency hell."
I would like to ask anyone who has one of our self-contained Inkscape builds, and who also has Gtk+ installed for something else like Gimp: Is there any interference between their DLL's and ours? That shouldn't happen (current directory is always searched first) but you never know. I would suggest that the Inkscape executable directory -never- be added to the PATH (on win32), just to prevent this. If you need convenience, just drag a shortcut onto your desktop.
One thing I think that I am going to do, is move the .exe and the .dlls out of the toplevel install directory, and into a /bin subdirectory. That would make it more like Unix's /bin, /etc, /lib... It would be most like if you built Inkscape with ./configure --prefix=/usr/local/inkscape.
Then when we fix Inkscape to use relative paths to find its resources, then Win32 will reap the benefit also.
Bob
On Mon, 2004-01-26 at 00:58, Bob Jamison wrote:
Then when we fix Inkscape to use relative paths to find its resources, then Win32 will reap the benefit also.
That might be easier said than done.
There's no portable way to find the absolute path of the current executable in Unix (yes, in many versions of Linux you can dig around in /proc, but that's not portable, and won't work for cases with symlinks like where stow(8) has been used).
Intuitively, abspath(argv[0]) would be sufficient, but argv[0] having anything to do with the executable path on Unix is merely a convention; there are no guarantees.
This is why all major Unix applications either:
1. use the path specified at compile-time
2. use an environment variable to find their files
3. use a wrapper shell script (shell scripts DO always have an argv[0] that points to the script)
-mental
MenTaLguY wrote:
On Mon, 2004-01-26 at 00:58, Bob Jamison wrote:
Then when we fix Inkscape to use relative paths to find its resources, then Win32 will reap the benefit also.
That might be easier said than done.
There's no portable way to find the absolute path of the current executable in Unix (yes, in many versions of Linux you can dig around in /proc, but that's not portable, and won't work for cases with symlinks like where stow(8) has been used).
Python provides some functions to do this, perhaps we can steal that?
njh
On Tue, 2004-01-27 at 21:03, Nathan Hurst wrote:
Python provides some functions to do this, perhaps we can steal that?
Python scripts are ... well, scripts, meaning that they already have the proper executable path as argv[0] to begin with, so they don't need to do anything special.
-mental
participants (4)
-
Bob Jamison -
bulia byak -
MenTaLguY -
Nathan Hurst