- Inkscape Devel - Inkscape Mailman

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

Inkscape news as a feed
by Jared Meidal 05 Mar '14

05 Mar '14

Hi Martin, Can we add a generation of the News items from the website into RSS? I feel think would be helpful to allow users to follow us at another level. I've seen documentation for this here, but not sure if this is already something built into the django site already up. https://docs.djangoproject.com/en/1.6/ref/contrib/syndication/ Thanks, --Jared

4 7

Fwd: Re: Careful with C-strings!
by mathog 05 Mar '14

05 Mar '14

On 03-Mar-2014 13:47, Martin Owens wrote: > I'm going to rip out c-strings from uri handling. It's dangerous code > and needs to be dealt with. A c string is only "dangerous" if the programmer mistakenly thinks it works the same as std::string. Conversely, all changes to working code are dangerous since a modification introduces the risk of creating a bug and breaking the program. For the URIs it doesn't matter much what the internal storage method is, so go ahead and change that - in your branch. For bitmap images the underlying libraries, like libPNG, are not going to play nicely with std::string, and it seems a little silly to waste time and memory converting back and forth all the time, since either way in the end Inkscape just carries around a big block of memory. Similarly, a lot of glib uses gchar * (or guchar *) arguments, and some of those functions return values in those formats. It is far from clear to me that requiring everything that talks to glib to convert to/from std::string will reduce the number of bugs in Inkscape. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

Windows: default enable console output window?
by Johan Engelen 04 Mar '14

04 Mar '14

Hi all, Is it OK if I enable the extra console output window per default on Windows? (i.e. build with "-mconsole" instead of "-mwindows") We should disable it in finale releases, but I think in trunk it should be enabled so people can always see the messages that trunk generates. Thoughts? -Johan

4 4

Re: [Inkscape-devel] Inkscape joins the Open Invention
by Jared Meidal 04 Mar '14

04 Mar '14

I have that content copied and published on the main site now. I'll stand by for any adjustments needed. --Jared > -----Original Message----- > From: Bryce Harrington [mailto:bryce@...961...] > Sent: Sunday, March 2, 2014 10:32 PM > To: Martin Owens > Cc: Jared Meidal > Subject: Re: [Inkscape-devel] Inkscape joins the Open Invention > > On Sun, Mar 02, 2014 at 09:29:49PM -0500, Martin Owens wrote: > > On Sun, 2014-03-02 at 15:44 -0800, Bryce Harrington wrote: > > > Thanks, currently I get a error page at that url. "Could not import > > > inkscape.person.views.register. View does not exist in module > > > inkscape.person.views." > > > > That's my fault. Sorry for the downtime. > > No prob, it's why we have a staging site right? :-) > > So, the GSoC section looks great. I think we might be able to say more in fewer > words... let me have a try at copyediting it down: > > """ > This is Inkscape's 10th year mentoring in Google's Summer of Code. > Students, please see our <Summer of Code wiki page>[1] for directions. > Find an <idea>[2] that interests you, and <let us know>[3]! > """ > > 1: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code > 2: > http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code#Suggested_Ide > as > 3: http://wiki.inkscape.org/wiki/index.php/SOC_Application_Template > > Bryce

2 1

Swatch dialog has a serious bug
by Johan Engelen 03 Mar '14

03 Mar '14

Hi all, I just discovered a very serious bug in the swatches dialog (/src/ui/dialog/swatches.cpp). Using a vector of DocTrack*, it tracks all current documents, and using a timer callback updates itself. The problem is, no DocTrack* is ever removed from that list. A DocTrack* (that points to an SPDocument) is added whenever you open a new document. Then when closing a 2nd document, the DocTrack* should be removed from the list and ~DocTrack should be called. Because this is _not_ happen, the timerfunction will use an already deleted SPDoc and will eventually crash in SPDocument::getResourceList (priv is set to nullptr for deleted SPDoc). I added proper ref-counting of the SPDoc object in DocTrack's constructor and destructor, but still the SPDoc is deleted and the crash occurs. Some code in swatches.cpp looks unfinished, creating data structures that are never used... Thanks for any help in tracking down and fixing the issue, Johan

