- Inkscape Devel - Inkscape Mailman

Compiling 0.91pre1
by john Culleton 04 Aug '14

04 Aug '14

I get this error: -------------------------- CXX libdepixelize/kopftracer2011.o In file included from /usr/include/glibmm-2.4/glibmm.h:89:0, from libdepixelize/kopftracer2011.cpp:29: /usr/include/glibmm-2.4/glibmm/threads.h:142:11: error: field 'gobject_' has incomplete type GThread gobject_; ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'GThread* Glib::Threads::Thread::gobj()': /usr/include/glibmm-2.4/glibmm/threads.h:138:41: error: 'gobject_' was not declared in this scope GThread* gobj() { return &gobject_; } ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'const GThread* Glib::Threads::Thread::gobj() const': /usr/include/glibmm-2.4/glibmm/threads.h:139:41: error: 'gobject_' was not declared in this scope const GThread* gobj() const { return &gobject_; } ^ make[3]: *** [libdepixelize/kopftracer2011.o] Error 1 make[3]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/inkscape-0.91pre1' make: *** [all] Error 2 ---------------------------------------- I get another kind of error on gobj_ when attempting to compile pre0. I use Slackware Linux 14.1 64 bit. Suggestions? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

2 1

Re: [Inkscape-devel] Compiling 0.91pre1
by Johan Engelen 04 Aug '14

04 Aug '14

Try swapping the order of the include files, that sometimes helps for this issue. -Johan ----- Reply message ----- From: "john Culleton" <John@...1202...> To: <inkscape-devel@...6...> Subject: [Inkscape-devel] Compiling 0.91pre1 Date: Mon, Aug 4, 2014 23:12 I get this error: -------------------------- CXX libdepixelize/kopftracer2011.o In file included from /usr/include/glibmm-2.4/glibmm.h:89:0, from libdepixelize/kopftracer2011.cpp:29: /usr/include/glibmm-2.4/glibmm/threads.h:142:11: error: field 'gobject_' has incomplete type GThread gobject_; ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'GThread* Glib::Threads::Thread::gobj()': /usr/include/glibmm-2.4/glibmm/threads.h:138:41: error: 'gobject_' was not declared in this scope GThread* gobj() { return &gobject_; } ^ /usr/include/glibmm-2.4/glibmm/threads.h: In member function 'const GThread* Glib::Threads::Thread::gobj() const': /usr/include/glibmm-2.4/glibmm/threads.h:139:41: error: 'gobject_' was not declared in this scope const GThread* gobj() const { return &gobject_; } ^ make[3]: *** [libdepixelize/kopftracer2011.o] Error 1 make[3]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/inkscape-0.91pre1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/inkscape-0.91pre1' make: *** [all] Error 2 ---------------------------------------- I get another kind of error on gobj_ when attempting to compile pre0. I use Slackware Linux 14.1 64 bit. Suggestions? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

Fix for #601336 (Pattern rotation crash)
by Liam White 04 Aug '14

04 Aug '14

Hi all, I came up with a fix for this week's bug of the week ( https://bugs.launchpad.net/inkscape/+bug/601336 ). However, I'm bringing it up here for two reasons: 1. It's a fairly large patch (and it modifies sp-item.h) 2. It introduces new, little-tested functionality I'm more concerned about the second item on the list. The fix was to introduce separate knots for stroke and fill patterns, and to make stroke pattern transformations independent of fill transformations. If anyone has time, I'd appreciate any feedback. The diff is attached. If for some reason you can't download it, I've also pastebinned it here: http://paste.debian.net/113020/ Thanks, Liam

2 2

Windows x64 and gtk3
by Liam White 02 Aug '14

02 Aug '14

Hi all, I've added a gtk3 build rule to the 64-bit Windows devlibs[0]. I'd like people to start testing out the gtk3 look on Windows. As the gtk3 for x86 developers probably figured out, the MS-Windows default theme looks awful with the new gtk3 version[1]. So I've again decided to stick with the Adwaita theme for compilation, which is much nicer[2]. I don't plan on returning to Windows anytime soon, so I would advise all who build on Windows to please fix any problems I might have overlooked in the build rule. Thanks, Liam [0]. See this <http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs64/trunk/revision…> [1]. See https://db.tt/js7hR38Y [2]. See https://db.tt/EGwiP0ft

