- Inkscape Devel - Inkscape Mailman

Better hrefs
by Krzysztof Kosiński 15 Aug '09

15 Aug '09

Hello all Currently we have some handling for hrefs (in the form of Inkscape::URIReference). It provides some signals and callbacks, but doesn't do everything that I would like it to. To be specific, there are several places when solving the following problems efficiently would be a great thing: 1. Given an object, iterate over all references to it. 2. Given an object, iterate over all objects it refers to. Point 1 is useful for all sorts of things: marking objects for update, compensating clones, deletion, vacuum defs, etc. Point 2 would allow to remove 80% of clipboard code, and implement robust ID changing and clash prevention (which means, one that doesn't have to be updated whenever a new href-like attribute is added). Here is my idea. We define a three-way smartpointer that looks like this: class ObjectRefBase { ... SPObject *obj; ObjectRefBase *next; ObjectRefBase *next_ref; }; template <typename T> class ObjectRef : public ObjectRefBase { ... }; template <typename T> ObjectRef<T> const &getRef(T *obj) { return static_cast<ObjectRef<T> const &>(*obj); } The 'next' and 'next_ref' pointers form a singly-linked cyclic lists. Each SPObject contains such a smartpointer (by protected inheritance: 'class SPObject: protected ObjectRefBase, ... {') that can be accessed using the getRef function, which is a templated friend of SPObject and returns an ObjectRef of correct type. The header of both lists is the pointer contained in the referenced object; it has 'obj' set to itself. 'next' allows us to iterate over references to this object, while 'next_ref' - over references contained in this object. The constructor might look like this: ObjectRefBase(SPObject *owner) { if (owner == this) { obj = this; next = this; next_ref = this; } else { next_ref = owner->next_ref; owner->next_ref = this; obj = NULL; next = NULL; } } If this is the embedded instance from protected inheritance, the the first test will be true and both lists will be initialized as empty (an empty cyclic list is represented by the header node having a next pointer pointing to itself). The assignment operator is as follows: ObjectRefBase &operator=(ObjectRefBase const &other) { if (obj != NULL) { ObjectRefBase *cur = this; while (cur->next != this) cur = cur->next; cur->next = obj->next; } next = other.next; other.next = this; } If the reference pointed to some object, the function walks the list and removes the reference from the linked list of the previous object; it then inserts itself into the linked list of the new object. The destructor works similarly: ~ObjectRefBase() { ObjectRefBase *cur = this; while (cur->next != this) cur = cur->next; cur->next = obj->next; cur = next_ref; while (cur->next_ref != this) cur = cur->next_ref; cur->next_ref = next_ref; } Now we can iterate over the references to an object like this: for (ObjectRefBase *cur = this->next; cur != this; cur = cur->next) { // do something with each reference to this object } And over references contained in an object like this: for (ObjectRefBase *cur = this->next_ref; cur != this; cur = cur->next_ref) { // do something with each reference stored in this object } Testing whether the object has any indirect references is dead simple: this == next. Same for checking whether this object refers to anything: this == next_ref. The owner of a reference can be retrieved in linear time (by walking next_ref until we encounter next_ref == obj). All this of course can be encapsulated into a nice STL-like iterator interface which provides some extra type safety not present in ObjectRefBase (for example, we know that all ObjectRefs which we can reach via 'next' point to the same type). Handling CSS properties with URI references that are not members of the object is easy as well: ObjectRef doesn't need to be a member of the owner for all this to work. There are no boilerplate attach() / release() methods: the assignment operator of ObjectRef takes care of everything. If walking the lists during reassignment and destruction turns out to be a performance problem, we can make both lists doubly-linked rather than singly-linked, where a node can be removed in constant time, at the price of 2 more pointers stored in each reference. Fast owner retrieval additionally requires storing the owner pointer. This gives 5 pointers of overhead, so for 10000 references on a 64-bit machine we get 390KB of overhead - should be manageable. I thought about a trick that can be used to implement constant-time erase on a cyclic single list (the iterator actually points one node before and we use cur->next->value to get the value), but it can't be applied here. Why this is better than keeping pointers to the references in std::list or std::vector? - no memory allocations when adding a reference = better performance. - removing a reference is much simpler, because finding it in the list is not needed. - signals can be put in the ObjectRef class. - simple and elegant implementation. What do you think? Improvements and discussion welcome. Regards, Krzysztof -- View this message in context: http://www.nabble.com/Better-hrefs-tp24939304p24939304.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 10

Live path effects - better XML representation
by Krzysztof Kosiński 14 Aug '09

14 Aug '09

While rewriting the node tool I necessarily had to look into path effects. Live path effects are currently seem to be represented by a single svg:path that has information on what the original path looked like in the inkscape:original-d atribute, the applied effects in another attribute, and additional. I think this is not very flexible, because it does not allow for example nondestructive boolean operations where both operands are other path effects. What do you think about this representation: 1. A live path effect is represented by an svg:switch element. An Inkscape-specific attribute can be added to it to simplify implementation, but it is not really necessary. 2. The first element in that svg:switch is an inkscape:path-effect element that contains all the information about objects it was generated from. Shape parameters are represented as inkscape:path-effect-param elements that can contain anything including svg:use, svg:rect, svg:path, another inkscape:path-effect etc. This could allow very nifty things like live boolean operations. It would also simplify the node editor, because it could just operate on the invisible children of inkscape:path-effect while being completely unaware of path effects. As bonus points, path effects created from rectangles, circles, spirals, etc. could preserve the editing capabilities of those shapes. 3. The second element would be an svg:path that contains the result of the path effect, style properties, etc. 4. When opening the file in Inkscape, it would only look at inkscape:path-effect and recompute the fallback svg:path whenever something changes. When opening in another SVG viewer, it would only display the svg:path. 5. To handle live boolean operations, there would be an additional parameter for shapes that says whether they are 'live'. If a shape is 'live', all boolean, offset, etc. operations would create path effects instead of paths, similar to how linked offset works now. In fact, the destructive versions could be implemented as a combination of creating a path effect and an object-to-path conversion. 6. Path parameters would accept any SPShape. There would be a separate type of parameter that accepts a group of shapes. To convince an effect to accept an object group as a parameter, a special effect called Flatten Group would be provided - it would convert a group into a path effect suitable for use as a parameter for another one, and could optionally use a clone rather than the original for flattening. Now some use cases: 1. To create an outline of some collection of objects, we create clones of them, group them, apply Flatten Group and then Offset. Result: whenever any of those objects is moved or modified, the outline updates. 2. The sun and cloud example in http://wiki.inkscape.org/wiki/index.php/Lpe-blueprint would be dead simple: create the circle and the sun ray, use pattern along path; create a clone of the cloud, make it 'live', create an offset; then apply a live subtraction between the sun and the clone. Updating any of the original shapes will now change the appearance. (As a related note, compensation on moving should not be a global property, but a property of the clone! As demonstrated here, we want the invisible clone used for the path effect to move with the cloud, but we want other visible clones to stay where they are when the original is moved) UI changes: The LPE stack would need to be changed into an LPE tree like the layer dialog. The path effect tool would allow the editing of various parameters using control points and the node editor; selecting an item in the tree would cause its editing controls and toolbar to appear. Live path effects would be created from a menu rather than from the tool, like dynamic offset. Internal changes: SPLPEItem would be removed, and SPShape would be used as the type of object that can be used as a path parameter. What do you think? I think when done this way, path effects (or maybe they should be called Vector Effects, because they're not really limited to paths?) provide a generic vector equivalent to filtering. This means they could become super-powerful, and in fact the main method of editing complex drawings. There would be some problems with legacy live path effects, but it can be dealt with at document load. PS I just noticed this is somewhat similar to the vector effects proposal in SVG 1.2. It might be wise to plan ahead and make it easy to optionally store some path effects as an SVG 1.2 vector effect. Regards, Krzysztof -- View this message in context: http://www.nabble.com/Live-path-effects---better-XML-representation-tp24778… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 20

Bug Hunt passes 500!
by Tavmjong Bah 14 Aug '09

14 Aug '09

The current bug hunt tally is now 507/500. We have reached the mark! Newly fixed bugs: 6 379977 buliabyak Imagemagick Raster extensions not working 3 308183 JazzyNico Measure Path text shifted when used with a copied object 6 168780 Papouin 0.45 on winxp: Mouse not properly captured.. 6 373309 A. Johnson Print has offset on page 12 166678 A. Johnson Paper size or orientation are not used when printing 9 304018 buliabyak Crash when using LPE with node tool selected 3 407893 buliabyak Text Tool attributes messed up. 9 376068 buliabyak Inkscape 0.46_5 Segmentation fault on gradient edit Top Bug Hunters (With 30 or more points): 120 van Lierop 57 theAdib 45 Bulia Byak 36 JazzyNico 33 T. Holder 30 Jon A. Cruz Special Mention for most active bug reviewing: ~suv Tracked at: http://wiki.inkscape.org/wiki/index.php/Release_Info_for_0.47 Tav

2 2

Quick File Import Test
by Tavmjong Bah 13 Aug '09

13 Aug '09

Hi, I just did a quick File Import Test. I did not test all possibilities. Here are a couple problems: 1. .wmf There are two options. One via Uniconverter and the other from GDK. Do we need both? 2. Images in PDF appear to be imported upside down. Tav

1 0

From *.o compilation to Inkscape.exe
by Yann Papouin 12 Aug '09

12 Aug '09

Hi, In Build.xml there is three main steps: 1. Compiling *.cpp into objects 2. Linking *.o into static libinkscape.a 3. Compiling and Linking "Main" with libinkscape.a Actually I'm using the IDE Code::Blocks (with the same mingw compiler) to debug inkscape and I'm able to do the same things that the Build.xml does. My problem are these three steps, I would like to create Inkscape.exe without having to create a static library because with the -g parameter linking in (2) and (3) took so long !!! So I tried to bypass the "libinkscape.a" creation but it's not working. Someone already did this before ? Yann.

2 2

removed files from trunk/share/extensions still present after svn update/make/make install
by ~suv 12 Aug '09

12 Aug '09

When updating Inkscape to the most recent SVN revision I use: | svn update | make | make install and then build the application bundle for macosx. When files are removed from trunk/share, like recently some extensions (in rev. 22049), those files still exist in 'Build/share/inkscape/extensions' and are not removed when I do 'make' and 'make install' after 'svn update'. Do I have to manually clean the Build/share directories when updating from SVN, or is there a make target that specifically does this instead of the overall 'make clean'? The issue has come up before with packages for win32 which included long gone extension files. On a side note - the build date (shown in the about screen) also doesn't update with every make/install/package cycle - though the revision number is always correct. tia, ~suv

2 1

STL Containers related question...
by Arcadie M. Cracan 12 Aug '09

12 Aug '09

Hello all, I have an issue with STL std::map. Here's a quick description. I have a member in SPConnectorContext structure that is a map: std::map<SPKnot* , ConnectionPoint> connpthandles; Having the following code in a function produces a sigfault: cc->connpthandles[knot] = it->second; where cc is a pointer to SPConnectorContext. I have also defined a local variable std::map<SPKnot*, ConnectionPoint> cph_clone; and the following instruction executes all right cph_clone[knot] = it->second; It seems that somehow the connpthandles map gets scrambled or improperly initialized. I don't know why this is so. Any help is welcome. Regards, Arcadie

2 2

GSoC 2009 - Nearing the end
by Joshua A. Andler 12 Aug '09

12 Aug '09

Hey Mentors, As you are probably aware the "soft" pencil's down date for the students was yesterday. The more firm date being next Monday, the 17th. They will technically have up until the 24th to get the finishing touches on things as far as grading is concerned. Please talk to your respective students to ensure that you can provide the best mentoring possible for the time they have left and to see what the community can do, if anything, to help them succeed. CCing the devel-list so people know that we're near the end. Cheers, Josh P.S. To the list members... the projects will get merged in when we get 0.47 out the door... so if you're itching for the new features, look at this as a booster shot to help make 0.47 happen that much sooner. ;)

1 0

Inkscape Wiki: please restore Release notes/0.46
by ~suv 12 Aug '09

12 Aug '09

Some mishap seems to have wiped out the release notes for Inkscape 0.46. Does anyone have access to a backup and knows how to restore it? Having the release notes available is helpful to answer questions on <https://answers.launchpad.net/inkscape> and for bug triage as well. tia, ~suv

2 4

Build still broken...
by Tavmjong Bah 11 Aug '09

11 Aug '09

Still no joy in Mudville. After seeing failures in a variety of different ways with each new check-in, the build is stuck on box3d.cpp: box3d.cpp: In function ‘Inkscape::XML::Node* box3d_write(SPObject*, Inkscape::XML::DocumentTree*, Inkscape::XML::Node*, guint)’: box3d.cpp:281: error: invalid use of incomplete type ‘struct Inkscape::XML::Document’ ./xml/xml-forward.h:23: error: forward declaration of ‘struct Inkscape::XML::Document’ box3d.cpp: In function ‘Geom::Matrix box3d_set_transform(SPItem*, const Geom::Matrix&)’: box3d.cpp:342: error: cannot convert ‘Inkscape::XML::Document*’ to ‘Document*’ for argument ‘1’ to ‘Persp3D* persp3d_create_xml_element(Document*, Persp3D*)’ box3d.cpp: In function ‘SPGroup* box3d_convert_to_group(SPBox3D*)’: box3d.cpp:1382: error: invalid use of incomplete type ‘struct Inkscape::XML::Document’ ./xml/xml-forward.h:23: error: forward declaration of ‘struct Inkscape::XML::Document’ box3d.cpp:1395: error: invalid use of incomplete type ‘struct Inkscape::XML::Document’ ./xml/xml-forward.h:23: error: forward declaration of ‘struct Inkscape::XML::Document’ box3d.cpp:1421: error: invalid use of incomplete type ‘struct Inkscape::XML::Document’ ./xml/xml-forward.h:23: error: forward declaration of ‘struct Inkscape::XML::Document’ Tav

8 10