- Inkscape Devel - Inkscape Mailman

Devlibs updates
by Krzysztof Kosiński 28 May '10

28 May '10

Hello I made the following changes to the devlibs: 1. Upgrade Python to 2.6.5 2. Upgrade lxml to 2.2.4 3. Upgrade numpy to 1.4.1 4. Upgrade gettext-tools to 0.17 Please look for any breakage it might have introduced. The gettext tools update was a bit problematic and two versions of libintl are now contained in the build dir: one is being used by Inkscape and the GTK stack, and the second one by the gettext tools. Fixing this would require either convincing the gettext binaries to use the devlibs libintl, which I have no idea how to do, or rebuilding all other libraries to use the one built by gettext. In the longer run, I think that cross-compiling the devlibs from Linux might be less painful than recompiling them as needed in MSYS (mainly because MSYS is excruciatingly slow and sometimes doesn't work). Regards, Krzysztof

5 6

Showstopper bug
by bulia byak 28 May '10

28 May '10

This is easily a no-go for the release: - with Pen or Pencil, draw anything in Spiro mode (any other LPE would do the same) - clone (alt+d) - select original and try to move it by arrow key - watch Inkscape freeze and die an out-of-memory death, apparently in some kind of infinite recursion. I suspect this has something to do with LPE stack cloning that Johan recently worked on, but as I don't watch commits as closely as I would like lately, I also cc: others who did some nontrivial changes. Let's get this fixed quickly :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 2

Re : Re : Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 25 May '10

25 May '10

> De : Peter Moulder <Peter.Moulder@...2349...> > À : Nicolas Dufour <nicoduf@...48...> >> Another check-markup related issue: [it doesn't support msgctxt >> lines] > > It's past my bedtime, so I haven't tested interesting cases > yet, but try the attached patch. Thanks for the patch. Unfortunately, it still doesn't work. But the error message is different now: ... fr.po: parse error; may be a bug in po/check-markup: #: ../src/ui/tool/transform-handle-set.cpp:479 ... And the fuzzy lines are now correctly ignored. Regards, -- Nicolas

1 1

Re : Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 24 May '10

24 May '10

Hi, Another check-markup related issue: I've just activated gettext context macro C_() support in po/Makevars in order to include all the status bar messages added in the new node tool, but check-markup now returns an error message for each string, translated or not: ... fr.po: Not in msg format: #: ../src/ui/tool/transform-handle-set.cpp:479 msgctxt "Transform handle tip" msgid "<b>Rotation center:</b> drag to change the origin of transforms" msgstr "" I guess it is related to the new msgctxt line. Bug again, I'm really not a Perl expert... Could you please see if you can fix this issue? Regards, -- Nicolas

1 0

Inkscape 0.48pre0
by Ted Gould 24 May '10

24 May '10

Hey all, I did the release this afternoon, but realized I forgot to write the e-mail! :) None the less, I put together a pre0 release for the upcomming 0.48. Please if packages could look at it and ensure that they can build their package FROM THE TARBALL that would be great for making sure the tarball is useful. Links: https://sourceforge.net/projects/inkscape/files/inkscape/0.48pre0/ MD5: 273b3a032a57e8c557ebfac750d4572e inkscape-0.48pre0.tar.bz2 9cb002bd9ac0c3613ef435fd98551e06 inkscape-0.48pre0.tar.gz 332c4028f582f48e1587c232009a8886 inkscape-0.48pre0.zip --Ted PS - Odd to me is that there's already 72 downloads of the source!

1 0

Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 21 May '10

21 May '10

Comments removed from Makefile.am and patch committed in revision 9438. A huge thanks for your patch and explanations! Regards, -- Nicolas

1 0

The path to FREEZE... Woohoo!
by Joshua A. Andler 21 May '10

21 May '10

Hey all, We're roughly 6 weeks behind the proposed schedule... not good, but could be worse. If we stick to it, things could shape up nicely. A quick update... here is the one thing that MUST be done before moving to Freeze... posting of an "alpha" tarball. The following outstanding issues HAVE to be addressed to not be cut (and most unfortunately have not been addressed fully during Frost): *Jon's swatches MUST be initially editable in the F&S dialog. *Jon's new Input Devices dialog needs whatever polish to be good enough (I saw regressions from 0.47 mentioned recently in the tracker). *Jon's "UX" work (specifically UI placement needs to be settled). *Tavmjong's LinuxFund text tool work (we'll take what we can get, great progress has been made!). *Felipe Sanches' color management work. The "not real" (device) cmyk thing MUST be addressed prior to release. I'm not saying to remove, but perhaps disable, it is a part of the SVG spec, but it's not how the CMYK workflow actually works. Now is the time to bring up other possibly blocker bugs. Please speak up... things that can be fixed in point releases and that aren't critical/high priority should not be brought up. Cheers, Josh

4 4

Re : Re : I suck at Perl (or check-markup)
by Nicolas Dufour 21 May '10

21 May '10

>De : Lucas Vieites <lucasvieites@...400...> >Would it work to use the < and > entities in the original strings? The original string is already "<width>x<height>". intltools extract it as "<width>x<height>" to the pot file, which is the correct behavior. The issue is due to the check-markup perl script, which detects "invalid" markups in the translated strings (or markups which are not correctly closed, etc.). And <width> and <height> are not allowed by the script... Regards. -- Nicolas

1 0

I suck at Perl (or check-markup)
by Ted Gould 21 May '10

21 May '10

Hey, So I was trying to make a release but the check-markup script is failing because of the strings "<width>x<height>" which it thinks is a tag. I tried fixing the check-markup script to ignore this, but well, read the subject :) Could someone who knows Perl help out here? Here's the output: perl ../po/check-markup ../po/*.po br.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Bountañ war ar Vent a rank bezañ arventennet evel <width>x<height>" fr.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Imposer la dimension doit être défini sous la forme « <width>x<height> »" ja.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "サイズ強制は <幅>x<高さ> のように設定してください。" nl.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "Dimensies forceren moet ingesteld worden als <breedte>x<hoogte>" ru.po: parsing error for `<width>x<height>': #. i18n. Description duplicated in a fake value attribute in order to make it translatable #: ../share/extensions/webslicer_create_rect.inx.h:12 msgid "Force Dimension must be set as <width>x<height>" msgstr "" make[1]: *** [distcheck-hook] Error 1 Thanks, Ted

2 1

Coding style question
by unknown＠example.com 19 May '10

19 May '10

Hi all, Is it good practice to start class member variables with an underscore? The reason I ask is for ambiguity in a function in a class that is derivative of SPObject. class SPObject has member "repr". So now if I subclass from that and add a method to my class like "sp_do_something(XML::Node repr)", there is an ambiguity in the method. Perhaps underscoring the class member variables is better... Ciao, Johan

2 1