- Inkscape Devel - Inkscape Mailman

src/extension/script Makefiles
by Bob Jamison 16 Dec '04

16 Dec '04

Hi, all. Finally got my work email fixed again. Ok.. I finally hooked up the Makefile_insert and makefile.in in src/extension/script to the rest of the automake tree. So Inkscape is now compiling and linking with Perl and Python. Please try updating and building, when it is convenient. We will likely need to tweak it to make sure that the build works on everyone's machine. Now we need to make a dialog to load and execute scripts in either Perl or Python. Would there maybe be a user who is interested in GUIs, who would like to draw a mockup of what such a dialog might look like? (that's a lot of subjunctives in one sentence ;-) Bob

5 8

Winlibre and Upping our point release numbers
by jon 15 Dec '04

15 Dec '04

Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users? http://www.winlibre.com/en/Versions.php Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now) I am making the official push that our 1.0 of Inkscape is full 1.2 SVG compliance. By this, I mean we can accept and render a SVG 1.2 file. I think that developing the editing around this is important, but it is more important that we handle SVG 1.2. Maybe though someone can argue for Inkscape 1.0 being able to both render and edit an SVG 1.2 file. However, our system works currently, so why change it, right? I do think though that we need to get a supa-advanced version of Inkscape out the gate as Microsoft is going to drop their WVG (their SVG makeover) soon, and then we know what that means... I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?

12 30

inkscape static build
by herve couvelard 15 Dec '04

15 Dec '04

Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2. we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !) So what we can do is 1) to go back to previous state (gtk2-2.2). but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?) thanks

6 11

[patch] compile errors in nodepath.cpp
by Derek P. Moore 15 Dec '04

15 Dec '04

Howdy, I grabbed Inkscape 0.40 last night. I've been enjoyin' Inkscape for a little bit now, tryin' to hack a few things into the code (selectable ruler metrics, etc.). I figured it was time to port what modifications I'd been working on to the 0.40 tree. I'm using GCC (g++/libstdc++) 3.4.3 and Fedora Rawhide (post Core 3). In nodepath.cpp, I was getting the following compile errors: nodepath.cpp: In function `void node_ctrl_grabbed(SPKnot*, guint, void*)': nodepath.cpp:2220: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) nodepath.cpp:2222: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) make[2]: *** [nodepath.o] Error 1 In examining the code, the problem was with a few anonymous objects when calculating the origin of the grabbed control. The offensive code is: // remember the origin of the control if (n->p.knot == knot) { n->p.origin = Radial(n->p.pos - n->pos); } else if (n->n.knot == knot) { n->n.origin = Radial(n->n.pos - n->pos); } else { g_assert_not_reached(); } n->p.origin is of type Radial; and n->p.pos, n->n.pos, and n->pos are of type NR::Point. The creation of the anonymous Radial object with the subtraction of Points as the constructor argument seems to be working... The problem seems to be with the assignment of the resulting anonymous Radial object to n->{p,n}.origin. Translating the current code to pseudo-constructor-syntax (which is more along the lines of what the compiler actually compiles) results in: Radial origin(Radial(Point pos1 - Point pos2)) But since the Radial class has Radial::Radial(NR::Point const &), the following should suffice: Radial origin(Point pos1 - Point pos2) ... thus dropping the superfluous anonymous Radial. There are two solutions: A) create a pass-by-value Radial constructor, so we can properly pass the anonymous Radial, or B) drop the superfluous anonymous Radial in favor of the assignment being translated into the Radial::Radial(NR::Point const &) constructor. Attached is a patch that drops the anonymous Radial object in favor of C++ assignment/constructor magic. Now Inkscape 0.40 compiles and functions without complaint on my system.

2 1

Shortcut key translation
by Lucas Vieites 14 Dec '04

14 Dec '04

