On 20/10/2009, at 12:13 AM, ~suv wrote:

Arrgh - I was too fast to respond or too sloppy in testing! Obviously the path to the python installation (inside the MacPorts tree) is hardcoded into the modules - if I rename the installation directory (I have not used the default prefix '/opt/local') the python extension fail with the ominous 'fantastic lxml wrapper for libxml' story :(

Will try again tomorrow, but might need some help as well on how to create 'portable' python module packages...

I'm not sure how the original ones were created to be portable (I think JiHO built them). They certainly don't look portable since some link to dylibs in /opt/local. I may have broken them in that respect when I removed the DYLD_LIBRARY_PATH variable, though they appear to work on Leopard installations fine. This might be something to do with the different versions and architectures being linked to different libraries. That is, the ones I have tested on Leopard might only be linked to the system libraries and work, but the others to non- present Macports libraries.

I have a patch (attached) for the packaging script that does the path rewriting on the python files, but I'm not convinced it works completely since I was testing it on SnowLeopard and still couldn't get the extensions to run, as per my last email in the other thread. Anyway, that's as far as I got last time I had a chance to look at the problem.

Cheers, Michael

[ addendum ]

On 20/10/09 15:51, ~suv wrote:

Locally for testing I don't use the install_path rewriting (my MacPorts $PREFIX is too short and I can't re-install and upgrade to MacPorts 1.8.1 due to a bug still unfixed... waiting for 1.8.2 ;-).

My current MacPorts prefix is '/Volumes/blue/mp'. '/opt/local' doesn't exist on my system.

I will try if I can apply the 'fixlib' function to the new python modules manually and report back if I can get it to run with Inkscape-SVN.app on 10.5.8.

I meant 'if I can get the updated python modules to run with Inkscape 0.47pre4 from sf.net on 10.5.8.'

~suv

On 21/10/09 02:33, Chris Mohler wrote:

But a semi-related follow-up: where should user extensions go in OS X? Does a ~/.inkscape get created?

I keep them in '~/.config/inkscape/extensions' (0.47pre). There was a bug that the subdirectories in '~/.config/inkscape' were not automatically created, but this was recently fixed in rev.22349. [Bug #437938] “User resource directories no longer created if they do not exist” https://bugs.launchpad.net/inkscape/+bug/437938

If he is using Inkscape 0.46, put them into '~/.inkscape/extensions'. But AFAIK then your own extension script needs to append the path to the bundled extensions so that modules like inkex.py are found... (this is not necessary with Inkscape 0.47).

# only needed if you don't put the script into the installation directory import sys sys.path.append('/usr/share/inkscape/extensions') # OS X sys.path.append('/Applications/Inkscape.app/Contents/Resources/extensions') # win32 ??? #sys.path.append('C:\Program Files\Inkscape\share\extensions')

~suv

On 21/10/09 03:02, Chris Mohler wrote:

Any tips for the non-power user on accessing the .dotfiles? I gave him a couple of commands in the terminal, but if there's a Finder shortcut or something that would probably help. I get the feeling that he's not familiar with the terminal at all, so I'm trying to go easy on him ;)

dotfiles are hard, dot-folders are easier ;-)

to access the Inkscape preferences:

1) open a finder window 2) use menu bar 'Go > Go to Folder...' 3) enter the path to the dot-directory: '~/.config/inkscape', 4) click 'Go' -> you get a list with user preferences and all user folders like extensions, keys, palettes and templates. 5) optional: if he needs to go there often, change the view to 'as Columns' and pull the dot-folder into the left sidebar under places. 6) Tip: you can call 'Go to Folder...' from every save/open dialog using it's keyboard shortcut 'Shift+Cmd+G'

Which dotfiles does he need to access?

There are text editors that have options to show hidden files in the open/save dialog (MacVim does, though that's not one I'd recommend ;-)

Smultron has 'Open Hidden...' in the 'File' menu, a small text editor - though I just noticed that it's no longer developed: http://smultron.sourceforge.net/ (you can still download the last version 3.5.1 from sf.net).

I don't use others myself, but 'TextWrangler' (free, but not FOSS) could have similar options http://www.barebones.com/products/TextWrangler/. 'BBEdit' and 'TextMate' are the bigger ones among Mac text editors for programmers.

~suv

On 21/10/09 08:45, Chris Mohler wrote:

Aha - thanks for the tip, as it is just ~/.inkscape that I need to point him to.

That means he's using Inkscape 0.46...

I tried to copy&paste the new lxml and numpy modules into the Inkscape 0.46-2 package, but it didn't work. Let's hope that you don't get