2 1

Inkscape Windows compile instructions and MinGW-w64/MSYS2
by Ruben Van Boxem 01 Aug '14

01 Aug '14

Hi everyone, I wanted to explore the possibility of a 64-bit Windows build of Inkscape (for obvious reasons of increased memory availability), and discovered the "effort" had already been done by the great people of MSYS2 and MinGW-w64. I would strongly suggest the Windows developers look into switching to this development platform instead of the current, manually maintained "devlibs" setup. Perhaps this suggestion can be made more plausible if I attempt to explain what MSYS2 and MinGW-w64 provide. MinGW-w64 is an active project that provides Win32 headers and libraries so that GCC can be used on Windows, both 32- and 64-bit. It has replaced "ye olde" MinGW.org on numerous Linux distros (most notably Debian, Fedora, OpenSUSE, Ubuntu, and Arch). It is also the toolchain distributed alongside the Qt SDK releases. MSYS2 is an updated version of the old MSYS (it takes a newer version of Cygwin, applies the MSYS patches, and presto: a Unix shell environment for building Unix/cross-platform software on Windows). Additionally, MSYS2 provides a complete repository of binary packages, linux-distro style. What the developers did was port Arch Linux' package manager, pacman, and create a whole ecosystem around it of ready-made MinGW-w64 packages. The full list can be found here. You'll notice that the list contains a mingw-w64-inkscape package. What this means is that there is an easy way of obtaining/building/... inkscape on Windows, without the need to jump through too many hoops. I'm not saying you guys should drop everything and come hide in the shade of MSYS2, but instead evaluate the current build process on Windows, and perhaps provide a simplified way of developing Inkscape on this platform. A free bonus would be the possibility of providing a 64-bit Inkscape build, which is already possible without any 64-bit Windows patches thanks to good code by you guys ;-). Also note that cross-compilation from Linux shouldn't be much harder either, all the aforementioned distros have an extensive list of MinGW-w64 libraries at their disposal, and using CMake should make it all "just work". The current wiki's instructions look abysmally complicated compared to the simplicity made possible by the MinGW-w64/MSYS2 combo. I strongly hope you take this into consideration, as it will lead to a lower entry for developing Inkscape on windows, which in turn will lead to quicker bug-fixing (I hope ;-)). Thanks and keep up the fine work! Ruben (known as rubenvb in the MinGW-w64 mailing community)

3 2

Inkscape web services will be down tomorrow
by Ian Caldwell 28 Jul '14

28 Jul '14

FYI tomorrow from approximately 1000-1045 PDT INKSCAPE web services will be down while we upgrade to a bigger hard drive. Thanks, Ian Caldwell

1 0

Cloned gradient bug fix
by Johan Engelen 26 Jul '14

26 Jul '14

Hi all, I just committed a symptom fix to LP bug #453067. The root cause is evil to fix, and probably no-one will get to it before release. Hope it counts towards the bug score. regards, Johan

4 5

Re: [Inkscape-devel] GSOC status report - Better support for SVG paints
by Tomasz Boczkowski 24 Jul '14

24 Jul '14

