August 2013 - Inkscape Devel - Inkscape Mailman

dom/cssreader.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, For those who know about dom/cssreader.cpp, is this code correct? In CssReader::getPage(int p0): int p = p0; ..... XMLCh ch = get(p); if (p != '{') { error("@page requires '{' before declarations"); } Shouldn't that be if (ch != '{') ? It happens a number of times in that function and looks like a bug to me. If it is indeed correct the way it is now, please add comments to those locations, because it is quite confusing. Thanks, Johan

1 0

display/sodipodi-ctrl.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, Hope that someone who knows a bit about /src/display/sodipodi-ctrl can help me with these lines: for (y = 0; y < side; y++){ px = reinterpret_cast<guint32*>(data + y * r); for (x = 0; x < side; x++) { *p++ = *px++; } } The "px++" is not necessary right? Should just be "px" the way I see it. (while fixing it, please also reduce the scope of px) Thanks, Johan

1 0

[CAD] Status
by Sebastian Götte 05 Aug '13

05 Aug '13

Hi, I just pushed some changes to launchpad that fix the GObject instantiation problem I had [0]. I am now explicitely initializing the members to 0. Next comes some cleanup integrating the feedback I received. The current code allows one to place SPPoints and SPConnectors in the document, the three major problems left are state handling in the ConnectorContext (dragging does not work yet), live preview (the "red curve" is not displayed/updated yet) and a missing/superfluous display->doc transform. I just finished moving into a new flat so I did not spend a lot of the last few days at my computer. Best regards, Sebastian [0] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files/

3 2

Re: [Inkscape-devel] GObject removal branch
by Markus Engel 04 Aug '13

04 Aug '13

Hi, I'm on vacation from now until (probably) August 21. Thus, I may be able to answer e-mails but I can't work on my branch actively. I opened a merging proposal on launchpad. Maybe any of you can have a look at it and, if no other critical bugs appear, merge it? Regards, Markus

1 0

floating dialog transient behavior
by Johan Engelen 04 Aug '13

04 Aug '13

Hi all, I came across this code: void FloatingBehavior::onDesktopActivated (SPDesktop *desktop) { Inkscape::Preferences *prefs = Inkscape::Preferences::get(); gint transient_policy = prefs->getIntLimited("/options/transientpolicy/value", 1, 0, 2); #ifdef WIN32 // Win32 special code to enable transient dialogs transient_policy = 2; #endif Why is transient_policy hard-coded to 2 on Windows? And why not just set the transient_policy option to 2 per default for Windows? Thanks, Johan

2 2

memset on SPStyle
by Johan Engelen 04 Aug '13

04 Aug '13

Hi all, I just came across this piece of code: memset(style, 0, sizeof(SPStyle)); That looks terrifying! SPStyle is a huge struct, containing member objects (sigc::connection) besides just simple integers and enums. CPPCheck complains with "Using 'memset' on struct that contains a virtual method.". I can't find any virtual methods in SPStyle, but still it looks like a bad bug. I have disabled that line of code, and added extra re-init lines in r12452. Please have a look and confirm the fix. Thanks, Johan

2 3

[Tracing] Library integration/API design
by Vinícius dos Santos Oliveira 03 Aug '13

03 Aug '13

So, I reached a point where I know how the next steps can be implemented, but, differently from before, the next steps on libdepixelize can have a big impact on how it will be integrated on Inkscape. I decided it would be a good thing to discuss this matter with other developers. Currently it's possible to represent simple paths on libdepixelize (see this), but to implement the full Kopf-Lischinski algorithm, I'll need to have paths with "holes" and I'll need to use complex path representations with enough expressive power to communicate things like "point start in A, then do a Bézier to C...". I don't want to create a new interface to represent paths, because this interface already exists and it's called SVG. Anyway, I'm sending this message now, but I'll look deeper in Inkscape code and come up with some design ideas later. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

3 4

Automatic tests now in PPA
by Alex Valavanis 03 Aug '13

03 Aug '13

Dear All, I have enabled automatic testing (make check) in the trunk PPA, so we'll now have an early warning system for runtime errors. Please can I draw your attention to the known test failures [1]: #1202271 cxxtest: preferences-test.h fails #1208002 cxxtest: svg-length-test.h fails (in progress) #1208005 cxxtest: svg-path-geom-test.h fails #1208013 cxxtest: curve-test.h fails #1207502 cxxtest: svg-affine-test.h fails At the moment, PPA builds will (correctly) fail if the extension tests fail, but will still succeed in the case of errors in Inkscape itself until we fix *all* of the broken tests above. It therefore makes sense to try to fix all of these in time for Inkscape 0.49 so that we have a correctly functioning unit test system. If no one objects, I'll target all of those bugs to Inkscape 0.49. Thanks, AV [1] https://bugs.launchpad.net/inkscape?field.searchtext=cxxtest&search=Search&…

1 0

Re: [Inkscape-devel] GObject removal branch
by Markus Engel 03 Aug '13

03 Aug '13

>> So far, only the crash with the text tool can be reproduced >> consistently (after 4 or at most ~8 times tapping the space bar). >> >> However, with some patience I'm able to make your branch crash when >> tool-switching with other tools as well: > >The backtrace looks like a double-free. There could be some leftover manual calls to member constructors / destructors in InkNodeTool >and SPTextContext. > >Regards, Krzysztof Hm, I didn't find any, but I'm sure this has got to do with the way I rewrote the part that switches the tools, see src/desktop.cpp:675. The old method is right underneath it, commented out. I reordered it, maybe this will help. Could you try it out once more? If you just comment out line 691 ("delete ec_old;"), does it still crash? Regards, Markus

3 3

2 questions: Walk through all nodes and the two "different trees" SPObject/agnostic XML
by Christoffer Holmstedt 02 Aug '13

02 Aug '13

I'm trying to walk through a complete document and get all nodes of a specific type, in this case <metadata> to populate the new metadata GUI. My best bet now is to get the current active SPDocument and start to iterate from the root node, depth-first. I've found the sp_repr_lookup_name in "src/xml/repr.h" which do exactly that but stops at the first hit so I would have to wrap it somehow and run it multiple times. If I've understood this correctly it will work on the agnostic XML backbone and not with SPObjects which I should be using but then again RDF implementation doesn't use SPObject in its current state. Am I on the right track or totally lost? (within repr-util.cpp it seems like you can iterate through a XML::Node's all children with the help of firstChild() and next(), perhaps better than using the c facade function, but will it work with RDF nodes?) So to my second part, somewhat related, In sp-object.h a comment says "[...] SPObject layer is bound to the SPRepr layer, closely following the SPRepr mutations via callbacks." We have the typed object layer with SPObjects and the agnostic XML layer with SPRepr. The confusion for me now is concerning variable naming, I think, throughout Inkscape codebase both "repr" and "node" are used as variable names for XML::Node objects. Is SPRepr the old "name" for XML::Node? If yes, this would mean that everything below Inkscape::XML do work on the the agnostic XML backbone layer and not the SPObjects, have I understood this correctly? Regards -- Christoffer Holmstedt

2 2