- Inkscape Devel - Inkscape Mailman

snapping update?
by bulia byak 02 May '06

02 May '06

One thing that we can't release without is workable snapping. Since more and more people start talking about releasing, I thought I'd ask for an update. Overall, it seems to me that this area, which was actively worked upon a few months ago, has been abandoned since and is now in some semi-working state. At the very least, the freeze-when-dragging-many-objects bug MUST be fixed. There are many other snapping bugs and RFEs, and there's probably some work that was left unfinished. Carl, is there any chance you will address the freeze bug in the near future? What about other bugs? Mathieu, I know you were working on some features that were conditional on Carl's work. Can you please give us an update of the current status? What is required to enable your features? Do you think you could help us with the bugs and general cleanup in absence of Carl? Of course, any insights on the situation, or better yet, help with coding will be much appreciated from anyone. Thanks! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

path effect grammar
by Aaron Spike 02 May '06

02 May '06

I'm still rather hating the way I'm currently implementing attributes for storing live effects parameters. <path path-effect="sample" path-effect-param1="0.0" path-effect-param2="0.0" path-effect-param3="0.0" path-effect-param4="0.0" /> My problems with this are: 1) Anytime a new effect is implemented that uses n+1 parameters, another parameter attribute needs to be added in a few code places. 2) It is not possible to layer multiple effects. 3) It is not possible to order the effects that cannot be layered. 4) The meaning of the parameters is unknown in the SVG file. The structure used by SVG's style attribute deals with 1 and 4. The structure used by SVG's transform attribute deals with 2 and 3. We could combine them into something like: <path path-effect="sample1(param1:0.0;param2:loopy;) sample2(paramA:45;)" /> I of course don't know how to begin doing something like this in C++. I'd like to hear what you think would be more appropriate and how it would be implemented. Aaron Spike

7 24

Re: [Inkscape-devel] Inkscape 0.44 Status
by Bryce Harrington 02 May '06

02 May '06

On Mon, May 01, 2006 at 02:36:42PM -0700, MenTaLguY wrote: > On Mon, 1 May 2006 16:28:52 -0400, "bulia byak" <buliabyak@...400...> wrote: > >> Brush size adjustment on zoom toggle for calligraphic pen > >> ========================================================= > >> MentalGuy is working on this and plans to have it to a finished point > >> for the release. > > > > Mental, is this what you described - some kind of visual pen width > > changer? Do you think it will be ready for this release? > > I think bryce was describing the absolute size toggle you've comitted. > > I would have liked to do the visual pen width adjustment for this release, I don't think I'll have time. Except perhaps for fixing any gross memory leaks that turn up, addressing the tablet bug takes priority over everything else (even the layer dialog), because I find it makes Inkscape nearly unusuable (I've become very adept at switching back and forth from the mouse, but...). > > -mental > Just to clarify, should I mark this Brush size feature as done, or as on hold? Bryce

2 1

Underlined Text
by Joc 02 May '06

02 May '06

What about adding support for underlined text? Many kind of underline are possible, single line, double line, wavy line, etc. This could be extended to have the line above the text or in the middle of it (overstrike). The text flow could also be expanded to be able to write fractions, equations, etc. Joc

4 7

finalizer logging
by MenTaLguY 01 May '06

01 May '06

I've just added another debugging category to the debug logging code, so now object finalization is reported in the log. Finalization is a special step taken before freeing those objects which the collector cannot automatically clean up (e.g. because they need to release non-collector-managed resources). Classes with finalizers include SPDocument and SPDesktop. Try it out with latest SVN: INKSCAPE_DEBUG_LOG=debug.xml INKSCAPE_DEBUG_FILTER=REFCOUNT,FINALIZERS src/inkscape Open some documents, close them, and before closing the last one, go to the "About Memory" dialog and click "recalculate" a few times to make sure that a garbage collection pass gets run. Then look at debug.xml. You can see not only when the finalization of an object happened, but also what debugging events (in this case refs/unrefs) happened during its finalizer. -mental

2 3

WEBFORM Broken Wiki links on the german homepage
by Christian Corona 01 May '06

01 May '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Christian Corona email: christian.corona@...240... submitted the following: Hi, I wanted to read about how to help the Inkscape project by doing translations, but all the links on the german version of the Inkscape homepage that point to wiki pages are broken. They\'re all in this format: http://wiki.inkscape.org/wiki/?TranslationInformation While it should be: http://www.inkscape.org/wiki/index.php/TranslationInformation You really should look into this, because right now all the links point to the wiki main page. I haven\'t checked this but the links might be broken on other translated versions, too. Also, I hereby would like to offer my help by doing translations english<->german, I am especially interested in translating the tutorials to german since they are really useful for learning how to use Inkscape. Cheers, Chris

2 1