| Bug #321346 “Bundled lxml lib not being found” | https://bugs.launchpad.net/inkscape/+bug/321346

when using python modules built with newer shared libraries in MacPorts.

~suv

On 29/10/09 22:10, JiHO wrote:

3rd reply to the same thread. Sorry, I am catching up on a ton of email...

Glad to have your input!

...

My current MacPorts prefix is '/Volumes/blue/mp'. '/opt/local' doesn't exist on my system.

That reminds me of another issue we have with the way we currently add items to the PATH. Right now, we are (well, I am, since I coded that part) brutal and stupid: just add "common" locations to the PATH and do not even try to deal with user-specific configuration.

In you case that could mean that, even though you probably configured your shell to use /Volumes/blue/tmp, Inkscape does not know about it. I suspect (but would welcome confirmation) that if you set the PATH in environment.plist: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPRun... it should work. As far as I know, this is the standard way of setting environment variables for GUI apps on OS X.

No, I don't use 'environment.plist' - I don't like it because it is static and absolute (i.e. you can't append to system variables like $PATH and you need to logout/login again to get any changes picked up by the applications started by launchd). Even Apple says "The answer to your next question is: Yes, this is a relic left over from OpenStep/NextStep." http://developer.apple.com/mac/library/qa/qa2001/qa1067.html

<...>

So to sum up, if setting stuff in environment.plsit works for Inkscape, I would be for writing a FAQ about setting PATH in environment.plist and remove our PATH stuff from the bin/inkscape script. Removing it will cause people to ask about what changed and this should diffuse knowledge of environment.plist.

I would not recommend the use of 'environment.plist'.

Then, if someone comes with a clever way of extracting the PATH modifications from the shell configuration file of the user, that would be a plus, and would make things more transparent. However, this is no easy task: BASH alone has many possible user level config files (.profile, .bashrc, .bash_profile and there might be others). And then there are the csh, ksh aficionados ;)

I have been running your Inkscape development snapshots and later my own SVN builds with custom shell launcher scripts (script, openDoc and bin/inkscape), and have my normal shell environment (set with ~/.profile - a symbolic link to ~/.bash_profile - and ~/.bashrc) in Inkscape available by using a login shell in the first level (script and openDoc) which automatically sources the default startup files of my $SHELL (whatever that might be). See bug #383456 “[OS X] launch Inkscape with a login shell” https://bugs.launchpad.net/inkscape/+bug/383456 where I filed my initial ideas. That report is quite old and I have learned a lot since, but basically the attached patch is what gets the user configuration into the shell launcher script for inkscape-bin.

Please let me know what you think,

If this is something you might consider I could attach my current launch scripts to bug #383456 (status 'work-in-progress': additionally they log all inkscape console output into a separate file, add a time stamp, PID and list some env variables plus any arguments to inkscape-bin e.g. when called by a python extension script - mainly debugging info not of interest for the regular Inkscape user). I am sure using a login shell ('#!/bin/bash --login' or '#!/bin/sh -l') is debatable - OTOH X11/Xquartz does it as well as e.g. MacVim and probably other (ported) applications I don't know about.

~suv

On Thu, Oct 29, 2009 at 23:22, ~suv <suv-sf@...58...> wrote:

I have been running your Inkscape development snapshots and later my own SVN builds with custom shell launcher scripts (script, openDoc and bin/inkscape), and have my normal shell environment (set with ~/.profile  - a symbolic link to ~/.bash_profile - and ~/.bashrc) in Inkscape available by using a login shell in the first level (script and openDoc) which automatically sources the default startup files of my $SHELL (whatever that might be). See bug #383456 “[OS X] launch Inkscape with a login shell” https://bugs.launchpad.net/inkscape/+bug/383456 where I filed my initial ideas. That report is quite old and I have learned a lot since, but basically the attached patch is what gets the user configuration into the shell launcher script for inkscape-bin.

I never realized this. From your bug report, I would say that updating script exec would be the best solution but for now the bash --login will do. I'll commit that as soon as the trunk reopens.

...

Please let me know what you think,

If this is something you might consider I could attach my current launch scripts to bug #383456 (status 'work-in-progress': additionally they log all inkscape console output into a separate file, add a time stamp, PID and list some env variables plus any arguments to inkscape-bin e.g. when called by a python extension script - mainly debugging info not of interest for the regular Inkscape user).

This would be welcome indeed. I would suggest, however, to make it a new bug report/blueprint, assigned to me, that reads "Adding debugging output to Inkscape on OS X" or something.

Thanks a lot,

JiHO --- http://maururu.net