November 2014 - Inkscape Devel

RenderTests WRT python
by Martin Owens 13 Nov '14

13 Nov '14

Johan E, I've looked at the inkscape-rendertest branch. There is a pdiff codebase and a few other bits, but I notice no use of Pillow(was PIL) to process the images. We have access to PIL.ImageChomp to select the difference rectangles and further processing (with some good guides online) for pulling out more information if we need to. http://stackoverflow.com/questions/1927660/compare-two-images-the-python-li… If we went with pdiff instead of Chomp and CMP in python, was there a reason? Thanks for your time. Best Regards, Martin Owens

3 5

Looking for Code Inefficiences
by Natalie Sanders 11 Nov '14

11 Nov '14

Hi All! I'm new to the community and I'm looking to improve any code inefficiencies, especially inefficient data structures. Do you have any suggestions on where to start? Thanks! Best, Natalie -- Natalie Sanders University of Notre Dame Class of 2016 Computer Science Major

3 2

Good Introductory Bugs
by Kathryn Weiss 11 Nov '14

11 Nov '14

Hello, I am a relatively new programmer. I am looking to gain some coding experience and I am interested in developing Inkscape. In particular, I am looking at trying to fix bugs or improve performance related to data structures. I was wondering if anyone had advice as to specific areas that need this sort of work. Thank you for your help! Sincerely, KW

3 2

Testing related
by Josh Andler 11 Nov '14

11 Nov '14

Hey all, There has been quite a bit of discussion over the past couple months related to testing. Thanks to an inquiry from someone interested in helping us improve Inkscape, it was a reminder that we have a mailing list which used to be dedicated to the topic. https://lists.sourceforge.net/lists/listinfo/inkscape-tester In looking back in the archive, there were regular posts from automated builds of Inkscape which would provide compilation warnings and errors encountered during the build. It seems like it would be great to get the results from Coverity, automated builds, and the test framework (whatever we end up with) posted there. Any thoughts on us doing this? Cheers, Josh

2 1

Feature Freeze for 0.91
by Bryce Harrington 09 Nov '14

09 Nov '14

3. Frost. √ Experimental Branch is forked √ Mainline Branch focuses on stabilization √ Only production-ready code committed to Mainline √ Post inkscape-0.91-pre0.tar.gz √ Finalize any major changes to platform packaging √ Release Notes should be >90% filled in. √ Inkscape must pass >90% of 'make distcheck' √ Start an About Screen contest √ General Bug Hunt: 1500 points √ Post additional inkscape-0.91-pre*.tar.gz releases √ Packagers test creating pkgs of the -pre* releases 4. Feature Freeze √ Stable Branch is forked from Mainline Regular development resumes on Mainline. Avoid major refactorings on Mainline. Only bug fixes committed to Stable Branch. Bug fixes are cherrypicked from Mainline. Inkscape must pass 'make distcheck' String Freeze No further string changes allowed on Stable Branch. Finalize tutorials to be shipped with release Finalize other docs included in the release Finalize about screen Finalize Release Notes except Known Issues Translators work on translations. Recruit Release Wardens for Hard Freeze Inkscape has completed the Frost phase and is moving into Freeze. Translators, please fire up your engines! You have (at least) until Nov 18th to commit translation updates to the stable branch. ------------------------------------------------------------------------ A stable branch lp:inkscape/0.91.x has been split off of trunk. Only strict bug fixes and translations may be committed to this branch; for anything else please seek release manager approval (Josh or Bryce). # Stable branch bzr clone lp:inkscape/0.91.x inkscape-0.91-stable You will need to check this out only if you intend to check in fixes to the stable branch. IMPORTANT: Do not make changes to translatable strings in the stable branch. If it is critical that a string change be made, please get approval from the release managers first! ------------------------------------------------------------------------ The lp:inkscape branch (trunk) is now open for regular development towards the 0.92.x series. # Development branch bzr clone lp:inkscape You don't need to do anything with your current branch if you just want to keep committing to the development branch. Congrats to everyone that helped us get this far, Bryce

8 22

Merge of experimental branch
by Liam White 06 Nov '14

06 Nov '14

With Bryce's permission, I have merged the experimental branch into trunk. Trunk is now open for development. Please do not make further commits to experimental. If you do not use a separate directory for build and source: > $ bzr pull lp:inkscape … > Conflict: can't delete src/dialogs because it is not empty. Not deleting. > 1 conflicts encountered. > Now on revision 13641. > $ rm -rf src/dialogs > $ bzr revert This should fix your local copy.

