- Inkscape Devel - Inkscape Mailman

Casting-macro replacement
by Markus Engel 05 Mar '14

05 Mar '14

Hi there, in r13061 I added two template functions in order to replace the tools' casting macros. You can see them in action in widgets/pencil-toolbar.cpp:110. I also added some compile-time checking there which can be uncommented later. As I just stumbled across this. In order to build clang from its svn source, you need a c++11-enabled compiler: "This is expected to be the last release of LLVM which compiles using a C++98 toolchain. We expect to start using some C++11 features in LLVM and other sub-projects starting after this release. That said, we are committed to supporting a reasonable set of modern C++ toolchains as the host compiler on all of the platforms. This will at least include Visual Studio 2012 on Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of compilers (and the C++11 features they support) is not set in stone, but we wanted users of LLVM to have a heads up that the next release will involve a substantial change in the host toolchain requirements." Should I proceed replacing the casting-macros like this? Any suggestions? Regards, Markus

5 13

Inkscape news as a feed
by Jared Meidal 05 Mar '14

05 Mar '14

Hi Martin, Can we add a generation of the News items from the website into RSS? I feel think would be helpful to allow users to follow us at another level. I've seen documentation for this here, but not sure if this is already something built into the django site already up. https://docs.djangoproject.com/en/1.6/ref/contrib/syndication/ Thanks, --Jared

4 7

Fwd: Re: Careful with C-strings!
by mathog 05 Mar '14

05 Mar '14

On 03-Mar-2014 13:47, Martin Owens wrote: > I'm going to rip out c-strings from uri handling. It's dangerous code > and needs to be dealt with. A c string is only "dangerous" if the programmer mistakenly thinks it works the same as std::string. Conversely, all changes to working code are dangerous since a modification introduces the risk of creating a bug and breaking the program. For the URIs it doesn't matter much what the internal storage method is, so go ahead and change that - in your branch. For bitmap images the underlying libraries, like libPNG, are not going to play nicely with std::string, and it seems a little silly to waste time and memory converting back and forth all the time, since either way in the end Inkscape just carries around a big block of memory. Similarly, a lot of glib uses gchar * (or guchar *) arguments, and some of those functions return values in those formats. It is far from clear to me that requiring everything that talks to glib to convert to/from std::string will reduce the number of bugs in Inkscape. Regards, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

2 1

Windows: default enable console output window?
by Johan Engelen 04 Mar '14

04 Mar '14

Hi all, Is it OK if I enable the extra console output window per default on Windows? (i.e. build with "-mconsole" instead of "-mwindows") We should disable it in finale releases, but I think in trunk it should be enabled so people can always see the messages that trunk generates. Thoughts? -Johan

4 4

Re: [Inkscape-devel] Inkscape joins the Open Invention
by Jared Meidal 04 Mar '14

04 Mar '14

I have that content copied and published on the main site now. I'll stand by for any adjustments needed. --Jared > -----Original Message----- > From: Bryce Harrington [mailto:bryce@...961...] > Sent: Sunday, March 2, 2014 10:32 PM > To: Martin Owens > Cc: Jared Meidal > Subject: Re: [Inkscape-devel] Inkscape joins the Open Invention > > On Sun, Mar 02, 2014 at 09:29:49PM -0500, Martin Owens wrote: > > On Sun, 2014-03-02 at 15:44 -0800, Bryce Harrington wrote: > > > Thanks, currently I get a error page at that url. "Could not import > > > inkscape.person.views.register. View does not exist in module > > > inkscape.person.views." > > > > That's my fault. Sorry for the downtime. > > No prob, it's why we have a staging site right? :-) > > So, the GSoC section looks great. I think we might be able to say more in fewer > words... let me have a try at copyediting it down: > > """ > This is Inkscape's 10th year mentoring in Google's Summer of Code. > Students, please see our <Summer of Code wiki page>[1] for directions. > Find an <idea>[2] that interests you, and <let us know>[3]! > """ > > 1: http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code > 2: > http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code#Suggested_Ide > as > 3: http://wiki.inkscape.org/wiki/index.php/SOC_Application_Template > > Bryce

2 1

Swatch dialog has a serious bug
by Johan Engelen 03 Mar '14

03 Mar '14

