Re: [Inkscape-devel] [Inkscape-translator] Inkscape 0.45 Hard Freeze & String Freeze
by Arpad Biro
Hi,
> I would also like at this time to declare String Freeze, to assist
> translators in finalizing their translations. If there are any
> remaining string issues such as non-translatable strings or fixes to
> existing strings, please send patches in ASAP.
I made a bug report of all string problems I'm aware of:
http://sf.net/tracker/index.php?func=detail&aid=1645093&group_id=93438&at...
Could other translators please check if they also see the "string
translated, but appears in English" problems described there?
Plus I have the following questions for translation:
"Trace along the boundaries of reduced colors"
(in "Trace bitmap" dialog)
-- does "reduced colors" mean "less colors" here?
"Isotropic scaling (uses smallest: width/xrange or height/yrange)"
(in "Function Plotter" extension)
-- does this mean: "use the smaller of those two values"?
"Scale Factor (Drawing:Real Length) = 1:"
(in "Measure Path" extension)
-- what does "(Drawing:Real Length) = 1" mean?
"Text Outline File"
(in "Outline 2 SVG" extension)
-- what's a "text outline"?
Arpad Biro
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
16 years, 10 months
Inkscape 0.45 Release Plan
by Bryce Harrington
With the completion of the Bug Hunt, we are nearly ready to move to
Feature Freeze, however there are a few tasks we must complete first:
Frost: ***
+ (DONE) Wrap up development work
+ Select an about screen
+ Release Notes is 90% filled in
+ (DONE) Bug Hunt: 300 points
+ Identify the Release Wardens for 0.45
+ Post inkscape-0.45pre0.tar.gz
Feature Freeze:
+ SVN is branched
+ No further development work on release branch
+ Focus on critical bug fixing
+ Finalize all tutorials, docs, extensions, etc.
+ Translators create translations
+ Inkscape must pass 'make distcheck'
+ Packagers encouraged to test package creation
+ Post inkscape-0.45pre1.tar.gz
Hard Freeze:
+ Focus on 'MUST FIX' bug fixing
+ Finalize translations
+ Finalize release notes
+ Test installation of packages for all major platforms
+ Post inkscape-0.45pre2.tar.gz
Release
+ Final verification of late work, packaging, release notes, etc.
+ Post inkscape-0.45.tar.gz
+ Post packages for major platforms
+ Post official announcements
Bryce
16 years, 10 months
attention windows packagers
by bulia byak
There are two issues that must be addressed in the next prerelease.
1. We need GTK at least version 2.10.7. Reason: in that version they
fixed bug which causes a pretty bad crash in Inkscape:
374378 Crash as GTK tries to blink cursor in defocused spinbutto...
Take the latest from http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/.
2. We really need to package numpy (numeric python) with python on
windows, otherwise the perspective extension does not work.
Thanks!
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
16 years, 10 months
Re: [Inkscape-devel] Xara and Inkscape comparison on Linux ActionShow
by MenTaLguY
On Thu, 25 Jan 2007 13:10:01 -0600, Aaron and Sarah Spike <spike@...749...> wrote:
> The ability to draw those outlines will also be useful for blurred
> objects and objects that have live path effects applied. :-)
One thing we will need to be aware of, though, is that the render-only-the-displayed-portion-of-the-path optimizations apply only to NRArenaShape, not SPCanvasBPath (which is currently what we have to use for "annotations" like nodes and these hypothetical outlines). Kind of a shame since the two classes do essentially the same thing, and one of the reasons I think the canvas code needs to have the two layers unified somehow.
-mental
16 years, 10 months
Re: [Inkscape-devel] Xara and Inkscape comparison on Linux ActionShow
by bulia byak
On 1/25/07, Aaron and Sarah Spike <spike@...749...> wrote:
> The ability to draw those outlines will also be useful for blurred
> objects and objects that have live path effects applied. :-)
Yes, and it's been in a todo list for a long time as well. Should not
be terribly difficult though, we already have the necessary building
blocks, just combine them.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
16 years, 10 months
INX definition of description text
by unknown＠example.com
Clearifying labels in an extension's UI are now defined in INX like:
<_param name="cmdlinename" type="description">The description</_param>
The external program, e.g. python, is called with a list of commandline options, among which:
--cmdlinename="The description"
I think this is not desired and that there are no cases where this cmdline option is actually used. funcplot.inx for example has a huge description parameter. The description isn't really a parameter; should we recode this to enable a syntax like:
<_description>The description</_description>
Or <label> or something else. (underscores to make it translatable, which is sometimes not necessary, e.g. in the case of funcplot.inx's help function listing)
The easier solution is to add a check whether the param is a description and not add it to the cmdline. This would also benefit the notebook parameter whose cmdline text is also often superfluous (the cmdline specification of which notebook tab was selected). Implementing this is peanuts.
Ideas?
Johan
16 years, 10 months
Numerical input of node coordinates
by Aron Stansvik
Hello Inkscape developers.
I recently started looking at how to add support for numerical input
of node coordinates when editing a path, and it seems it will be a bit
trickier than I initially though.
My first question is how would you want this feature to work? There
are two approaches that I can see:
* Inputs in node editing tool bar
- Values are updated while dragging a node?
- Values are updated when a node is released after dragging?
* Inputs in a dialog
- Dialog is shown when double clicking a node?
- Dialog is shown by pressing a button in the tool bar?
After mentioning this on IRC, it seems the first approach is the
favored one. So a couple of questions regarding this approach:
1) What's the best way to make the node editing tool bar aware of what
goes on in nodepath.cpp (node selected, moved, N of selected nodes
et.c.). Can I fire off signals and the tool bar will see them? The
approach that the select tool bar uses to get notified of object
modifications does not really seem to work for this (though I'm not
sure).
2) Is it really important that the input values are updated _while_
dragging a node (like with object dragging), and not when dragging
stops? (Latter seems easier to implement).
Any advice and pointers from people more familiar with this part of
the Inkscape code is appreciated, since this is my first stab at
hacking Inkscape and I might be poking at the wrong places.
Best regards,
Aron Stansvik
PS. ACSpike on IRC suggested that bbyak is probably the man I'm after.
You there bbyak? :) DS.
16 years, 10 months
Re: [Inkscape-devel] Inkscape 0.45 Release Plan
by Arpad Biro
Hi,
> 2. For committing translations during the Hard Freeze, Aaron and I
> would like to have an official Translations Integrator to handle
> committing of all the translation patches. Arpad, do you have time
> to take this role again this release? If not, then Cornelius, would
> you be willing to take the role?
OK for me. Still better would be to have both of us (Cornelius and me)
in that role...
Arpad Biro
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
16 years, 10 months
+ Inkscape::SVG::PathString
by MenTaLguY
I've noticed a number of places in the codebase where people have been
painstakingly building SVG path strings by hand. There had to be a
better way.
And now there is: Inkscape::SVG::PathString. It accumulates SVG path
operations and is convertable to a Glib::ustring.
Inkscape::SVG::PathString str;
str.moveTo(0, 0).lineTo(100, 0)
.lineTo(100, 100).lineTo(0, 100)
.closePath();
return str.c_str();
(You don't have to do all the operations in one go, but you can if you
want.)
Check out the before and after of using it in sp-ellipse.cpp:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/sp-ellipse....
So, the next time you're tempted to break out a raw SVGOStringStream (or
worse, sprintf) to build a path string, consider SVG::PathString
instead.
-mental
16 years, 10 months
Path optimizations?
by MenTaLguY
Now that we've got all our path building going through one class
(SVG::PathString), we've got the opportunity to do some syntactic
optimizations if we want -- for instance, using H or V instead of L for
axis-aligned segments.
Think that's worthwhile? Any other optimizations you all would like to
see?
-mental
16 years, 10 months
