- Inkscape Devel - Inkscape Mailman

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

Code cleanup in trunk
by Johan Engelen 23 Jul '14

23 Jul '14

Hi Markus, Thanks for the code cleanups in trunk. One comment: please be careful in removing nullptr checks in trunk. Although they look unnecessary, we really don't want to (re-)add bugs. In rev 13460, you removed a this == nullptr check. It's terrible code, I agree. The problem is that some other bad code may still rely on that check. I'm not saying that's the case for that particular piece of code, but I'd rather not remove such checks in trunk until after release. Small tip for people bughunting, "this" in a class method can be nullptr. A call through nullptr to non-virtual method will happily pass. Because we changed code like f(SPFoo *g) { if (!g) return; to Foo::f() { if (!this) return; you may see a check on "this" in the code. If you are sure that all callers make sure the object is not nullptr, you can remove the check in experimental. thanks, Johan

2 3

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

23 Jul '14

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. All pattern types can be chosen when no item is selected on canvas. In this case newly created items will receive selected style. Regards Tomasz [1] https://www.dropbox.com/s/5fb0r9hhdo4w2uc/solid-swatch-properties.mpeg [2] https://www.dropbox.com/s/54vi1j4ypjdv2mq/pattern-swatch-properties.mpeg [3] https://www.dropbox.com/s/z998vjvoucbirmg/gradient-support.mpeg On Fri, Jun 27, 2014 at 11:30 PM, Tomasz Boczkowski <penginsbacon@...400...> wrote: > Thank you! > > > One quick suggestion, please add Black to the options for background > > color. :) > Added. > > Tomasz > > > On Fri, Jun 27, 2014 at 9:23 PM, Martin Owens <doctormo@...400...> wrote: > >> On Fri, 2014-06-27 at 19:49 +0200, Tomasz Boczkowski wrote: >> > I've implemented the look and feel options that were planned in >> > project proposal. [1] Now there are three view modes: >> > * list, showing tiles with labels divided into categories >> > * grid, presenting only preview tiles contiguously >> > * tree, presenting preview tiles divided into categories >> >> Nice work Tomasz! >> >> Martin, >> >> >> >

2 2

Re: [Inkscape-devel] New swatches dialog and questions
by Tomasz Boczkowski 23 Jul '14

23 Jul '14

Thanks! > It would also have been nice to be able to change multiple swatches at > the same time as it might have been if last years color GSOC project had > been finished. How can this be done? Are there any mockups from last year available? > The Fill and Stroke dialog could use a rethinking. I really don't like > that clicking on the Swatch icon automatically creates a new swatch. The "swatch" tab can be moved to the color notebook and display solid color swatches. It would behave similar to the patterns tab. > We should also be displaying gradients in the swatches dialog. No problem. > Same thing with clicking on the Pattern icon. I'm afraid I didn't get the point. After clicking the pattern icon a list of patterns is displayed and no new pattern is created. > It might be interesting to think on how > the Fill and Stroke tabs could be integrated with the new Swatches > dialog. I fully agree. Especially when solid colors, gradients and patterns are equally treated as swatches. My first mockups from this project included a modified fill and stroke interface [1]. They were rejected and replaced by integration of pattern preview widget in a fill and stroke tab. At those time, the mockups didn't involve the swatches dialog. Do you think this idea is worth considering again? Tomasz [1] https://www.dropbox.com/s/l2w3ybeozmzix73/integration.png On Sun, Jul 13, 2014 at 1:45 PM, Tomasz Boczkowski <penginsbacon@...400...> wrote: > Thanks! > > > It would also have been nice to be able to change multiple swatches at > > the same time as it might have been if last years color GSOC project had > > been finished. > > How can this be done? Are there any mockups from last year available? > > > The Fill and Stroke dialog could use a rethinking. I really don't like > > that clicking on the Swatch icon automatically creates a new swatch. > > The "swatch" tab can be moved to the color notebook and display > solid color swatches. It would behave similar to the patterns tab. > > > We should also be displaying gradients in the swatches dialog. > > No problem. > > > Same thing with clicking on the Pattern icon. > > I'm afraid I didn't get the point. After clicking the pattern icon > a list of patterns is displayed and no new pattern is created. > > > It might be interesting to think on how > > the Fill and Stroke tabs could be integrated with the new Swatches > > dialog. > > I fully agree. Especially when solid colors, gradients and patterns > are equally treated as swatches. My first mockups from this project > included a modified fill and stroke interface [1]. They were rejected > and replaced by integration of pattern preview widget in a fill and stroke > tab. At those time, the mockups didn't involve the swatches dialog. > Do you think this idea is worth considering again? > > Tomasz > > [1] https://www.dropbox.com/s/l2w3ybeozmzix73/integration.png > > > On Thu, Jul 10, 2014 at 5:02 PM, Tavmjong Bah <tavmjong@...8...> wrote: > >> On Wed, 2014-07-09 at 18:57 +0200, Tomasz Boczkowski wrote: >> > There's one more issue that I would like to consult. >> > >> > >> > 4) There's a number of palettes provided with inkscape. If they are >> > all displayed in tree mode, they occupy a lot of >> > space in swatches dialog [1]. It can be quite uncomfortable to use >> > "Ubuntu" and "Current document" palettes >> > at the same time. In grid view mode, when all categories are collapsed >> > into one, the situation is even worse [2]. >> >> Yes, this is a big problem. >> >> > I can think of three solutions: >> > * Leave tree mode [1] as is and in grid mode [2] display only expanded >> > palettes. To enhance discoverability >> > it would be possible to expand and close palettes from popup menu >> > [3] >> >> I like the way the tree mode keeps the palettes separate. I prefer this >> to the grid mode. >> >> > * Use the popup menu [3] to choose palettes that are shown in swatches >> > dialog. If a category is shown it can >> > further be expanded or collapsed. >> >> There is a discoverablity issue here. >> >> > * Share a TreeModel behind swatches dialog between: patterns panel in >> > fill and stroke dialog, color chooser bar >> > at the bottom of the screen and swatches dialog. Add a dialog to >> > choose active palettes, as shown in [4]. The >> > solution is similar to GIMP behaviour. >> >> Sharing the TreeModel is a good idea, but I am not sure about the dialog >> to choose the palette. >> >> > Which of them do you like most? >> >> What about adding a fourth option "Choose Palettes" to Tree, Grid, List >> that would be like your Palettes dialog >> >> > In third case we have a data model common to a number of dialogs. How >> > can I implement creating and sharing >> > the object? What comes to my mind is making the data model a >> > singleton, or associating it with SPDesktop >> > object. Are there other possibilities? >> >> Singleton would be fine, I think. >> >> Tav >> >> >> >> > [1] https://www.dropbox.com/s/5tfjj0ih62fxl03/swatches_categories1.png >> > [2] https://www.dropbox.com/s/5675of3vfi926pt/swatches_categories2.png >> > [3] https://www.dropbox.com/s/q16h3ecqhkn1pso/swatches_categories3.png >> > [4] https://www.dropbox.com/s/v245xz3m1o82jch/palettes_dialog.png >> >> >> >

2 3