--without-gui crashes if home dir not writable

[Vibber]

Trying to use Inkscape headless for SVG to PNG conversion from a
web application, I discovered that inkscape will crash if it can't
create ~/.inkscape.

Command line is like this:
inkscape -z -w 123 -f some/file.svg -e someother/file.png

Stack trace (attached) shows a long series of GTK+ functions
leading back to inkscape_init_config(), where a failure to create
the directory leads to running a GTK+ message dialog. Since we're
running without an X server this naturally fails!

On Mac OS X, Apache runs as the user 'www', whose home
directory is /Library/WebServer and is writable only to root and
members of the admin group. Red Hat/Fedora Linux is similar with
'apache' homed at /var/www, which is root-only-writable.

If I first create a /Library/WebServer/.inkscape that www user can
write to, everything works fine from there...

If it's absolutely necessary to have an ~/.inkscape to run, it
probably should output the error messages with a nice printf() or
something when using the -z/--without-gui option.

[Vibber (vibber)]

I should add that this is with 0.39, built with fink on Mac OS X 10.3. I'm

experiencing the same problem also with sodipodi 0.34, and that part of
the code seems to be substantially similar.

[Bryce Harrington (bryce)]

Thanks, yes this should be fixed. The way Inkscape is
implemented, the ~/.inkscape dir is required for storing prefs. I
imagine with a little work it can be made to not require this
though.

For doing SVG to PNG conversion, you may want to take a look
at svg2png, which uses Cairo. The rendering may or may not
produce the same results as Inkscape, but it will definitely be a
lighter weight option.

[Bryce Harrington (bryce)]

Confirmed. Looks like it's similar to 10000350. Probably trying
to pop up the warning dialog about .inkscape not being writable.

[Bryce Harrington (bryce)]

Okay... I've added a fairly crude flag to the
Inkscape::Application structure so Inkscape can know whether
or not it's running with a gui or not.

A better solution would be to provide a mechanism for warning
message display that can be overridden as appropriate, but will
leave that for the gtkmm work since we'll want to replace all the
error dialog calls at that point anyway.