August 2004 - Inkscape Devel - Inkscape Mailman

Web Site Changes
by Plinnell 15 Aug '04

15 Aug '04

Hi, I am in the middle of a changing the DNS servers for http://www.scribus.net You might not be able to directly access it in the next 24-48 hours, until the changes propagate throughout the DNS peers. In the mean time, if it is unaccessible, you can get to it via http://www.scribus.org. uk, http://scribus.us or http://scribus.biz Once, this is in place, we can directly link to it, instead of the current redirect. Thanks for your patience. Peter

1 0

randomized stars
by bulia byak 15 Aug '04

15 Aug '04

* A new Randomization control for the Star tool lets you set the amount of random displacement of the star's tips and (for rounded stars) curve handles. A little randomization makes a star less regular, more humane and sometimes funny; strong randomization is a way to obtain a variety of crazily unpredictable objects. Unleash your imagination!

3 9

knot statusbar tips
by bulia byak 15 Aug '04

15 Aug '04

* Each knot (control handle, node, node handle, etc.) displays a tip in the statusbar when mouseovered, explaining the function of the knot and its applicable keyboard modifiers. P.S. Don't forget to update http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes when you do something notable.

1 0

pattern edit regression
by bulia byak 15 Aug '04

15 Aug '04

Now when you start dragging the pattern scaling knot, the scale "jumps" unpredicably. There was some recent pattern-related change in object-edit by Carl which may have caused this. Carl, could you please look into this?

2 1

more GC work (SPRepr)
by MenTaLguY 15 Aug '04

15 Aug '04

Been doing some more gc-related work; I've been taking advantage of the facilities offered by the garbage collector to simplify SPRepr's implementation a little. The biggest win was in the strings used in the repr transaction logs. Previously, new copies were made to put in the log since memory management got hairy otherwise. Now the transaction logs and the attributes/text nodes can share the same strings. Another win is that SPRepr does not require a destructor anymore. Some current rough areas: * because finalizers are needlessly registered for SPRepr (as an Inkscape::Refcounted), we will occasionally end up with finalization cycles. This is not really harmful (especially for an object which has no destructor), but it does print a message on stderr and leak a very tiny amount of memory when it happens. I need to figure out how to have finalizer registration for Inkscape::Refcounted be optional. * secondly, the shared, immutable, garbage-collected strings allocated with Inkscape::Util::shared_c_string() are currently indistinguishable from any other C string. I am wondering whether I should introduce a special class for these, so type-checking will prevent someone from passing an ordinary string when they should be passing one of these instead (passing a static string is OK, but a temporarily allocated string will cause interesting and hard-to-diagnose bugs when it is freed out from under someone who was still holding a reference because they assumed it was safe to do so...) -mental

1 0

text refactored
by bulia byak 14 Aug '04

14 Aug '04

I just finished committing a huge patch from Fred which refactors the old sp-text into smaller pieces. The text system now became more powerful, about 10% faster, with less arbitrary limitations, and much more manageable. This is the foundation on which the GUI for the recently added flowtext and texpath will be built, as well as a necessary prerequisite for implementing text selection and styling of arbitrary text fragments. As of now, almost everything that used to work, works. Known exceptions: - letterspacing adjustment from keyboard does not work - kerning adjustments from keyboard does not work in non-latin text - keyboard movement in non-latin text is wrong (2 arrow keypresses needed to move one char) - the End key jump in the last line is off by one char These problems will be fixed soon. Of course there are likely other bugs too. Please test text editing and rendering thoroughly and report the results here. For now we're only interested in things that used to work until today but are broken now; if you discover something which also did not work in 0.39, submit to the bug tracker.

2 1

undo before finalizing
by Robert Crosbie 13 Aug '04

13 Aug '04

This may just be unexpected behavior. While drawing a line, If I select Undo before I've finished that line, it will undo the previous action, or remove the previous object. Now if I finalize the line I'm drawing and select Redo, it doesn't do anything. The previous action/object it undid is now lost. I was expecting that if I selected Undo while I was drawing a line, it would cancel or remove the line I was working on. Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN� Premium right now and get the first two months FREE*.

2 1

gc-awareness
by MenTaLguY 13 Aug '04

13 Aug '04

I've just reworked SPRepr to derive from Inkscape::Refcounted, so it is garbage-collector-aware (I've already done this with NRObject). What I mean by "gc-aware" is that it is safe to put pointers to garbage-collected objects in them, and that they are managed by the garbage collector. Normally gc-aware objects should derive from Inkscape::GC::Object or Inkscape::GC::FinalizedObject. GC::Object is the most lightweight of the base classes; it has no overhead, but destructors will not be run when it is collected (not a problem if there are no nontrivial destructors). GC::FinalizedObject (deriving from GC::Object) runs its destructors before it is collected, but there is additional overhead for tracking the destructors and a C++ vtable. Inkscape::Refcounted (which derives from FinalizedObject) is the heaviest of the "gc-aware" base classes, as it adds the overhead of an "Anchor" pointer and a refcount. The refcount is initialized to 1. It's also special among managed classes in that it allows you to safely keep references to Inkscape::Refcounted objects in non-gc-aware classes; all you need to do treat them like normal refcounted objects; increment their refcount with Inkscape::Refcounted::claim(), and decrement it with Inkscape::Refcounted::release(). As a result, an Inkscape::Refcounted will never be collected out from under you so long as its refcount is nonzero. The intent is that Inkscape::Refcounted will provide an interface between non-gc-aware code (e.g. classes derived from GObject or gtkmm's Glib::Object), and lighter-weight gc-aware objects. (it's safe to store pointers to gc-managed objects in automatic, global or static variables, as well as function parameters, so this is only a concern for storing pointers in dynamically-allocated objects) By the way, we can't simply make glib use the boehm allocator, since glib is used to allocate pixmaps, and RGBA pixmaps look like huge arrays of pointers. Maybe we could get away with it, but I think that'd be pushing our luck with a conservative collector. -mental

2 1

textFlow Example
by Jon Phillips 13 Aug '04

13 Aug '04

I made a full page letter overview of inkscape using the new textFlow features. I wrote it in a text editor. Once a UI is done for this feature, the usefulness of inkscape is going to scale incredibly!!! http://www.inkscape.org/doc/index.php I also split the documentation into user and developer on the website and updated the news. Jon -- Jon Phillips USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

2 2

breakage!
by bulia byak 13 Aug '04

13 Aug '04

Current CVS is unusable. 1. Start, press ctrl+n. Tools icons partially disappear on the new window. Open fill&stroke. At first only the stroke color tab icon is lost. Close the dialog, open again. Now all icons disappear. 2. Draw anything with the bezier tool. You get: ** (inkscape:19152): CRITICAL **: file sp-item.cpp: line 774 (NR::Matrix i2anc_affine(const SPObject*, const SPObject*)): assertion `object != NULL && ancestor != NULL' failed ** (inkscape:19152): CRITICAL **: file sp-item.cpp: line 774 (NR::Matrix i2anc_affine(const SPObject*, const SPObject*)): assertion `object != NULL && ancestor != NULL' failed Please fix ASAP. P.S. Please try to better test things before committing.

3 7