2 7

python extension preview information
by TimeWaster 02 Mar '14

02 Mar '14

hi, for "my" plotter extension i would like to implement a preview functionality. right now i can't do that because the preview would overwrite the document permanently once one hit the apply button. it would really help if there was a way to know if the call to the extension was made for the preview (preview checkbox) or the final rendering (apply button), or if the above is not possible, if there was an .inx tag attribute preventing inkscape from using the extensions ouput as the final document while still maintaining preview functionality. maybe it makes sense to implement both. i could imagine multiple solutions for that: - add a parameter to the extension call identifying the preview state - add an preview state attribute to the document's internal structure (the svg tag perhaps) - add an attribute to the effect tag in the .inx file format: <effect needs-live-preview="true" needs-document="true" discard-final-result="true"> i think it would be a beneficial feature for other extensions as well. i could imagine that an extension could do a rough rendering for preview while still providing the fine rendering for the finished result, this could greatly improve speed and handling on some extensions. since i am no C programmer i can not do it, but if someone could implement such a feature my eternal gratitude for him/her would be certain. with kind regards, TimeWaster

1 0

SVG feature angled CAP
by Jabiertxo Arraiza Cenoz 02 Mar '14

02 Mar '14

Hi to all. Is or could be in the roadmap of SVG this feature: "angled CAP" for svg:path. Could be very useful at design. I made a svg to explain well.

1 2

0.48.5
by Josh Andler 01 Mar '14

01 Mar '14

Hey All, Since we're obviously not going to be getting 0.91 in Ubuntu 14.04, it seems reasonable that we should try to get 0.48.5 in it instead. Are there any pending items people have for backporting? Cheers, Josh

2 1

Why is the position of this line of code so touchy?
by mathog 28 Feb '14

28 Feb '14

In the files in src/display there are many instances of this Inkscape::DrawingContext::Save save(dc); First thing, I don't understand the syntax. What does the lower case "save" in that line indicate? The only places "::Save save(" appear in the source code are instances of this line. Secondly, it acts strangely. Moving it around breaks graphics for some reason that escapes me. For instance this: Inkscape::DrawingContext::Save save(dc); //PROBLEM LINE dc.transform(aff); double thickness = decorateItem(dc, aff, phase_length); dc.setLineWidth(thickness); dc.strokePreserve(); dc.newPath(); results in mangled graphics (text decoration drawn as if with a very thick line, but in what appears to be the correct location), whereas moving the first two lines above into double DrawingText::decorateItem(DrawingContext &dc, Geom::Affine const &aff, double phase_length) as the first two lines of that method results in normal graphics (text decoration drawn with the expected line thickness). That is: line1 line2 call is broken but call (inside called function) line1 line2 works. Moving "dc.setlinewidth()" from the position shown above into decorateItem() as the line before its return does not make any difference in either of these cases. decorateItem() just defines a cairo path with moveto/lineto on _ct in dc, it doesn't touch anything else in the dc. Using the debugger and stepping through showed that execution of the problem line passes through this: DrawingContext::Save::Save(DrawingContext &dc) : _dc(&dc) { _dc->save(); } in drawing-context.cpp. _dc->save() just does cairo_save(_ct); I have never seen anything quite like this when using cairo directly, that is, calling cairo_save() and cairo_restore() has never resulted in mysteriousness of this level. And that seems to be mostly what the DrawingContext does - it keeps track of (private) cairo_t *_ct; I would have thought that passing dc by reference should have made the position of the problem line before the call, or just within the called function, a moot point, but apparently not. This is so even though when the address of _ct was checked with dc.raw(), before and after the problem line, it didn't change. Whether or not the problem line was before or inside decorateItem(). Can somebody please explain what is happening here? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 5

