- Inkscape Devel - Inkscape Mailman

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

Rcord to gif
by Jabiertxo Arraiza Cenoz 01 Nov '14

01 Nov '14

Hi to all. For all linux users here are a sreen recorder script to save directly as gif im using on the wiki. It require the byzanz package instaled. once instaled use as: ./recordToGif.sh "40 Desktop/myGift.gif" 40 are the seconds to save. (you can give more and stop the script when you want.) Is a modified script taked from here: http://askubuntu.com/questions/107726/how-to-create-animated-gif-images-of-… Best regards, Jabier.

1 1

Release date of Inscape 0.91
by "Christoph Schäfer" 30 Oct '14

30 Oct '14

Hi Inkscape developers, As some of you may know, I'm a contributor to an influential German-language publishing magazines. It's in this capacity that I ask if there's a chance of a 0.91 release before 10 November, as this is the deadline I'd have to meet for an article on 0.91. The editor has reserved some space (1.5 pages) for text and images, and I may be able to convince him of a delay (i.e., 17 November). If even 17 November is unrealistic, please let me know. The article on 0.91 will then be published in the January issue of the magazine, but it'd help the editors and myself if we knew about the time frame. Please feel free to answer me off-list, if necessary. Christoph

5 6

Re: [Inkscape-devel] Feature Freeze for 0.91
by Jon A. Cruz 30 Oct '14

30 Oct '14

Sounds like we should do a quick round of new discussion on this. Not necessarily to reach a different conclusion, but rather to refresh the details for capturing in a Web/wiki page. I'll run through the past discussions on my archive and then start a new thread with a summary. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Johan Engelen <jbc.engelen@...2592...> Date:10/30/2014 10:36 (GMT-08:00) To: inkscape-devel(a)lists.sourceforge.net Cc: Subject: Re: [Inkscape-devel] Feature Freeze for 0.91 On 30-10-2014 18:30, Johan Engelen wrote: > I do not have a preference, as I am pretty much unfamiliar with either. > But I do think that Google Test is more widely used, and so more people > are familiar with it? Perhaps my searches have been biased. An important > feature for me is how well it integrates into Jenkins; a clear test > report on a website will greatly contribute to its usefulness I think. lib2geom uses Google Test, btw.

1 0