November 2005 - Inkscape Devel

ProposteSvago, terza et� inHOTEL* * * *
by Intersectors Servizi sas 28 Nov '05

28 Nov '05

1 0

PATH variable for extensions (problem on OSX)
by jiho 28 Nov '05

28 Nov '05

I forked the discussion from "[Inkscape-devel] Re: Using Inkscape for scientific work" because this thread was becoming very large. I should have done it before. On 24 nov. 05, at 19:34, Bryce Harrington wrote: >> the first problem is to get these EPS in Inkscape. At least on OS X, >> EPS import does not work because Inkscape cannot find pstoedit or >> ghostscript, though they are installed from fink. Where does inkscape >> takes the PATH from? With my fink tree added to the PATH in .bashrc >> or .profile in my home (.profile is the default) it does not work. >> With uberconverter on the way I hope all this will be solved in a >> not- >> so-far-away future. > > The path stuff in Inkscape is a bit limited; it works sufficiently on > linux but I'd have been surprised if it worked out of the box on > OSX. I > think it still doesn't work reliably on Windows. > > If you'd like to dig into this problem, here are a couple starting > points. > > First, there is a directory where config files for the extensions are > located. On Linux this is in /usr/share/inkscape/extensions. These > don't include path info but you may find it illuminating to review > their > settings and so forth. I think that the solution is somewhere there. All these are of the form: <inkscape-extension> <name>Postscript Input</name> <id>org.inkscape.input.ps</id> <dependency type="executable">pstoedit</dependency> <input> [...] </input> <script> <command reldir="path">pstoedit -f plot-svg</command> <check reldir="path">pstoedit</check> </script> </inkscape-extension> So the problem is to find the "executable". If I link my executables from /sw/bin to /usr/bin everything works. So when the path is standard, all work as expected. The problem is to know where the "path" of reldir="path" is defined. I found some references to the inx files in src/extensions/extensions.cpp and some references to paths to but it's only the paths where to look for the extensions... In doc/extension_system.txt the inx file are said to be read at startup but I couldn't find where. > Second, the paths are set in the src/path-prefix.h file. There is a > section for ENABLE_OSX_APP_LOCATIONS. If I were you, my first step > would be to verify that this define is actually set correctly on your > machine. If it is, then also doublecheck that the paths match up to > what you have on your system. these are set to find inkscape files (ui, tutorials, extensions... everything that is normaly in /usr/share/inkscape/) in the app bundle. It works fine. > Third, there is a little bit of path manipulation going on in > src/main.cpp in the main() routine. See line 610 for instance, where > the current homedir is set for WIN32. I don't see any OSX specific > hacks there though. The home dir is non standard in OSX but ~ works so I guess everything is alright. I have never had problem at least. The whole thing might well be a shell problem rather than an Inkscape problem after all. The only problem from the inkscape side is: what "shell" is executed to give the PATH and at what level (user configuration files are apparently omitted)? In addition, while looking at the inx files I remarked that to open an eps file Inkscape in fact does: eps --gs--> ps --pstoedit--> sk --sk2svg--> svg which implies that you have sketch installed in order to open (e)ps files. what is the reason not to do: eps --gs--> ps --pstoedit--> svg or even: eps --pstoedit--> svg ps --pstoedit--> svg which work (I changed my inx files and tested) except for the usual problem with ps to svg conversion (see the XML repair wiki page). If using sketch as an intermediate is better, could the dependency be conditional: with only ps and pstoedit, use them, when sketch is present, add the sketch step. it's a bit weird to have to install sketch to have ps import in inkscape... JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

2 1

gtkmm memory leaks?
by MenTaLguY 28 Nov '05

28 Nov '05

I'm noticing, looking over the dialog code, that people don't seem to be paying attention to memory management with gtkmm. Now, it may be that folks aren't bothering, simply because the dialogs never get freed, but I'd still rather people do it properly. Here is an explanation of how memory management is supposed to work in gtkmm. In most of the cases I've seen, the remedy is as simple as adding manage() around the creation of a widget. http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch18.html Fingers off the about dialog, though, I've got that one. -mental

2 1

Re: Re: AW: IRT: [Very long subject lines]
by Bob Jamison 27 Nov '05

27 Nov '05

I have noticed that a lot of messages recently, after re-routing, forwarding, replying, etc, have developed extraordinarily long subject lines! ;-) Maybe people could trim those a bit, too? The subject titles are falling off the right side. Thanks a million lupins! bob

1 0

Extensions and binary distribution
by Mike Hearn 27 Nov '05

27 Nov '05