Href sub-document model
by Martin Owens 28 Feb '14

28 Feb '14

Hey developers, This is the model I'm going to implement for documents to reference other documents: SPDocument { GSList *child_documents; SPDocument *parent_document; // Parent of parents until parent == NULL; SPDocument *getRootDocument(); } Then in uri-reference, check paths of existing child_documents, load the referenced document and add to child_documents. Set parent_document. That should keep things consistant. The idea here is that we'll use this to track documents referenced in <use tags> as well as <image tags> and attributes like 'marker-*: url(...);' but not for non-vector graphics used in the image tag. Thoughts? Advice? Best Regards, Martin Owens

6 23

Image Data URIs
by Martin Owens 28 Feb '14

28 Feb '14

He devs, I've been trying to read up on image tags special case, where a href will start with data: and then proceed to have data. Since I want to merge most of the sp-image logic into Inkscape::URI I need to know if data uris are something the svg spec says should only be available to image tags... or should be available to any href. The svg 1.1 spec says nothing about data uris that I could find. Any ideas? In the end, I want hrefs to be able to be loaded, processed into localised absolute references and even parsed for data if that's generic. From the same Inkscape::URI object. Does this seem sensible? I note the css url(...) handler isn't the same as the href handler; so should something be done to help those converge too? Any thoughts would be appreciated. Martin,

3 2

Inkscape joins the Open Invention Network
by Bryce Harrington 28 Feb '14

28 Feb '14

