- Inkscape Devel - Inkscape Mailman

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

cannot link rev 13646, Windows XP
by alvinpenner 03 Nov '14

03 Nov '14

attempting to compile rev 13646, devlibs rev 52, I get the following link error: --- link / rc --- link / link ============ cmd ============ mingw32-g++ -o build/inkscape.exe -mwindows -mthreads build\obj\2geom\affine.o b uild\obj\2geom\basic-intersection.o build\obj\2geom\bezier-clipping.o build\obj\ 2geom\bezier-curve.o build\obj\2geom\bezier-utils.o build\obj\2geom\circle-circl e.o build\obj\2geom\circle.o build\obj\2geom\conic_section_clipper_impl.o build\ obj\2geom\conicsec.o build\obj\2geom\conjugate_gradient.o build\obj\2geom\convex -cover.o build\obj\2geom\crossing.o build\obj\2geom\curve.o build\obj\2geom\d2-s basis.o build\obj\2geom\ellipse.o build\obj\2geom\elliptical-arc.o build\obj\2ge ... snip ... 9 -Lc:\devlibs/lib -lwpd-stream-0.9 -Lc:\devlibs/lib -lwpg-0.2 -Lc:\devlibs/lib -llcms2 -liconv -Lc:\devlibs/lib -lMagick++ -Lc:\devlibs/lib -lMagickCore -Lc:\d evlibs/lib -lfontconfig -Lc:\devlibs/lib -lfreetype -Lc:\devlibs/lib -llcms2 -Lc :\devlibs/lib -lgsl -lgslcblas -lm -lpng -ljpeg -ltiff -lexif -lpopt -lz -lgc -l ws2_32 -lintl -lgdi32 -lcomdlg32 -lm -lgomp -lpthreadGC2 -laspell -lmscms ============================= Make error line 447: LINK problem: mingw32-g++: error: CreateProcess: No such file or directory Cheers, Alvin -- View this message in context: http://inkscape.13.x6.nabble.com/cannot-link-rev-13646-Windows-XP-tp4971975… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 9

Assertion/Parser Error
by Partha Bagchi 02 Nov '14

02 Nov '14

I am getting the following error(s?): Entity: line 22: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xED 0x6C 0x69 0x61 <filetypetooltip>A família de formatos de imagem PNM/PBM/PGM/PPM</filetypetoolti ^ ** (inkscape.exe:67052): CRITICAL **: Inkscape::Extension::Extension* Inkscape::Extension::build_from_mem(const gchar*, Inkscape::Extension::Implementation::Implementation*): assertion 'doc != NULL' failed Entity: line 22: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xED 0x6C 0x69 0x61 <filetypetooltip>A família de formatos de imagem PNM/PBM/PGM/PPM</filetypetoolti ^ Does anyone know what line 22 is and how do I fix it? Built today from revision-13657 Windows 8.1 64bit. Thanks, Partha

2 4

Saving dialog position: is it broken?
by Michael Grosberg 02 Nov '14

02 Nov '14

Hi, I'm trying to get Inkscape to have the "prefect" work layout for me, and that includes having all of my work-relevant dialogs docked at the same time and available without having to scroll down and up a list of dialogs. So, I arrived at the following layout: https://drive.google.com/file/d/0B1HG067cLWGDRFBjRE03bkN4M00/view?usp=shari… but I just can't get Inkscape to make it stick. Even if I lock all dialogs, They just can't stay in the same place between sessions. They get arranged one under the other in a long list or in three columns after I quit and restart again. I also tried placing the left column in its own window, while still docking the two dialogs one below the other. That produced the result of having the dialogs appear floating and in seemingly random locations the next time I ran Inkscape. The only thing that worked is to get two dialogs docked one below the other and have everything else as floating dialogs outside the window. But I would really like to have a maximized window with all the dialogs visible at once. So my question is, am I missing something or is this a bug? Also, if this IS a bug, is there a workaround, like locking some settings file from being re-written? I'm on Windows 7 64-bit, running a recent dev build.

1 0