Inkscape, like many open source programs, uses Python as a scripting language for extensions. This is all fine and good, but unfortunately raises serious issues for binary distribution. A few are obvious: * Windows users don't have it * Mac users probably have an out of date version * Linux users almost certainly have it, but it's probably got a different ABI/API to what is expected The first two do not concern me here. The last one does. The libpython C API varies between systems in an incompatible manner. Python 2.2, 2.3 and 2.4 are all in the wild, and they export different APIs. Worse, Python can be configured to use either UCS2 or UCS4 unicode strings. The upstream default is UCS2 but some distributions configure it to use UCS4 - this changes the exported ABI. I'm not sure what the solution to this is. Currently we recommend people do add Python for scripting to their applications, but that horse is long since gone for Inkscape. So we have a few alternatives: 1) Disable Python scripting in autopackage build. That'd be a shame. 2) Enable it in such a way that if libpython cannot be loaded, Inkscape still starts and works minus scripting 3) Figure out some new magic tricks so we can be compatible with all of them (relaytool can help here), for instance by avoiding the unstable parts of the API 4) Drop Python and port the scripts to some other system, like Lua or Mono (3) is the best for the user but requires the most in-depth knowledge of the Python API and versioning history. Statically linking Python isn't really an option, unfortunately. thanks -mike

7 12

daily win builds still crash on exit
by bulia byak 26 Nov '05

26 Nov '05

I'm not sure who's responsible for http://inkscape.org/win32-snap/ so I'm writing to the list. As reported in https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1275848&group_… these builds crash on exit. The remedy, according to Bob, is to make clean. Please can someone do this so that I can recommend those builds to windows people. Another related issue: Can we have with-debug-info builds in that directory? I for one would use them to report some crashes. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

sp_repr_set_attr conversions
by Robert Crosbie 26 Nov '05

26 Nov '05

I finished the conversions of sp_repr_ref, sp_repr_unref and most of sp_repr_set_attr. There are just a few instances of sp_repr_set_attr that require a little more thought, such as these: sp-object.cpp: /// \todo fixme: Exception if object is NULL? */ if (!sp_repr_set_attr(object->repr, key, value)) { ex->code = SP_NO_MODIFICATION_ALLOWED_ERR; } Since sp-repr_set_attr always returns true, code such as this will always be executed. I figured people who are familiar with this code and know what is supposed to be going on should make these changes. There are just 12 remaining instances that need to be addressed. -- Rob. http://woodpendant.com

1 0

WEBFORM opening drawer
by eric 25 Nov '05

25 Nov '05

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: eric email: e-rabbit@...714... submitted the following: Enter your message or news here. please help i downloaded inkscape to my docs when i try to openit it asks what do i wish to open with. maybe i just don\'t know what i am doing can you help. Please respond to e-rabbit@...714... with any suggestiions. Thanks stonehedge-13

1 0

RE: [Inkscape-devel] 0.44 plans
by Charles Moir 25 Nov '05

25 Nov '05

> From: bulia byak .. > P.S. As a "usability hall of shame" footnote, in the same > situation (clicking on a color swatch with nothing selected) > Xara always displays a "do you want to set the color as > default for new objects" dialog. This used to drive me mad. But it gives exactly what Tavmjong is asking for. So (obviously) I'll disagree that there's anything wrong with this way of doing things. We believe it's better and here's why. We only did it this way after looking at how users use the product (and competitor products), and after long and hard discussion as to the merits of all approaches. The bottom line is that it is a reasonable expectation that user want to work the way Tavmjong does. So our eventual approach satisfies all camps. A) You can configure Xara so that 'last applied style become current' so it acts like Illustrator and Inkscape. When you draw new things they take on the style of the last thing you drew. But this is not always a good thing or what you want. So, you can do it the other way; That all new objects are drawn in the 'default' style which you can define. B) If you change any attribute (e.g. select a color) when no object is selected, the user is obviously trying to do something. So I could argue that the hall of shame should be an application that ignores the fact the user is trying to do something, or disables controls with no obvious reason why (or worse disables some style controls and not others - I admit we have our fair share of these as well) So really all we're doing is prompting the user 'hey you just did something and I'm not sure what you want.' and we give them these choices; [ Set ] Sets the selected attribute the be the default for all new objects [ Cancel ] Oops, sorry I didn't mean to do that, go away [ Quiet ] Please shut-up and stop asking me this damn question (just for Bulia so it doesn't drive him mad any more) [ Help ] So we can explain what on earth this is all about. So the idea was that this satisfies everyone. Take the case of the text tool - the same point applies. We default to 10pt Arial, but this is a very personal thing of course. Just because you changed the font of a small bit of text somewhere, does that really mean you want all new text to appear in that style? (I see Inkscape is inconsistent here. Edit the colour of an object and this becomes the colour for all new objects, whether you like it or not. Edit the font, and this does not become the new font.) So Xara has a simple, global rule; try to apply any style or attribute with nothing selected and you can make it the default new style (font, colour, fill style, whatever). So we have a orthogonal model, that is actually easier to use than Inkscape (less to learn and less case-specific UI) and is more powerful (it does what Tavmjong is wanting, and gives the user the choice as to how they work, even Bulia's way) I see Inkscape has, for example, as 'Set as default' button in the text dialog. So does this mean that I have different UI for setting the default style or attribute for each of the possible styles or attribute? That's not good surely? Charles

6 11

Re: [Inkscape-devel] libintl.h
by Ralf Stephan 25 Nov '05

25 Nov '05

This is interesting for devel: J-F Lemaire: > There's also a SuSE 10 RPM of Inkscape here: > http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=/Office/inkscape Can we put that link on the web page, please, or does this posting suffice? ralf

1 0