[Fwd: Invitation to Participate in Summer of Code 2006]
by Bryce Harrington 01 May '06

01 May '06

Hi All, I've gone ahead and indicated our interest in participating in this year's Google Summer of Code. Please begin imagining some good projects for us to offer for students to work on. :-) The more ideas, the better! Bryce ----- Forwarded message from Leslie Hawthorn <lhawthorn@...819...> ----- Date: Fri, 14 Apr 2006 12:43:36 -0700 From: Leslie Hawthorn <lhawthorn@...819...> To: bryce@...961... Reply-To: lhawthorn@...819... Subject: Invitation to Participate in Summer of Code 2006 Hello Bryce, *ahem* Sorry about that - we'd like to invite Inkscape to sign up! Google is launching the Summer of Code program again this year and we would like to invite Inkscape to sign up to participate. You can peruse our [1]Mentor FAQ and [2]Terms of Service on the [3]Summer of Code site for more information on this year's instance of the program. If you would like to participate in Summer of Code 2006, please email back with your [4]Google Account information and we will use this information to create the first administrator account on the SoC site for Inkscape and send you instructions for accessing and updating the site. We look forward to working with you again during this year's Summer of Code! Cheers, LH -- Leslie Hawthorn Open Source Program Coordinator Google Inc. References 1. http://code.google.com/soc/mentorfaq.html 2. http://code.google.com/soc/tos.html 3. http://code.google.com/soc/ 4. https://www.google.com/accounts/ManageAccount ----- End forwarded message -----

22 66

Background Image and Drag to Install (was Re: [Inkscape-devel] new packaging for OS X)
by Ben Fowler 30 Apr '06

30 Apr '06

On 24/04/06, jiho <jo.irisson@...400...> wrote: > On 24 Apr 2006, at 13:59 , Ben Fowler wrote: > > On 24/04/06, jiho <jo.irisson@...400...> wrote: > >> Hi all, > >> > >> [ snip ] > > > > Could I underline that this is more than eye-candy: It is best > > practice to have a background image, showing that > > the way to install the application is to drag it to the folder of > > your choice. It is also advisable to somehow indicate > > where the application now is, to wit that the user will have to open > > the Applications folder (perhaps with Cmd-Shift-A) > > to see where they put it. ... > > so you advise not to use the symlink to Apllications but rather to > make the user open Applications (or anything else) and put inkscape > there? Well, I didn't mean to go into quite such a detail, but if you did want an opinion from me, I would be a little against it. (Does anybody else do this?). Some people (most people) want to put apps in the System wide Applications folder, some people put apps in their ~/Applications folder - necessary if you do not have write permission to the System wide Applications folder, and some people plonk new apps onto their Desktop to try out, and then transfer to the proper place when they have checked them out. I wouldn't expect a naive user to understand dropping an icon from part of a disk image to another. The problem is making the instructions brief and multi-lingual. My guide is this page which has aged very well: http://www.g2meyer.com/usablehelp/dmggfx.html , > >> I'll be unavailable for the next two months so I won't be able to > >> produce Inkscape dev builds for the testing phase of the release, nor > >> will I be able to package 0.44. I guess people will be available to > >> do it. If this new packaging is ok to everybody and worth bothering, > >> I'll modify the wiki to explain how to do it and somebody (Michael? > >> Ted?) could take over the builds. > > > > I think that they key to this is that there should be one person > > nominated to produced 'blessed' builds. FWIW, I have had to make a > > few modifications to the methods on the wiki, and I > > doubt that many people are producing Mac builds. This does not matter > > provided that one person can produce official builds - interested > > parties can download and test those. > > I agree with you. I'll be happy to be the one to produce the > "blessed" builds ;-) I just cannot do this for a while and I just > need someone with a 10.4 machine to take over for two months (BTW, I > mixed up the names and wrote Ted instead of Ben earlier. Even if you > work on 10.3, do you have a 10.4 machine somewhere?). Sure, if you can give brief instructions, on how to produce stripped builds, how to smoke test and how to upload, I will do this, but it is possible that there are people here who could do a better job, and I won't be offended to be relieved of this duty, if necessary! Ben

6 12

Google Summer of Code projects - update!
by Bryce Harrington 30 Apr '06

30 Apr '06

Hi all, I've cleaned up the list of ideas for summer of code projects, to elaborate on what the task is, why it's important, and how (in general) it should be done. I also took a stab at identifying mentors for many of them. http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code Please take a look and make sure I haven't completely misrepresented the ideas (I had to make guesses about a lot of stuff). There's also a few ideas listed at the bottom that I didn't understand well enough to flesh out; feel free to write those up in more detail. Also, if you would be willing to be a mentor for one of the ideas with a TBD mentor, please feel free to add yourself to the idea. Bryce

1 0