Inkscape has been invited to join as a member of the Open Invention Network. On Tuesday, the Inkscape Board voted in favor. In so doing we pledge to never use patents aggressively against the Linux System. We would never do this of course so the step is merely symbolic, but an important symbol. We are joining almost 750 projects and companies from the software industry (see http://www.openinventionnetwork.com/licensees.php) in a pledge that covers over 2,100 Open Source packages. This helps to reduce risk on the core Linux System and other middleware technologies. Valer Mischenko of OIN sums it up: "This is the largest community to address software patent challenges in the world. The idea is: when everybody pledges freedom, there will be no wars." For more information, please read on, or go to openinventionnetwork.com Bryce ------------------------------------------------------------------------ Subject: Re: [Inkscape-board] [REFERENDUM] Should Inkscape Join the Open Invention Network? Resolved: The Inkscape Project agrees to join as a member of the Open Invention Network. In so doing we pledge to never use patents aggressively against the Linux System. Votes: Five votes in favor, none against. Motion passes. Josh Andler a Johan Engelen a Bryce Harrington a Jon Cruz a Tavmjong Bah a (Votes not received from Ted Gould and Mental Guy) http://sourceforge.net/mailarchive/forum.php?thread_name=20140225080118.GB2… On Sun, Feb 23, 2014 at 11:38:07PM -0800, Bryce Harrington wrote: > Proposal: > > [ ] a. Join the Open Invention Network (OIN). Pledge that the > Inkscape organization would never use patents aggressively > against the Linux System. > [ ] b. Remain independent from the Open Invention Network. > > > Background: > > Hi Bryce, > > My name is Valer and I am writing to you on behalf of the Open Invention > Network (OIN). Our mission is to support projects developing or using > Linux-related and open source technology by deterring patent aggression. > > We do this through a community that pledges not to assert patents > against each other over the Linux System technology. This pledge covers > over 2,100 Open Source packages. It is structured to reduce risk on core > operating system and middleware technologies. Almost 750 projects and > companies from all areas of technology creation, deployment and use have > joined our community so far (see not very up to date list: > http://www.openinventionnetwork.com/licensees.php) > > We want to invite Inkscape to our community. > > You may be interested in our community credentials and to get some more > context about our work. Here is an endorsement from Eben Moglen, > Chairman of the Software Freedom Law Center: > http://emoglen.law.columbia.edu/now/organizations/OIN > > Here is an endorsement from Jim Zemlin, Executive Director of the Linux > Foundation: > http://www.linux-foundation.org/weblogs/jzemlin/2009/09/09/protecting-linux… > > Our community is free to join. The only thing we want is a pledge that > Inkscape would never use patents aggressively against the Linux > System. Of course it never will, and that's a symbolic gesture, but it > remains very important for our work. When we also bind big companies > with this pledge we are sure they will not attack ç in this context for > example. But their participation in OIN is also very important in > various other aspects. > > And these companies are numerous. For example Valve Software and Dropbox > are on of the latest bigger companies joined in. UnitedStack from China > joined just a weeks hours before. Pretty much everyone else is in there > too, from Red Hat to GNOME, Fujitsu to CentOS, Google to KDE to > OpenStack Foundation. This is the largest community to address software > patent challenges in the world. The idea is: when everybody pledges > freedom, there will be no wars. > > We are passionate supporters of the Linux System and open innovation. I > hope we can work together by welcoming Inkscape to our non-aggression > community. Every single voice helps us face current market challenges > while investing in a more collaborative future. > > Attached is a very short overview of OIN + FAQs, but I am happy to > answer any questions and to explain in more detail why the pledge of > Linux System and open source patent non-aggression is so important for > open innovation. > > May you decide positively there is a possibility to sign online: > http://licenses.openinventionnetwork.com > > Please consult to Johan, Tavmjong, Ted and Josh and let me know what you > guys think. > > Regards, > Valer Mischenko, > Open Invention Network > > www.openinventionnetwork.com

3 4

Potential GSoC 2014 project
by Krzysztof Kosiński 28 Feb '14

28 Feb '14

Hello As promised, here is a description of the project I could do as a student. The end goal of my MSc project is to write an OpenGL-based 2D scene graph library usable by Inkscape which is capable of displaying most of SVG. Unlike the Cairo OpenGL backend, this library would keep the data on the GPU as long as it's used, and only control points of the curves would be submitted to the GPU, which should give very good performance. However, this project has several prerequisites. The OpenGL drawing algorithm I'm thinking about (Loop-Blinn) handles only quadratic and cubic Bezier fills, so it would require substantial support from 2Geom to render SVG. http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html For this GSoC, my proposal would be to implement boolean operations and the stroke-to-fill transformation in 2Geom (since I think the latter depends on the former). Some of the required code is already present, for example the code to compute the offset of a single curve, but it's not exposed in an usable form. The project would be both about implementing the missing parts and providing an easy to use API. Here are the potential work-items: 1. Convert Geom::PathVector to a real class. 2. Investigate whether it is possible to store curve data in a more efficient format that does not store every curve endpoint point twice (as a start point and as an end point). 3. Provide and document an API to the existing intersection code. 4. Provide and document an API to the existing curve offset code. 5. Implement path uncrossing and monotonization. 6. Implement boolean operations, based on the algorithm used in CGAL. If necessary, add CGAL as a dependency - this is now acceptable, because CGAL in Debian no longer depends on Qt. 7. Implement stroke-to-path. As a backup option, I'm considering changing my MSc project to implementing a Python scripting console for Inkscape. If I were to pick that instead, the GSoC project could involve a variety of refactoring tasks intended to simplify writing the Python bindings used by the console. In this case, I'm 100% sure that I could do it, whereas in the case of OpenGL I still have some doubts, mainly because I haven't programmed in OpenGL yet. Regards, Krzysztof

9 14

Wiki down again
by John Cliff 28 Feb '14

28 Feb '14

Hi guys, The wiki seems to be down again, have checked with a couple of is it up type sites, and their all unable to see it. Have pinged an email to the osuosl support address about it. Thought I'd let you all know before anyone else did too. Cheers John

2 1

Ellipses and other shapes may be modified on load
by Krzysztof Kosiński 28 Feb '14

28 Feb '14

Hello It looks like the recent changes to make ellipses use the correct SVG element cause incomplete undo events being left on the undo stack when a document containing old ellipses is loaded. To see for yourself, load the attached document and press Ctrl+Z. This is causing crashes in some scenarios, one of which is detailed here: https://bugs.launchpad.net/inkscape/+bug/1001756 The culprit is the update_patheffect() function of SPGenericEllipse, which writes to the XML tree and is called by document->ensureUpToDate(). This write happens even if the object in question does not have any path effect. Under the SP tree model, writing to the XML tree in response to view changes or update events is not permitted. For now, I have hacked around this by disabling undo tracking when ensureUpToDate() is called from SPDesktop::init(), but the proper solution would be to avoid rewriting the LPE result when loading, and prevent the update_patheffect() function from rewriting shapes which do not have any LPEs. Regards, Krzysztof

1 0

Summer of Code 2014
by Josh Andler 27 Feb '14

27 Feb '14

Hey All, We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1). If you are interested in participating as a student please visit our page on Melange (2) to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year. Cheers, Josh (1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape

9 17

Re: [Inkscape-devel] URI
by Markus Engel 26 Feb '14

26 Feb '14

> auto initalising (c++ does this right?), C++ implicitly calls the default constructor for allmembers that are not initialized in the containing class's constructorinitializer list. Note that only *objects* are default initialized this way,atomic types are not (int, pointers, ...). They contain garbage until youassign them a value. class Member { public: Member(int i) {} }; class Container { public: Container() {} private: Member member; }; Thus, this will not compile. Instead you'll have to writethe constructor this way: Container() : member(42) {} I'm not sure whether you should add a parameterlessconstructor to Inkscape::URI. I mean, is an empty uri valid? Does it make senseto be able to create an uri this way, or is it's "path" necessary forthe object to have any sense at all? Regards, Markus -----Ursprüngliche Nachricht----- Von: Martin Owens [mailto:doctormo@...400...] Gesendet: Mittwoch, 26. Februar 2014 13:32 An: Krzysztof Kosiński Cc: Markus Engel; inkscape-devel Betreff: Re: [Inkscape-devel] URI Digging into the job, I've ripped away dom/* and most ofthe code works. I've ported color-profile.cpp which was using thedom::URI to Inkscape::URI and the same replacement can be done to odfextension. A missing piece was zipfile support. src/dom/util/ziptool.cpp/.h was a self-contained zipimplementation so I've moved that to src/util/ since it has no equivalentfunctionality. That worked well. I've hit a small problem with Inkscape::URInot having a constructor with no-arguments which I think can be solved byadding an OdfOutput constructor which initalises the URI instead of it autoinitalising (c++ does this right?), but this seems odd to me as if the Odfshouldn't initalise the URI until it needs it. Thoughts? Best Regards, Martin Owens

1 0

Re: [Inkscape-devel] URI
by Markus Engel 26 Feb '14

26 Feb '14

You may simply remove everything except the util folder,and dom.h domimpl.cpp domimpl.h domptr.cpp domptr.h ucd.cpp ucd.h uri.cpp uri.h Actually, that's about 50000 lines less :) . ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 797 60098 60211 295830 C/C++ Header 1060 32179 58535 90647 ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C++ 782 57002 57216 286170 C/C++ Header 1037 24443 43941 77657 Regards, Markus -----Ursprüngliche Nachricht----- Von: Martin Owens [mailto:doctormo@...400...] Gesendet: Dienstag, 25. Februar 2014 17:59 An: Bryce Harrington Cc: Inkscape Devel List; Inkscape User Community Betreff: Re: [Inkscape-devel] URI On Mon, 2014-02-24 at 23:51 -0800, Bryce Harringtonwrote: > 2. Remove dom/ directory > This directory contains strange code which is barelyused. The only > class which is actually used is the URI class. That's worth knowing, I'll hack that up in my branch as Iadd the data uri support. Martin,

3 2