Re: [Inkscape-devel] Changing the gtk2 theme for a self-built OSX nightly
by jiho
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:
>
> http://www.sendspace.com/file/plht64
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:
>
> 1. Leopard Default
> 2. 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/
14 years, 5 months
CharTypes.h et al
by Michal Svoboda
Hello,
for the second day I'm trying to compile inkscape and growing more and
more desperate. Compilation fails with:
In file included from extension/internal/pdfinput/svg-builder.cpp:19:
extension/internal/pdfinput/svg-builder.h:32:23: error: CharTypes.h: No such file or directory
In file included from extension/internal/pdfinput/svg-builder.cpp:20:
extension/internal/pdfinput/pdf-parser.h:29:24: error: goo/gtypes.h: No such file or directory
extension/internal/pdfinput/pdf-parser.h:30:20: error: Object.h: No such file or directory
(and ~3 more pages of induced errors).
I've tried to google and stuff, but to no avail. What do I need to have
installed to get those header files? (I've seen that they come with
xpdf, but that's not quite it - and they don't get installed to
/usr/include anyway.) So either some horrible hack is required on my
part or these include files come with something very basic that is
auto-assumed, and nobody bothers to check for it in ./configure. Can
someone shed some light into this?
Thanks,
Michal
14 years, 5 months
intltool
by Diederik van Lierop
Hey people,
Just a quick note: to run ./autogen.sh succesfully with latest revision,
I had to update intltool to v0.40.5. This was the error I got before
updating:
Running intltoolize --copy --force --automake ...
cp: cannot create regular file `po/Makefile.in.in': No such file or
directory
intltoolize: cannot copy '/usr/share/intltool/Makefile.in.in' to
'po/Makefile.in.in'
Please fix the error conditions and try again.
Fedora 9 is still only at v0.37.1, so I had to manually copy some files
from the Fedora 10 preview release.
Diederik
14 years, 5 months
New snapping features
by Diederik van Lierop
Hi all,
In the latest revisions you will notice that Inkscape now has a snapping
tab in the preferences dialog. It contains some non-document specific
settings, such as for example the snap indicator toggle. There are some
new parameters too though:
1) You can now specify the snapping delay (as promised a few weeks ago)
2) I've added a slider which controls which type of snapping Inkscape
will prefer. When multiple snap solutions are found, then Inkscape can
either prefer the closest transformation (when the weight-slider is set
to 0; this is the old mode), or prefer the node that was initially the
closest to the pointer (when the slider is set to 1). The way Inkscape
calculates the preferred snap has been improved too, which should lead
to more predictable snapping
3) There's a toggle to force Inkscape to only try snapping the (source)
node that is closest to the mouse pointer, à la Coreldraw. When this
mode is enabled a snap indicator will shortly be shown at that node.
This will give you maximum control of the snapping which is useful for
more complex drawings with many nodes.
Have a try and let me know what you think of it....
Diederik
14 years, 5 months
compilation problem
by M
Hi all,
I am having the following problem during compilation of version 20346 (the
lastest as of now):
extension/internal/cairo-ps-out.cpp: In member function 'virtual void
Inkscape::Extension::Internal::CairoPsOutput::save(Inkscape::Extension::Output*,
SPDocument*, const gchar*)':
extension/internal/cairo-ps-out.cpp:137: error: 'CAIRO_PS_LEVEL_2' was not
declared in this scope
extension/internal/cairo-ps-out.cpp:141: error: 'CAIRO_PS_LEVEL_3' was not
declared in this scope
extension/internal/cairo-ps-out.cpp: In member function 'virtual void
Inkscape::Extension::Internal::CairoEpsOutput::save(Inkscape::Extension::Output*,
SPDocument*, const gchar*)':
extension/internal/cairo-ps-out.cpp:201: error: 'CAIRO_PS_LEVEL_2' was not
declared in this scope
extension/internal/cairo-ps-out.cpp:205: error: 'CAIRO_PS_LEVEL_3' was not
declared in this scope
make[2]: *** [extension/internal/cairo-ps-out.o] Error 1
make[2]: Leaving directory `/home/rmagno/Downloads/inkscape-20346/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rmagno/Downloads/inkscape-20346'
make: *** [all] Error 2
best,
Ramiro.
14 years, 5 months
Parsing a command line to argc/argv
by Krzysztof Kosiński
I'm getting back to work on the GIO transition.
The first thing that must change in order to move to GIO is the parameter
parsing (to open files it's best to use
Gio::File::create_for_commandline_arg, and for this filenames in filename
encoding are needed). However, this will interfere with the shell mode. I
don't think this is an useful feature - an embedded scripting language would
be a lot better - but probably there's someone who relies on it, so it
should be preserved until there's a replacement. I would like to reuse the
option parser from the main application, but then I have to parse the
command line into argc and argv myself, because that's what
g_option_context_parse accepts. Does anyone know whether there's an
"officially blessed" way of parsing a command line into argc and argv?
Regards, Krzysztof Kosiński
--
View this message in context: http://www.nabble.com/Parsing-a-command-line-to-argc-argv-tp20874473p2087...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
14 years, 5 months
