Re: [Inkscape-devel] Changing the gtk2 theme for a self-built OSX nightly
Hi,
Sorry I did not answer earlier.
On 2008-December-01 , at 23:05 , André Berg wrote:
I compiled and uploaded numpy and lxml for Python 2.6 (i386) so that you guys can include them into the PythonModules.dmg on Modevia. Here's the link where you can download if you like:
Thanks, that will be useful. I will update the .dmg on Modevia ASAP (which might not be before a while though).
I also gave the build-system (mostly osx-app.sh) a few fair runs trying out the site-packages dir inside the Inkscape.app bundle. The inclusion of Arch and Python Version within site-packages made it somehwat difficult to get it working out-of-the-box with that build script. I have three Python distributions installed:
- Leopard Default
- MacPorts 2.5.x, 2.4, 2.6. (2.5.x being the active one with
MacPorts) 3. MacPython 2.6 (being the overall systems active python. symlinks from /usr/local/bin point to /Library/Frameworks/Python.framework/ Versions/Current/bin
My PATH (~/.bash_profile) looks like this:
export PATH="/Library/Frameworks/Python.framework/Versions/Current/ bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/ sbin:/sbin:/usr/X11/bin:/sw/bin:/sw/sbin:${PATH}"
So you can see MacPython comes first, then MacPorts, then /usr/ local, Leopard Default and finally remnants of a Fink installation.
The problem I had was that in the Inkscape shell script that ultimately resides within Inkscape.app/Contents/Resources/bin a path is exported that has almost the same entries but in another order.
Which led to the strange effect that even though I modified osx- app.sh to copy my numpy and lxml dirs automatically from /Library/ Frameworks/Python.framework/Versions/Current/lib/python2.6/site- packages into Inkscape.app/Contents/Resources/python/site-packages/ i386/2.6 the modules where never found when the program was started by double-clicking its dock icon. They were however found when I started Inkscape by double-clicking the Inkscape shell script mentioned earlier. It took me quite a while to find out what was happening:
Somehow the ScriptExec loader makes it so that Inkscape is started within a virgin /bin/sh with no PATH whatsoever set. The Inkscape shell script takes this into account by exporting its own PATH with a hardcoded order which for my system had the wrong order of importance. That's why I had this behaviour. The question now is, how can we make sure that when the user specifies a directory to use as the source for the Python modules, that we also start Inkscape with the proper shell environment that has the correct order of its PATH as set by the user for the Python install he/she selected to use as Python module root. In my opinion it is reasonable to assume that if the user has a custom PATH variable set in his/her default shell that he/she should know better than hardcoding/guessing what order the PATH components need to be in. However, unfortunately I failed modifiying the scripts involved in getting Inkscape to start up, so that the PATH in use by the user's default shell is set as the PATH to use for starting Inkscape.
I completely agree: we should read the PATH of the user and use that. However, as you, I was not able to find a solution. First, on Mac OS X, the "PATH" used by double clickable, bundled applications is the one defined in ~/.macosx/environment.plist. See the comment in packaging/macosx/resources/bin/inkscape:
# Brutally add many things to the PATH. If the directories do not exist, they won't be used anyway. # People should really use ~/.macosx/environment.plist to set environment variables as explained by Apple: # http://developer.apple.com/qa/qa2001/qa1067.html
The usual PATH variable, declared in the shell of the user, is used only on the command line. This is why we do this:
# but since no one does, we correct this by making the 'classic' PATH additions here: # /usr/local/bin which, though standard, doesn't seem to be in the PATH # newer python as recommended by MacPython http://www.python.org/download/mac/ # Fink # MacPorts (former DarwinPorts)
Instead of proceeding this way however, we could (should?) read the PATH variable set in the shell of the user and use that. The problems are: - we could probe for the existence of .bashrc, .cshrc or similar files depending on the $SHELL variable of the user and use what's in that. but the modifications could also be in .profile or .bash_profile or... So we need a clean solution to get the environment a regular shell script would get, and I don't know how to do that - Inkscape would behave differently from other graphical, bundled applications. - and another reason that I forgot...
There is, IMHO, a fundamental design flaw in the system, which makes scripts and regular applications use different PATHs (the things set in ~/.macosx/environment.plist, for applications are not available to shell scripts, and the PATH set in .bashrc for bash scripts for example, is not available for applciations). The only way to circumvent it is to set the same thing in ~/.macosx/environment.plist and in ~/.bash_profile (which is what I do), but I don't think Inkscape can do that for you. If you can find a way to concilate all these sources of PATH variables and detect/sort that in the launcher script, it would be very much welcome and will be included.
If it interests you I can include my modified osx-app.sh script. I also made a osx-keymap.sh script for setting the not so well- known .xmodmap hack until the Alt-Key behaviour is sourted out for X11. I'll include both with this e-mail.
I'm not sure what the modifications of osx-app.sh are intended for? Thanks for the other one. We need to decide whether it is better to include that (which would affect all X11 applications) or to sort it out for Inkscape only by using keys.xml in the appropriate way.
I also updated the wiki, but you may want to see it over, as there maybe some things in my edits that may go against the philosophy of the build teams involved.
I can't check now but I'm sure it's fine.
JiHO --- http://jo.irisson.free.fr/
jiho wrote:
Sorry I did not answer earlier.
No problem at all :)
jiho wrote:
I completely agree: we should read the PATH of the user and use that. However, as you, I was not able to find a solution. First, on Mac OS X, the "PATH" used by double clickable, bundled applications is the one defined in ~/.macosx/environment.plist. See the comment in packaging/macosx/resources/bin/inkscape
Instead of proceeding this way however, we could (should?) read the PATH variable set in the shell of the user and use that. The problems are:
- we could probe for the existence of .bashrc, .cshrc or similar files
depending on the $SHELL variable of the user and use what's in that. but the modifications could also be in .profile or .bash_profile or... So we need a clean solution to get the environment a regular shell script would get, and I don't know how to do that
- Inkscape would behave differently from other graphical, bundled
applications.
- and another reason that I forgot...
There is, IMHO, a fundamental design flaw in the system, which makes scripts and regular applications use different PATHs (the things set in ~/.macosx/environment.plist, for applications are not available to shell scripts, and the PATH set in .bashrc for bash scripts for example, is not available for applciations). The only way to circumvent it is to set the same thing in ~/.macosx/environment.plist and in ~/.bash_profile (which is what I do), but I don't think Inkscape can do that for you. If you can find a way to concilate all these sources of PATH variables and detect/sort that in the launcher script, it would be very much welcome and will be included.
Ah ok than I got the workings of it right... it is a very complicated matter I am suprised just how complicated it is...
Oh believe me I tried.. in the end my script was already at 300 lines and I was getting nowhere...
I tried to punch together a vanilla environment.plist file with a copy of the PATH as set in known locations (like .bash_rc or .profile or .bash_profile) or if a environment.plist file already exists without a *proper* PATH entry then just add that line to the existing file after lettting the user confirm the change.
Problem was the systems I was able to take a look at it was not uncommon that they included more than one file (out of the ones listed earlier) without the owner even knowing it. So how do I know which ones got the right PATH to copy?
As a small improvement I think it is reasonable to think that if a Python user has multiple Python version installed within multiple environments then it is reasonable to assume that he/she knows a thing or two about PATH variables and Terminal commands. In that case wouldn't it make sense to expand the error message a little when one of the modules inkex.py requires is not found, like for example:
"The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from http://cheeseshop.python.org/pypi/lxml/, or install it through your package manager by a command like: sudo apt-get install python-lxml. If you know that you have this module installed already and you have multiple Python versions installed, chances are that Inkscape uses the wrong Python installation. Please open <Inkscape.app>/Contents/Resources/bin/inkscape with a text editor and check that the order of the PATH variable matches the one your default shell uses"
Or something along those lines... I mean we can't break something by expanding the error message a little...
jiho wrote:
I'm not sure what the modifications of osx-app.sh are intended for? Thanks for the other one. We need to decide whether it is better to include that (which would affect all X11 applications) or to sort it out for Inkscape only by using keys.xml in the appropriate way.
The only modification I wanted to do was to find a way to only copy the needed Python modules and not the whole module directory which is what I believe the current script does. I ended up writing my own wrapper script that checks out Inkscape runs configure, make, then make install, then overwrite-copies to <LatestInkscapeSVNTrunkRoot>/packaging/macosx a slightly modified version of osx-app.sh that allows me to tell it via a command line argument which python modules it should copy from my local MacPython 2.6's site-packages dir (like osx-app.sh -b -py /path/to/python/modules "lxml numpy"). Then it runs the modfied osx-app.sh therefore building Inkscape-<revision>.app. I just made it for convenience and because I wanted to write some bash stuff again :)
I'll try to include it (it being the modified osx-app.sh, a .patch showing the few things that were changed and my wrapper osx-build2.sh script) via Nabble's file upload feature... maybe someone finds use for it I dunno.
I'm also thinking about putting a guide online that I wrote for a friend on compiling Inkscape for Mac OS X but with the updated wiki I don't think its needed anymore.
Btw, what's up with not being able to include a link to the CompilingMacOsX wiki article on the Inkscape wiki frontpage? That page is not editable. Can someone with proper rights change that? Else you basically have to know about the article in the first place to get to it or find it with Google by chance.
Or maybe I'm just blind :o) Nevertheless, if we can show more people how to compile for Mac OS X that can only be a good thing right?
Also for keys.xml I tried using that too... Even though I had a nice lookup table with all the key designations used by GTK I wasn't able to get the Alt key behaviour sorted out. Even tried using an old program called xkeycaps to figure out why exactly that could be but I couldn't get it to work the way I wanted to.
I added the xmodmap hack to the Inkscape FAQ in English and German, but not without warning that it is global to X11 and that the user cannot easily enter special diacriticals anymore especially on european keyboard layouts.
Btw, to whom do I need to speak to get the right to upload nightly builds ? I won't be able to upload every day but every once in a while I could contribute a build for Intel Macs.
http://www.nabble.com/file/p21063930/inkscape-support.zip inkscape-support.zip
Anyhow, Inkscape rules...
Cheers,
André
participants (2)
-
AndreBerg -
jiho