Developers: Refcounting
by MenTaLguY 30 Apr '06

30 Apr '06

I've finally gotten around to writing some developer documentation about memory management. Since nearly all of the memory leaks I have ever had to fix were related to refcounting in some way, I decided to start with an article about refcounting. The latest version of this article is available in SVN as doc/refcounting.txt. Please let me know if anything is unclear or incomplete. Hwæt! --- INTRODUCTION Many objects in Inkscape have lifecycles which are managed by "reference counting". Each such object has a counter associated with it, which is supposed to reflect the number of outstanding references to it. When that counter falls to zero, the object can be freed. This releases the programmer from worrying about having freed an object while somebody else is still using it (or someone else freeing while you're using it!). Simply "ref" the object (increment the counter) to stake your claim, and then "unref" it (decrement the counter) when you don't need it anymore. The ultimate decision to free the object is made safely behind the scenes. You should "ref" an object whenever you plan to hold onto it while transferring control to another part of the code (which might otherwise end up freeing the object out from under you). REFCOUNTING FUNCTIONS Ref and unref functions are provided to manipulate object counter (and make the final decision to free the object for you), but their names will vary depending on the type of object. Examples include g_object_ref()/g_object_unref() (for most GObject-based types), sp_object_ref()/sp_object_unref() (for SPObject-derived classes), and GC::anchor()/GC::release (for garbage-collector managed objects deriving from GC::Anchored -- more on that later). [ note: for code underneath the Inkscape namespace, you need only write GC::anchor(), but in other code you will need to write Inkscape::GC::anchor(), or import the GC namespace to your .cpp file with: namespace GC = Inkscape::GC; Consider this encouragement to start writing new code in the Inkscape namespace. ] REFCOUNTING POLICY Refcounted objects start with a reference count of one when they are created. This means that you do not need to manually ref one that you've just created. However, you will still be responsible for unreffing it when you're done with it. This means that during the lifetime of an object, there should be N refs and N+1 unrefs on it. If these become unbalanced, then you are likely to experience either transient crashing bugs (the object gets freed while someone is still using it) or memory leaks (the object never gets freed). As a rule, an object should be unreffed by the same class or compilation unit that reffed it. Reffing or unreffing an object on someone else's behalf is usually a recipe for confusion (and defeats the point of refcounting, really). If you pass someone a pointer, they should be the ones responsible for reffing it if they need to hold onto it. Similarly, you shouldn't try to make the decision to unref it for them. When you've unreffed the last ref you know about, you should generally assume that the object is now gone. CIRCULAR REFERENCES One disadvantage of reference counting is that a naive application of it breaks down in the presence of objects that reference each other. Common examples are elements in a doubly-linked list with "prev" and "next" pointers, and nodes in a tree, where a parent keeps a list of children, and children keep a pointer to their parent. If both cases, if there is a "ref" in both directions, neither parent nor children can ever get freed. Because of this, circular data structures should be avoided when possible. When they are necessary, try only "reffing" in one direction (e.g. parent -> child) but not the other (e.g. child -> parent). This can sometimes be trickier than it sounds -- circular references don't have to be direct to cause problems. A simple example of an indirect circular reference would be a circular singly-linked list, where the "last" element in the list points back to the "first". In that case, unidirectional reffing isn't sufficient; you'd have no choice but to delegate ref handling to some object which encapsuled the circular list, reffing and unreffing entries as it added and removed them. ANCHORED OBJECTS The garbage collector cannot know about references from some types of objects: * Gtk/gtkmm widgets * SPObjects * other GObject-derived types * Glib data structures * STL data structures that don't use GC::Alloc To accomodate this, I've provided the GC::Anchored class from which garbage-collector managed classes can be derived if they need to be referenced from such places. As noted earlier, ref and unref functions are GC::anchor() and GC::release(), respectively. For most refcounted objects, a nonzero refcount means "this object is in use", and a zero refcount means "this object is no longer in use, you can free it now". For GC::Anchored objects, refcounting is merely an override to the normal operation of the garbage collector, so the rules are relaxed somewhat: a nonzero refcount merely means "the object is in use in places that the garbage collector can't see", and a zero refcount asserts that "the garbage collector can now see every use that matters". While GC::Anchored objects start with an initial refcount of one like any other refcounted type, in most cases it's safe (and convenient) to GC::release the object immediately upon creating it. This is because the garbage collector can see references to the object from parameters or local variables. Trust the collector. One final note: when code is converted from pure refcounting to garbage collection with GC::Anchored, refs and unrefs between GC::Anchored objects should be removed. Refs are no longer necessary, and when circular references are present, reffing will lead to memory leaks. Normally (unlike pure refcounting) the collector has no problem with freeing circular references, but GC::anchor()ing a reference the collector can already see overrides the collector's judgement.

3 6