- Inkscape Devel - Inkscape Mailman

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

GObject removal branch
by Krzysztof Kosiński 02 Aug '13

02 Aug '13

2013/7/31 Markus Engel <p637777@...1081...>: >> However, using it would require you to rewrite the init functions of all > SPObjects. > ... >> Replacing GObject-style initialization with constructor / destructor > shims in the style of NRObject would considerably simplify removing > the GObject dependency later and reduce the burden of maintaining the > init / dispose functions. > > Well, please don't do that, I'm already done removing the GObject > dependency, take a look at my branch at > https://code.launchpad.net/~engelmarkus/inkscape/cppify . Some review comments about this branch 1. The code seems wrong in a several places. For example, the constructor of SPObject retains the manual constructor calls and its destructor retains the manual destructor calls. Member initialization is already done before the constructor is even entered, and member destruction happens automatically after the destructor returns. I'm fairly sure this will lead to problems at runtime. 2. A lot of the constructor code should be changed to member initializers. See e.g. the constructor of SPItem. 3. Class names such as CSomething are reminiscent of MFC. The prefixes should be removed and the classes put in namespace Inkscape::SVG (since they represent objects in the SVG). 4. "#pragma once" is not used in existing Inkscape code. For consistency you should use standard include guards. 5. singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason. 6. Method and variable names are not consistent with our coding style, though this could be addressed later since it's a leftover of previous GObject code. http://staging.inkscape.org/en/develop/coding-style/ http://inkscape.org/doc/coding_style.php (old website) 7. The virtual methods should be made protected, since they are not intended for use outside of SP node implementations. Since the initialization rework I proposed would address points 1 and 2, it seems that this part of the work is actually not done. What do others think? Should we work from Markus' code or rewrite the initialization first? Should we release 0.49 before introducing this kind of changes? Regards, Krzysztof

5 13

[Recolor] Week #3: Moving onto Further Tasks
by Arshdeep Singh 02 Aug '13

02 Aug '13

Hello all, Because I'd been stuck on the second goal for so long, I decided to get on to write the GUI subsytem, which was actually my third and final task for the midterm evaluation. I have written the paint_recolor_nodes( ) function successfully. Here is a screenshot: [image: Inline image 1] The black outlined, white colored (with color inside) are the intended nodes that will function in the final render. Now I'll move onto writing the events that trigger repainting and node dragging. I cannot work on these events making actual changes till the brick-wall issues are resolved. My mentor has promised he'll look into it by this weekend. :) Till then those tasks are deferred. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

2 5

Coding workflow and reading practices
by Jon Cruz 02 Aug '13

02 Aug '13

Hi Johan, In the thread on GObject instantiation you happened to raise an interesting issue that probably warrants some good discussion. You had mentioned that adding more to the headers "Saves some time wading through lengthy .cpp files only to find an almost empty function". Do you think you can expand a little on your use case where this type of practice is an issue? That is, can you give a quick description of some of the steps you would be going through when this problem pops up? I know that different people have different learning and processing styles. (As an extreme example I've even worked with someone whose workflow was impacted by a change in Emacs that limited the number of open windows to only a couple hundred.) It would be good to be sure that we try to get things structured well for easier maintenance, etc. Thanks.

1 0