Hi all, I just discovered a very serious bug in the swatches dialog (/src/ui/dialog/swatches.cpp). Using a vector of DocTrack*, it tracks all current documents, and using a timer callback updates itself. The problem is, no DocTrack* is ever removed from that list. A DocTrack* (that points to an SPDocument) is added whenever you open a new document. Then when closing a 2nd document, the DocTrack* should be removed from the list and ~DocTrack should be called. Because this is _not_ happen, the timerfunction will use an already deleted SPDoc and will eventually crash in SPDocument::getResourceList (priv is set to nullptr for deleted SPDoc). I added proper ref-counting of the SPDoc object in DocTrack's constructor and destructor, but still the SPDoc is deleted and the crash occurs. Some code in swatches.cpp looks unfinished, creating data structures that are never used... Thanks for any help in tracking down and fixing the issue, Johan

2 7

python extension preview information
by TimeWaster 02 Mar '14

02 Mar '14

hi, for "my" plotter extension i would like to implement a preview functionality. right now i can't do that because the preview would overwrite the document permanently once one hit the apply button. it would really help if there was a way to know if the call to the extension was made for the preview (preview checkbox) or the final rendering (apply button), or if the above is not possible, if there was an .inx tag attribute preventing inkscape from using the extensions ouput as the final document while still maintaining preview functionality. maybe it makes sense to implement both. i could imagine multiple solutions for that: - add a parameter to the extension call identifying the preview state - add an preview state attribute to the document's internal structure (the svg tag perhaps) - add an attribute to the effect tag in the .inx file format: <effect needs-live-preview="true" needs-document="true" discard-final-result="true"> i think it would be a beneficial feature for other extensions as well. i could imagine that an extension could do a rough rendering for preview while still providing the fine rendering for the finished result, this could greatly improve speed and handling on some extensions. since i am no C programmer i can not do it, but if someone could implement such a feature my eternal gratitude for him/her would be certain. with kind regards, TimeWaster

1 0

SVG feature angled CAP
by Jabiertxo Arraiza Cenoz 02 Mar '14

02 Mar '14

Hi to all. Is or could be in the roadmap of SVG this feature: "angled CAP" for svg:path. Could be very useful at design. I made a svg to explain well.

1 2

0.48.5
by Josh Andler 01 Mar '14

01 Mar '14

Hey All, Since we're obviously not going to be getting 0.91 in Ubuntu 14.04, it seems reasonable that we should try to get 0.48.5 in it instead. Are there any pending items people have for backporting? Cheers, Josh

2 1

Why is the position of this line of code so touchy?
by mathog 28 Feb '14

28 Feb '14

In the files in src/display there are many instances of this Inkscape::DrawingContext::Save save(dc); First thing, I don't understand the syntax. What does the lower case "save" in that line indicate? The only places "::Save save(" appear in the source code are instances of this line. Secondly, it acts strangely. Moving it around breaks graphics for some reason that escapes me. For instance this: Inkscape::DrawingContext::Save save(dc); //PROBLEM LINE dc.transform(aff); double thickness = decorateItem(dc, aff, phase_length); dc.setLineWidth(thickness); dc.strokePreserve(); dc.newPath(); results in mangled graphics (text decoration drawn as if with a very thick line, but in what appears to be the correct location), whereas moving the first two lines above into double DrawingText::decorateItem(DrawingContext &dc, Geom::Affine const &aff, double phase_length) as the first two lines of that method results in normal graphics (text decoration drawn with the expected line thickness). That is: line1 line2 call is broken but call (inside called function) line1 line2 works. Moving "dc.setlinewidth()" from the position shown above into decorateItem() as the line before its return does not make any difference in either of these cases. decorateItem() just defines a cairo path with moveto/lineto on _ct in dc, it doesn't touch anything else in the dc. Using the debugger and stepping through showed that execution of the problem line passes through this: DrawingContext::Save::Save(DrawingContext &dc) : _dc(&dc) { _dc->save(); } in drawing-context.cpp. _dc->save() just does cairo_save(_ct); I have never seen anything quite like this when using cairo directly, that is, calling cairo_save() and cairo_restore() has never resulted in mysteriousness of this level. And that seems to be mostly what the DrawingContext does - it keeps track of (private) cairo_t *_ct; I would have thought that passing dc by reference should have made the position of the problem line before the call, or just within the called function, a moot point, but apparently not. This is so even though when the address of _ct was checked with dc.raw(), before and after the problem line, it didn't change. Whether or not the problem line was before or inside decorateItem(). Can somebody please explain what is happening here? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

4 5