- Inkscape Devel - Inkscape Mailman

shortcuts.xml (configurable key bindings)
by unknown＠example.com 28 Nov '05

28 Nov '05

Here's the schema I've settled on: <keybindings name="user-visible name for shortcut scheme">  <primary keyval="a gdk keyval name" modifiers="control,alt,shift" verb="VerbName" />  <seconary keyval="a gdk keyval name" verb="OtherVerbName" /> </keybindings> The keyval names are as returned by gdk_keyval_name(). I've comitted a shortcuts.xml file that I've extracted from shortcuts.cpp; it follows this schema. We'll probably move it somewhere else later, but right now it's in src/. No code to read it, yet, but that'll come soon. I think files using these schemas will go in /usr/share/inkscape/keybindings/ and ~/.inkscape/keybindings/. I'm not sure whether the default schema should remain hard-coded or whether that should stay in an XML file. Thoughts? -mental

4 3

Markers
by Daniel Haude 28 Nov '05

28 Nov '05

Hello inkscape developers, many of my colleagues and myself are working in a scientific field which frequently requires the production of figures which are essentially bitmaps with some added annotations. A photograph with an arrow pointing at some feature. And a bar with two T-shaped ends to indicate a length unit. The problem is that most of the images are pretty dark, so what would be required are white arrows and scales. Which is difficult, given how SVG treats markers totally seperately from the lines to which they're attached. It is in fact this shortcoming in that has prevented me from advertising inkscape to my colleagues, many of which use WinDoze almost exclusively to prepare graphics in CorelDraw. For my own use I have created a markers.svg file in which I defined the most important arrows and stops in white, but this is a rather unstisfactory workaround (and it will be hell to explain to users why they should knuckle under restrictions which, from their point of view, have to do only with inkscape's weird data storage format -- all they need in the end is PostScript). Let's face it: there is hardly any case in which one would want arrowheads and other markers to have a different color than the line to which they're attached. Sadly the creators of SVG haven't seen this and provided some marker style option that makes markers inherit the colors of their attached path. So what would be required is that inkscape silently added an additional marker definition for every line color that is used with a marker. Maybe the "Stroke Style" dialog could include a checkbox to turn off this behavior if desired. I've looked into inkscape's code hoping to find a place where this functionality could be added but have found none. Anybody who is deeply familiar with inkscape's architecture could probably add the necessary code in one weekend, while it would take me weeks to just get my head around the entire source tree. So I'd be glad if someone could look into this. Inkscape is a great piece of software, and this would make it even better. -- dunno@...1090...

3 2

inkscape 0.43 not building on windows
by Sébastien Kunz-Jacques 28 Nov '05

28 Nov '05

Hi there, I try to build inkscape 0.43 and CVS snapshot on winXP, with latest mingw and perl/gtk2.8 as indicated on the win32 build page (http://inkscape.org/win32/win32buildnotes.html). The trouble is that some files seem to be missing from the 0.43 source archive found on inkscape website (for example, files under src/dom/js). These missing files make the build fail. When I try to build from a CVS snapshot (http://www.inkscape.org/cvs-snap/) I encounter other difficulties which seem to come from a broken CVS tree. Is it normal ? What is required to build 0.43? Best regards, SKJ

2 1

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