- Inkscape Devel - Inkscape Mailman

Nodetool problem?
by Thomas Holder 18 Aug '09

18 Aug '09

Hi, with svn rev 22105 (and 22073) I get unexpected node selecting behavior. So far I can reproduce: * draw first path * draw second path * switch to node tool * click on first path * click on some node Result: two nodes instead of one get selected and the mouse cursor does not switch to normal arrow when hovering to toolbar. Inkscape also froze (100% CPU for some minutes until I killed it) twice after such incident. rev 22044 is fine, so the fix for bug 168780 might have broke this. Thomas

3 3

Question about file opening function
by Mat 18 Aug '09

18 Aug '09

Hi, I want to call a funtion to open a file. I find the three function: sp_file_open_dialog(*parent, NULL, NULL); sp_file_new_default(); sp_file_open( path, NULL)； But when I call these funtions in another thread, it crash inkscape. Is there any required initialization before I call these this function? My program block is like to : ==== bool InkDBus::openFile(const string& path){ bool result = true; bool create_new = true; list< SPDesktop* > desktops; list< SPDesktop* >::iterator iter; inkscape_get_all_desktops(desktops); iter = desktops.begin(); SPDesktop* desktop = *iter; Gtk::Window *parent = desktop->getToplevel(); sp_file_open_dialog(*parent, NULL, NULL); return result; } ==== Thanks first for reading this letter :-) sincerely, Mat.

2 3

Inkscape scripting API (Draft)
by Glimmer Labs 18 Aug '09

18 Aug '09

Here is the first draft of a Dbus based Inkscape scripting API: http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html (Many thanks to the ConsoleKit team for the scripts and build system I used to generate this documentation.) I would welcome any comments or criticisms, the interface is very much still up in the air so any suggestions, from small changes to major issues, would be welcome. I would particularly like to hear if people think that this would potentially support the ways in which they use Inkscape, or whether there are use cases this doesn't address. If there are lots of uses that this interface does not support, additional interfaces geared towards different users could be added. (In fact there was originally one more interface than there is now, see document_new() for details.) If you like the current API (in general) feel free to suggest additional functions or functionality. Finally, how would you like to see this extended? Dbus has proven to be quite responsive and robust for this application. How would you build off the basic platform of the Inkscape application interface? I will keep the posted link updated as I make changes based on peoples feedback. -Soren

11 34

Cross software User Interface
by Brian Vidal 17 Aug '09

17 Aug '09

Hi there, we are starting a huge project in order to take advantage of some applications UI re-design: we want to make a huge UI redesign in the best opensource design, authoring and media creation/edition software. The need to do this is essentially, to provide a cross UI between all major media-related software. This way we can make all media-related software in the open source world to have the same and effective User Interface, so the user can work more tightly between applications and we can collaborate to each other. The project is just starting, and we want to put all of our effort to design, develop and migrate to a efficient, fast and beautiful User Interface. Please, think on it. As a starting point https://launchpad.net/linux+design+studio<http://www.launchpad.com/linux+design+studio> Hoping to make the big jump in the community. Best regards. dael99 (Brian Vidal) -- Brian Vidal

2 1

GSoC 2009 - Time to wrap things up
by Joshua A. Andler 17 Aug '09

17 Aug '09

Hey GSoC students and mentors, I just wanted to give a reminder of the schedule for GSoC. Students, today is the pencils down date. Please make sure that your mentor has access to your work today. You do have one week (until the 24th) to do any tweaks or code cleanup, but you should effectively be done at this point. Please be respectful of your mentors and don't force them into doing a last second evaluation. Also, if you are planning to use the additional time for more work, please do communicate that with your mentor. Mentors, evaluations can begin starting today and are due on August 24th. No need to rush as I'm sure we'll see some changes trickling in still. That's all for now. Cheers, Josh CCing dev list so everyone know where we're at.

1 0

SPEventContext stops receiving button1 press/release events
by Arcadie M. Cracan 17 Aug '09

17 Aug '09

Hello, I don't really understand what I am doing wrong. I have a button on the toolbar of the connector tool (InkAction) that, when gets pressed, basically creates a new knot that follows the mouse pointer. At this point (after the button is pressed) SPEventContext (for the connector tool) stops receiving any button1 press/release events. Other buttons press/release, pointer motion events are received. I don't even have a clue for where to start debugging, please help. Thank you. Following are some code exerpts: from toolbox.cpp: =========== ... g_signal_connect_after( G_OBJECT(inky), "activate", G_CALLBACK(sp_connector_new_connection_point), holder ); ... static void sp_connector_new_connection_point(GtkWidget *widget, GObject *tbl) { SPDesktop *desktop = (SPDesktop *) g_object_get_data( tbl, "desktop" ); SPConnectorContext* cc = SP_CONNECTOR_CONTEXT(desktop->event_context); if (cc->mode == SP_CONNECTOR_CONTEXT_EDITING_MODE) cc_create_connection_point(cc); std::cout<<"Done new connection point."<<std::endl; } ... from connector-context.cpp ================== ... void cc_create_connection_point(SPConnectorContext* cc) { if (cc->active_shape && cc->state == SP_CONNECTOR_CONTEXT_IDLE) { if (cc->selected_handle) { cc_deselect_handle( cc->selected_handle ); } SPKnot *knot = sp_knot_new(cc->desktop, 0); cc_select_handle( knot ); cc->selected_handle = knot; cc->state = SP_CONNECTOR_CONTEXT_NEWCONNPOINT; } } ... Regards, Arcadie Cracan

2 4

Re: [Inkscape-devel] Re : Re : Extracting a saturation map with SVG filters ?
by Jasper van de Gronde 16 Aug '09

16 Aug '09

I've attached two files which show how to replace the hue of an image with a "hard-coded" hue and the hue from a different image (a gradient in this case), respectively. Ivan Louette wrote: > Sorry for no replying earlier ! > > Thanks for the link and the explanations ! However at the moment I lack > a lot of technical skills I am afraid... I would have time to learn > programming but I must concentrate on my main project - writing a novel > - which progresses too slowly these months. This week end I was very > busy at cleaning the code of filters.svg ; the result (already > spectacular this evening) will be commited on SVN probably tomorrow in > the evening when I will have finished. Then I would concentrate on the > french filters doc (this is my mother language) I began some weeks ago > on Floss Manuals. > > Have a nice week, > > ivan

1 0

Preparing for Feature Freeze
by Joshua A. Andler 15 Aug '09

15 Aug '09

Hey All, It appears that the Frost is nearing completion, and the Feature Freeze will be setting in soon. Given this, it's probably a good time to start putting together a list of release blocker bugs, as well as discuss if any features need to be pruned due to them being incomplete. For reference, here are the bugs that are still milestoned for 0.47: https://edge.launchpad.net/inkscape/+milestone/0.47 Is anyone aware if there currently any major platform specific bugs like we had around 0.46? (win32 printing issue is what I speak of) Also, JonCruz, should we hold back the "Auto" swatch palette from this release? At this point I want to again remind people to ensure that the release notes are as up-to-date as possible! Please take a moment to ensure that your improvements/enhancements/new features are all mentioned with a brief explanation where necessary. Thanks to everyone for your contributions! Cheers, Josh

9 12

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