- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Blocking Signals
by Markus Engel 10 Mar '14

10 Mar '14

> In this case, it seems it might be doing the > wrong thing. The blocking class is what's > needed instead. Probably yes. You'd do a void ObjectsPanel::_setCompositingValues(SPItem *item) { //Block theconnections to avoid interference SignalBlockerb1(*_opacityConnection); SignalBlockerb2(*_blendConnection); SignalBlockerb3(*_blurConnection); // ... } At the end of the scope, these objects are destructed inreverse order, so this is just fine. This code is blocking around a lot, I'm not sure whetherall of this is necessary. Maybe there are better solutions to this. Regards, Markus

1 0

"Flatten" vectors
by Alexander Brock 10 Mar '14

10 Mar '14

Hi, When drawing stuff I usually have a lot of overlapping areas. Sometimes I use a vinyl cutter to cut adhesive foil. Then I need to select the topmost object and subtract it from every object which i (partially) covered by the topmost object. Next, I need to repeat the process with the second-to-topmost object etc. I also need to convert all strokes etc. to paths to actually get paths plotted with non-zero width, otherwise it's just one cut along the path which is useless. I also need to intersect all objects with their respective clip or mask, if they are clipped or masked. For complex drawings this process takes a lot of time. I wondered if there's a plugin or something for "flattening" an image like that, essentially converting it to a set of non-overlapping closed paths without stroke. If there isn't such a functionality I'd like to program it. In which way should this be done? Regards Alexander

3 4

GSOC 2014 - New patterns/paint servers UI
by Tomasz Boczkowski 10 Mar '14

10 Mar '14

Hi! My name is Tomasz Boczkowski. I would like to apply for GSOC 2014 and spend this summer coding Inkscape. I have an idea to revamp the pattern UI, currently being part of the Fill and Stroke dialog. It would consist of a new "patterns" dialog and a new on-canvas tool to edit patterns. The file new_patterns_ui.svg [2] contains my first draft, how the improved UI could look like. The new dialog would provide a way to browse, manage and apply patterns. Some basic support for grouping patterns into collections would be provided. By dragging a pattern and dropping it on an svg object or on Fill and Stroke dialog, a user could apply it. After dropping a pattern on empty canvas, a new object could be created. It would look like a mini-page and have the size of pattern. Any objects inside this object would be treated as pattern child elements. That would allow live modifications to existing patterns. An alternative to "patterns" dialog would be to implement a general "print servers" dialog, enabling to manage, besides patterns, named colors, gradients and hatches. The alternative is also enclosed in mockup drawing. I suppose I would be able to implement support for selected print servers only (eg. named colors + patterns) in GSOC timeframe. Please tell me what do you think about this idea. Is it suitable as GSOC project? Which alternative is better in your opinion? Two of my patches are accepted into Inkscape source code tree [1] and there are more to come. Best regards, Tomasz Boczkowski [1] https://bugs.launchpad.net/~penginsbacon [2] https://www.dropbox.com/s/efgwoc3a3vqn8qm/new_patterns_ui.svg

1 0

Blocking Signals
by Martin Owens 10 Mar '14

10 Mar '14

Hey Devs, I was reviewing some of the ponyscape merge today and I noticed in the object's dialog Janeczko used signal.block() and signal.unblock() to deny signals and I suspect to prevent loops and such. Is this a good pattern to use? I've come across several places where looks are caused by update and refresh signals locking up. Everything from image.cpp's update to filters dialog reorder signal. And what I found interesting was how sp-use deals with this problem. It puts update signals on a glib callback and has a mass of code for preventing the problems that sp-image.cpp gets into a lot. I'd love to hear from those more experienced with C++, GLib and signals about the best pattern to use. Best Regards, Martin Owens

4 4

Re: [Inkscape-devel] Blocking Signals
by Markus Engel 09 Mar '14

09 Mar '14

I didn't know this class existed I swear :) . Anyway, you're totally right, this unconditionalunblocking in my example would definitely have led to problems. Is there any specific reason why you store a pointerinstead of a reference to the connection? Just curious... Regards, Markus -----Ursprüngliche Nachricht----- Von: Jon Cruz [mailto:jon@...18...] Gesendet: Sonntag, 9. März 2014 21:47 An: Markus Engel; Martin Owens Cc: Inkscape Developer Mailing List Betreff: Re: [Inkscape-devel] Blocking Signals On Mar 9, 2014,at 1:39 PM, Markus Engel wrote: > Hi, > if you wantto use this, I'd suggest creating a class like this: > classsignal_blocker { > public: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/uti… Good thinking.However there is another common problem. If you block a signal, then callanother function or so that end up also blocking the signal, then the lattercode will unblock the signal early. The coderecently added in signal-blocker.h addresses this by checking at constructiontime and only blocking if it is not already blocked. Then as it is destructedit only unblocks if the instance blocked to begin with. However, we doneed to take care on when and where we block, and to minimize issues. Oneapproach is to block signals. Another is to not cause signals to be emitted inthe first place. We've had need of both those plus a few more in fixingproblems in our codebase.

2 1

Viewport, filters, and Inkscape code structure: help needed
by Tavmjong Bah 06 Mar '14

06 Mar '14

I am struggling a bit with the overall structure of Inkscape's code as I work on getting filter regions implemented correctly. This is how I understand the current structure to work: XML Tree: This represents the actual document. SP Tree: This is an expanded tree. For example: <defs> <rect id="myRect"/> </defs> <use xlink:href="#myRect"/> has two SPRect instances, one for the <rect> in the <defs> section and one generated by the <use> element. The allows for things such as style cascading and for different dimensions when the rectangles size is expressed in percent of the viewport (and there are multiple viewports in one document). Markers and symbols may also have multiple instances generated. The SP tree includes print functions used by the EMF, WMF, and TeX exporters. Other exporters (including Cairo PDF and PS) are independent of the SP and NR trees. NR Tree (e.g. Cairo Renderer): This is an expanded tree created for on-screen rendering. (Silly questions: what does NR mean?, what does 'arena' mean?) Now we come to filters. A filter can be applied to multiple objects. It's coordinates can be expressed in terms of the current viewport or the bounding box of the object that references it. In both cases, a filter's absolute coordinates can be different when applied to different objects. At the moment, only the bounding box case is handled and it is handled in the NR Tree. The NR tree doesn't know about the viewport but the SP tree does so I've tried to add code to handle the coordinates expressed in terms of a viewport into the SP tree. It seems more natural to handle coordinates in the SP tree as the SP print functions and other exporters can take advantage of these dimensional calculations. This works, kind of. There are a couple of problems: 1. The update functions of the filter primitives are not called. This can be fixed by adding explicit calls from SPFilter::update (following the model in the SPGroup update function). 2. The filter update function is only called once, at the beginning of the update process. So if a document has more than one viewport (due to an embedded SVG, for example), the filter coordinates are not updated for the second viewport. (This is unlike the <use> element case.) It seems my choices for fixing filter regions for viewport based dimensions is to either follow the <use> element example, and have instances of the filter element for each use of the element or to move all coordinate handling to the NR tree (after making the viewport available in the NR tree). The former, I think, is more desirable, but the latter may be easier. Any thoughts? Thanks, Tav

3 3

Bazzar
by Vinícius dos Santos Oliveira 06 Mar '14

06 Mar '14

Hi folks, I was reviewing one merge proposal for Inkscape, but something that would really help is something similar to git's merge-base, which gives me the common ancestor of two branches. This way, I could see the diff introduced by the new branch without being spammed/flooded by new commits that aren't interesting for my review. So, any Bazzar experts wishing to give me a helping hand here? -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 4

trunk rev 13117 broken?
by mathog 05 Mar '14

05 Mar '14

It seems I cannot build r13117 (with none of my patches) bzr revert bzr update make clean make ... In file included from /usr/include/glibmm-2.4/glibmm.h:89:0, from /usr/include/gdkmm-2.4/gdkmm/pixbuf.h:9, from libdepixelize/kopftracer2011.h:32, from libdepixelize/kopftracer2011.cpp:36: /usr/include/glibmm-2.4/glibmm/threads.h:142:11: error: field ‘gobject_’ has incomplete type /usr/include/glibmm-2.4/glibmm/threads.h: In member function ‘GThread* Glib::Threads::Thread::gobj()’: /usr/include/glibmm-2.4/glibmm/threads.h:138:41: error: ‘gobject_’ was not declared in this scope /usr/include/glibmm-2.4/glibmm/threads.h: In member function ‘const GThread* Glib::Threads::Thread::gobj() const’: /usr/include/glibmm-2.4/glibmm/threads.h:139:41: error: ‘gobject_’ was not declared in this scope make[3]: *** [libdepixelize/kopftracer2011.o] Error 1 make[3]: Leaving directory `/usr/local/src/inkscape_trunk/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/inkscape_trunk/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/inkscape_trunk' make: *** [all] Error 2 Just me? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 1

W3C SVG 1.1 test suite with trunk
by Tavmjong Bah 05 Mar '14

05 Mar '14

Hi, I've run the SVG 1.1 test suite with the latest version of trunk. Compared with 0.48, 21 tests newly pass and an additional 13 are closer to passing. There are 14 tests that no longer pass, mostly due to the feImage filter primitive no longer being able to load PNG and JPG files. (This was broken in commit 12939.) And there is one test that caused an infinite loop: struct-use-08-b.svg The test results can be seen at: http://tavmjong.free.fr/INKSCAPE/W3C_SVG_0.91/htmlInkscapeHarness/index.html There is an HTML page for each test showing the raw SVG file, and PNG results for Inkscape 0.48, Inkscape 0.49 (a snapshot from some months ago), current trunk (0.91), and the official reference PNG. The formatting isn't the best... sorry. I have not removed tests that Inkscape cannot pass due to animation or the use of the DOM. Here is a full list of the test results: New Failures 0.48 -> 0.49 coords-units-01-b.svg filters-conv-01-f.svg (edge effect) filters-displace-01-f.svg painting-marker-02-f.svg (fixed in 0.49 -> 0.91) struct-cond-01-t.svg (fixed in 0.49 -> 0.91) text-tref-02-b.svg (partial) 0.49 -> 0.91 coords-units-01-b.svg filters-composite-04-f.svg filters-displace-01-f.svg filters-image-01-b.svg filters-image-02-b.svg filters-image-03-f.svg filters-image-04-f.svg filters-image-05-f.svg filters-light-02-f.svg struct-use-08-b.svg (*** Infinite loop***) New Passes 0.48 -> 0.49 filters-background-01-f.svg filters-composite-03-f.svg (partial) filters-comptran-01-b.svg filters-conv-02-f.svg filters-displace-02-f.svg filters-example-01-b.svg filters-felem-01-b.svg (partial) filters-felem-02-f.svg (partial) filters-gauss-02-f.svg filters-gauss-03-f.svg filters-image-03-f.svg filters-image-04-f.svg filters-turb-01-f.svg masking-path-05-f.svg masking-path-07-b.svg (partial) painting-marker-07-f.svg (partial) painting-stroke-06-t.svg paths-data-10-t.svg paths-data-18-f.svg (partial) pservers-grad-17-b.svg (partial) pservers-grad-20-b.svg (partial) struct-frag-05-t.svg struct-image-02-b.svg (partial) text-altglyph-01-b.svg text-deco-01-b.svg text-text-03-b.svg 0.49 -> 0.91 filters-felem-02-f.svg (partial) painting-marker-02-f.svg (partial) struct-image-05-b.svg struct-symbol-01-b.svg struct-use-04-b.svg (partial) struct-use-05-b.svg (partial) struct-use-11-f.svg text-tref-01-b.svg Tav

3 4

Casting-macro replacement
by Markus Engel 05 Mar '14

05 Mar '14

Hi there, in r13061 I added two template functions in order to replace the tools' casting macros. You can see them in action in widgets/pencil-toolbar.cpp:110. I also added some compile-time checking there which can be uncommented later. As I just stumbled across this. In order to build clang from its svn source, you need a c++11-enabled compiler: "This is expected to be the last release of LLVM which compiles using a C++98 toolchain. We expect to start using some C++11 features in LLVM and other sub-projects starting after this release. That said, we are committed to supporting a reasonable set of modern C++ toolchains as the host compiler on all of the platforms. This will at least include Visual Studio 2012 on Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of compilers (and the C++11 features they support) is not set in stone, but we wanted users of LLVM to have a heads up that the next release will involve a substantial change in the host toolchain requirements." Should I proceed replacing the casting-macros like this? Any suggestions? Regards, Markus

5 13