9 24

About Screen
by Josh Andler 05 Nov '14

05 Nov '14

Alright... we should get this wrapped up. Here is the about with just 0.91: https://inkscape.org/en/gallery/item/1586/ Here is the about screen w/ the 0.49 strike: https://inkscape.org/en/gallery/item/1592/ Johan, you were the one mainly interested in the strike through 0.49, what are your thoughts on it? Cheers, Josh

3 5

Static analysis results
by Jon A. Cruz 05 Nov '14

05 Nov '14

Hi, I've been working with Johan and Bryce on the clang and Coverity analysis. Bryce should be getting the coverity runs more automated soon, but we'll take a little before things get published. We'll need to ensure we are sensitive to security, disclosure, etc. However I do have a few preliminary results. First goes to leveraging the clang results effectively. We'll need to pull together some wiki info on which clang issues to prioritize, and what approaches might be used for remediation of some of the reported problems. Initially we have one question on "Dead assignment" and the other dead store. The first case Johan and I looked at was one that did warrant skipping initialization... however clang reports 167 of those while Coverity lists only 8 issues that might overlap them. So this set of clang warnings appears to be a bit subjective on the clang dev's part, or perhaps just more advisory. So we should probably look at addressing those last. In the Coverity results I spotted two different big-picture issues hiding in the details. One warrants just low-level code cleanup while the other should be looked over by as many people keeping 'architecture' in mind. The simple issue is with the GTK-style casting macros such as SP_IS_USE(x) and SP_USE(x). They started out following the GTK team's approach to adding objects to C. A while back these were refactored to be C++ oriented so existing code would not have to be changed as we migrated to true classes. However, the usage is backwards (check-then-cast vs. cast-then-check) and conceptually there are some big mismatches that lead to most usages being vulnerable to null pointer dereferencing. Conceptually these are also backwards as they use run-time checks instead of compile-time checks. >From an implementation viewpoint, these macros have two major problems. First is that they cast away any const attributes and thus make the code less safe. Secondly (and far more critical) they are using C-Style casts that also make them take any random block of data and treat it as a proper C++ object. One of my test cases was to feed the macros a simple array of 5 arbitrary bytes. I expected it to accept but result in NULL, however it instead gave me a seemingly valid SPUse pointer. Not good. The good news is that in the vast majority of cases, no macros or casts are needed at all in C++ (for upcasting, etc.) and thus their use can just be removed. I'm working through an initial cleanup pass that should correct all but those where the improper loss of 'const' comes into play. This cleanup is good since these macros are responsible for 600-800 of the outstanding 1,135 Coverity defects. The second issue is a higher-level problem of design and naming. There are a few methods who's names appear to be leading to buggy use. The main example is SPShape::getCurve(). The problem is that to convey proper meaning this probably should be called something more like SPShape::generateNewCurve(). Many developers were treating it similar to std::string::c_str() and accessing it to query attributes of the resulting curve without explicitly grabbing and then freeing the curve. That is, the name implied access to an existing object instead of creation and ownership transfer of a new object. To fix this we might simply change the naming approach (e.g. avoid 'getFoo()' for anything that allocates) and the using code... or we could change getCurve() and friends to operate on an internal object that is persistent... or perhaps something else. -- Jon A. Cruz jon@...18...

3 2

Problem with "node->position()" and document units.
by Jabiertxo Arraiza Cenoz 04 Nov '14

04 Nov '14

Hi to all. I have a problem with this call to a node->position()[1], if the document unit not in "px" give wrong results in X and Y, I try to fix myself but for the moment no lukcy. If anybody know where is the problem, tell me. I fill a bug if nobody has a quick solution to this problem. Jabiertxo. [1]http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/l…

2 2

need a short name
by Jabier Arraiza 03 Nov '14

03 Nov '14

Hi to all, i want a short name to a type of fillet chamfer. Currently is called "double chamfer" but i want add a int parameter to subdivide the chamfer in more steps than one. see the attachment. I want a two word name at max, because is in a GUI button. Im thinking in: multi chamfer chamfer steped... Finaly, about this, i have another question, could I remove this button "double chamfer" and manage it in the chamfer subdivision? The only disventage i find, is you can't have a "real chamfer" -0 subdivision- and a stepper chamfer in the same path. Removing or not the "double chamfer" button, there is only one subdivision to all chamfers in the path, also a extra "no subdivision" -0- in case of retain the button. Think i explain well, but tell me if dont undertand my "english". Cheers, Jabier.

2 2