> It would be nice to be able to edit the gradient as is done with > swatches... but this might be involve resurrecting a simplified version > of the late Gradient editor dialog. I like the idea. I can do it after I implement hatches. > One small problem... I had trouble switching back from "Grid" view to > the "Tree" view as there wasn't an empty place to click on until I > widened the window a bit. You can also change the mode using left arrow button at the bottom right corner. By the way I'm thinking of leaving some empty space after each palette in grid mode to keep palettes separate. It would look like this [1]. An icon could be added as first element of each palette. It would have a tooltip set to category name. [1] https://www.dropbox.com/s/0jltcbm8rqthsi9/newlines.png On Wed, Jul 23, 2014 at 4:43 PM, Tomasz Boczkowski <penginsbacon@...400...> wrote: > > It would be nice to be able to edit the gradient as is done with > > swatches... but this might be involve resurrecting a simplified version > > of the late Gradient editor dialog. > > I like the idea. I can do it after I implement hatches. > > > One small problem... I had trouble switching back from "Grid" view to > > the "Tree" view as there wasn't an empty place to click on until I > > widened the window a bit. > > You can also change the mode using left arrow button at the bottom right > corner. > > By the way I'm thinking of leaving some empty space after each palette in > grid mode > to keep palettes separate. It would look like this [1]. An icon could be > added as first element of > each palette. It would have a tooltip set to category name. > > [1] https://www.dropbox.com/s/0jltcbm8rqthsi9/newlines.png > > > On Wed, Jul 23, 2014 at 1:43 PM, Tavmjong Bah <tavmjong@...8...> wrote: > >> On Tue, 2014-07-22 at 13:19 +0200, Tomasz Boczkowski wrote: >> > New functions were added to the swatches dialog. >> > >> > >> > The most important is the ability to modify swatches. A swatch >> > properties >> > dialog was added. When a swatch in "current document" category is >> > selected, >> > "swatch properties" option is active. After clicking it a dialog >> > appears. >> > It is possible to change swatch name. Technically it is stored in >> > title child >> > element. Swatch preview is displayed at the bottom of the dialog. >> > Depending >> > on swatch type different controls can be displayed. For colors a color >> > notebook >> > widget is used to change swatch value [1]. Pattern attributes can be >> > changed >> > using attribute table widget [2]. >> > >> > >> > Gradient support has been added. Gradients having a gradient vector >> > defined >> > are displayed in swatches panel [3]. The user can apply gradient to >> > existing >> > object. It is linear by default. An exception to this is applying >> > gradient to >> > an object with existing radial one. >> >> It would be nice to be able to edit the gradient as is done with >> swatches... but this might be involve resurrecting a simplified version >> of the late Gradient editor dialog. >> >> > All pattern types can be chosen when no item is selected on canvas. In >> > this case >> > newly created items will receive selected style. >> >> This is all really nice. >> >> One small problem... I had trouble switching back from "Grid" view to >> the "Tree" view as there wasn't an empty place to click on until I >> widened the window a bit. >> >> Tav >> >> >> >> >> >

5 7

Different handling of x, y for path vs. text breaking text clipping
by mathog 24 Jul '14

24 Jul '14

Hi all, I'm trying to get clipping on text read in from EMF to work properly and r13463 (and maybe earlier) is doing something odd in that it is treating path and text coordinates differently, but ONLY when it reads the SVG "hot off the press" from the EMF read. If the exact same SVG is first emitted to a file and then read in directly, it works fine. Here is one such file(retrieve only directory): http://saf.bio.caltech.edu/pub/pickup/mangle_clip.svg that has the clipping more or less right when viewed in Firefox and when opened in Inkscape. But when the source EMF file is read directly, the coordinates of the <text> pieces are transformed and a <transform> tag is added to the <text>, the coordinates of the <path> draw are not transformed. Since both reference the same clipping path, this breaks clipping for text, because the coordinates of the clip-path must match up with those of the <text> IN the <text>, not AFTER it. If the text were not being clipped, the transform would not make a difference (but it is, so it does). The link above is the output of the following code fragment: (void) myEnhMetaFileProc(contents,length, &d); free(contents); if (d.pDesc){ free( d.pDesc ); } std::cout << std::endl << d.outsvg << std::endl; SPDocument *doc = SPDocument::createNewDocFromMem(d.outsvg.c_str(), strlen(d.outsvg.c_str()), TRUE); And things go wrong when the SVG as text in memory goes through createNewDocFromMem but not when the SVG as text in a file goes through whatever path the usual SVG file open uses. Does this issue sound familiar to anyone, and if so, what is the workaround? Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

1 1

Reviews to experimental
by Jabiertxo Arraiza Cenoz 23 Jul '14

23 Jul '14

Hi to all. Any body want to review one or both branches to merge on experimental: https://code.launchpad.net/~inkscape.dev/inkscape/lastApplied https://code.launchpad.net/~inkscape.dev/inkscape/roughen Regards, Jabier.

1 0