Hi, I was contacted the other day by J. Ramón Palacios, who translated the basic tutorial to spanish (I'll sent it in as soon as I do a quick revision). He asked me a question I had no answer for: in the inkscape menus the names of theshortcut keys are not translated. On the attached screenshot you'll see the spanish 'Object' menu (red underlining is mine). The shortcut keys are named 'PgUp', 'PgDn', etc. when they should be named 'Repág', 'Avpág', etc. Are these strings supposed to be in the .po file? If not, where are they supposed to be translated? Thanks for your time, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 2

Re: [Inkscape-devel] Shortcut key translation
by Kees Cook 14 Dec '04

14 Dec '04

On Tue, Dec 14, 2004 at 04:49:04PM +0100, Lucas Vieites wrote: > > This seems to be common to all Gtk applications, but I can't believe > > it's intended. If I run other tools (like gnumeric), I get the same > > results. > > > That's strange, because I don't. Before posting the origianl message I > checked Gnumeric and Evolution, and both show the correct key names, > that's why I asked. > Any other comments, anyone? Hm. Then I wonder if it's the locale of the Gnome instance itself? I use the "C" locale for my system by default, so when I start X, everything is in English. If I force inkscape (or gnumeric, etc) into another locale ("LC_ALL=fr_FR inkscape"), I get the localized menu names, but not shortcuts. Weird. I wonder if inkscape is missing some kind of localization initialization call? I know there is the main one at the start. Don't know. I guess file a bug so we can track this. -- Kees Cook @outflux.net

2 1

API for extensions?
by Ben Crowell 14 Dec '04

14 Dec '04

Bulia tells me there will soon be an extensions menu. I'm interested in writing some extensions in Perl. My motivation is to scratch my own itch, but some of the stuff I write might be of interest to other users as well. So far I've just been writing Perl scripts to manipulate SVG files, and running them from the command line. Is there an API for extensions yet? The simplest thing would probably be to do it through a shell, and provide a way to hook the command-line options and arguments up to a dialog box in the GUI. There would need to be provisions for internationalization, and for error reporting (including errors resulting from not having the right Perl modules installed). However, since Inkscape runs on Windows, running it in a shell might not work. Is the Extensions menu envisioned as a Unix-only feature? It seems like it would be quite complicated to implement such a thing on a cross-platform basis. It's easy to write the scripts to be platform-independent, but, e.g., most Windows users aren't going to have Active State Perl installed, and even if you embedded a Perl interpreter in Inkscape, that would only work for Perl, and there would still be the issue of libraries. Even if you told Windows users they were required to install Perl and a certain set of libraries, it would also be complex to try to write the glue between Inkscape and Perl in a platform-independent way. And my experience from writing a cross-platform Perl app is that it's a lot of work in terms of testing and code maintenance, much more than writing a Unix-only app.

3 2

[pjc@...609...: Re: [Inkscape-devel] OpenCD]
by Kees Cook 14 Dec '04

14 Dec '04

----- Forwarded message from Pierre-Jean Coudert <pjc@...609...> ----- Hello, I am Pierre-Jean Coudert from the WinLibre project ( http://www.winlibre.com/en/ ). WinLibre is a free software distribution for Windows aimed at popularizing free/open source software. We are including Inkscape since the WinLibre 0.2 release. (actually Inkscape 0.39 ) I want first to thank you for your great and impressive work. We have actually a problem with the 0.40 version. When we install it over the 0.39, it's impossible to open a file with the menu or the icon command (Inkscape crashes). Any idea for correcting this ? We would like to include the 0.40 version in the next WinLibre release. TIA Best regards, Pierre-Jean Coudert, WinLibre. ----- End forwarded message ----- -- Kees Cook @outflux.net

1 0

script for embedding raster images
by Ben Crowell 13 Dec '04

13 Dec '04

>> and I'm going to need to write >> various scripts anyway for my own use (e.g., I'm going to need >> something to gamma-correct svg files). Is there an API for >> extensions? >Hmmm... >Sounds perhaps like you might need to do more than just base gamma-correction. >There are many issues on color in general that need to be addressed. What >exactly are your needs for gamma-correction, and have you skimmed any of the >wiki pages on color? Ah, thanks for pointing me to the wiki -- lots of cool information there! I have a set of textbooks that was originally done on a Mac in PageMaker and Illustrator, and which I'm now in the process of converting to LaTeX and Inkscape on Linux. I'm actually producing the printed books in black and white, so CMYK issues aren't important to me. But as I move the books from Mac to Linux, I've been switching to the appropriate PC gamma correction. This makes them look right to me on the screen, and to users on Windows. (I give the PDFs away for free on my web site, and also sell them in print. Having them look good to professors who might adopt them is important.) Up until now, I'd just been gamma-correcting the EPS output from Illustrator using a kludgy Perl script. Now that I'm actually getting set up to *edit* the files on Linux using Inkscape, I'm planning to write software to gamma-correct the svg source files themselves.

1 0

Re: [Inkscape-user] Re: script for embedding raster images
by bulia byak 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote: > Up spake Ben Crowell: > > I don't know if AI's output is standards-compliant in this situation > > or not. If omitting the type is legal according to the SVG standard, > > then maybe Inkscape should allow it on input. > > Inkscape should probably allow it regardless, since being compatible > with AI is nearly as important as being compatible with the spec. > We don't have the clout to force AI to fix its mistakes, yet :-) I have to agree with that, though upon reading the RFC it's clear that the missing mimetype is interpreted as text/plain by default. So I think Inkscape is correct in its ignoring such images because technically, they're not images but texts. I'm not sure how to "fix" this because we probably use some library call to retrieve images from URIs.

1 0