- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2
by Ruben Van Boxem 06 Aug '14

06 Aug '14

As the previous email was sent only to one person, see below as well :-) I forgot to mention one thing: MSYS2 has a clang that can be used to compile applications. Unfortunately, GCC 4.9.1 header locations aren't yet added to the build, so currently it's not possible to use it. Note that Clang on Windows only works on 32-bit (for now, will change in the future) and with the dw2 C++ exceptions implementation. It uses and links to libgcc and GCC's libstdc++, no libc++ on Windows yet. Ruben From: rubenvb.development@...3139... To: jbc.engelen@...2592... Subject: RE: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Date: Wed, 6 Aug 2014 15:22:13 +0200 Hi guys, I'm not replying in-line because, well, the outlook.com web interface doesn't indent the previous message like gmail does. Now I have a reason to stick with gmail :-p On-topic: I understand you like the devlibs setup, but as you say yourselves, setting it up and maintaining it is a pain. My message was just meant as an FYI, for your consideration. I won't prevent you from using the binary packages built by the MSYS2 project and integrating those into your devlibs. But I'd only think it fair you credit the project for their work (I'm actually not involved in its development in any way). I think just copying the libraries from the MSYS2 packages should work. Note that C++ is a bit more ABI sensitive than C, and those packages will need a matching GCC variant. (sjlj-dw2-seh and win32-posix internal GCC threads). C code will also be affected by the internal thread implementation GCC uses. Note this does not affect your code or the generated code whatsoever. Just what GCC (libgcc) uses internally. Huh, I didn't find any 64-bit builds on the download page, if you want them to be picked up, you should place them alongside the 32-bit builds, otherwise people aren't even going to try them ;-) http://inkscape.org/en/download/windows/ or http://sourceforge.net/projects/inkscape/files/inkscape/0.48.5/ Cheers, Ruben Date: Fri, 1 Aug 2014 21:00:58 +0200 From: jbc.engelen@...2592... To: inkscape-devel(a)lists.sourceforge.net; rubenvb.development@...3139... Subject: Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Hi Ruben, On 31-7-2014 16:11, Liam White wrote: The devlibs setup is actually the most simplified way to build Inkscape, because one does not need to download and install MSYS to build it on Windows this way. I agree with Liam. Our current setup for Windows is about as simple as I can imagine (for both 32 and 64 bit). The most difficult thing is setting up Bazaar, which is unrelated to setting up the build environment. Once one can checkout Inkscape's source, the only build setup steps that are required are: bzr checkout devlibs, and downloading and unzipping mingw. There is very little room for improvement here; certainly MSYS2's installation instructions are more 'difficult'. I don't think setting up our build setup is preventing developers on Windows to join the project. That said, there is a cost of our simplicity: someone has to maintain the devlibs. With the hard work of Partha and Liam, we have managed to get devlibs64 up; without them we probably still would not have had 64bit. 64-bit builds are possible because we modified our code to get it built with 64bit! We already have official 64bit builds :) It'd be nice to have another project maintain a "devlibs", effectively what MSYS2 would provide for us, possibly at the cost of some *reduced* simplicity in setting up the build environment (based of of the installation instructions online for MSYS2). Perhaps it is as easy as just copying the binaries/headers into our devlibs though... regards, Johan (Does MSYS2 provide clang binaries that are usable for compiling Inkscape?) On Jul 31, 2014 4:00 AM, "Ruben Van Boxem" <rubenvb.development@...3139...> wrote: 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)

2 1

SVG2 hatch rendering
by Tomasz Boczkowski 05 Aug '14

05 Aug '14

Hi! I've implemented the rendering of SVG2 hatches in lp:~penginsbacon/inkscape/svg-paints-support. How it works can be seen using a test file attached to this message. The rectangles in left columns are filled with hatches, while the ones in right columns are reference images consisting of clipped paths. What is still to be done is to implement rendering when overflow property is set visible. In addition to this, I have to improve rendering when hatch covered object is zoomed out. The second problem can be seen in the picture [1]. The cause is aliasing when rendered cairo_pattern_t is applied to a shape. One of the solutions is to adjust applied pattern size to full pixels. This can be achieved by manipulating the transformation applied to the pattern by ink_cairo_pattern_set_matrix in drawing-pattern.cpp:119. The drawback of this rendering hatch paths at displaced positions, what can be visible in case of large shapes. Another solution is to allocate pattern surface of the size of object bounding box and to draw all hatch paths on it. The third one is to increase oversampling and use CAIRO_FILTER_NEAREST for hatches. What techique do you recommend? I'd like to add hatches to Swatches and Fill and Stroke dialogs and prepare stock hatches based on ISO 128-50 standard being used in Europe for technical drawing. As there are more SVG2 elements supported in Inkscape, how should fallback to SVG1.1 look like? Should there be an another output extension? In case of hatches should they be converted to patterns? Regards Tomasz

7 14

[GSOC Swatches] Latest code check in
by Tavmjong Bah 05 Aug '14

05 Aug '14

Hi Tomasz, I just looked at your latest code check-in. You've added in style.h: sigc::connection fill_ps_changed_connection; sigc::connection stroke_ps_changed_connection; to the already existing: sigc::connection filter_modified_connection; sigc::connection fill_ps_modified_connection; sigc::connection stroke_ps_modified_connection; How does "changed" differ from "modified"? This is a place where adding a comment or two would really be helpful to some future developer in understanding the code. Any progress with hatches? Tav

2 2

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

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

Re: [Inkscape-devel] Inkscape 0.48.5 Released
by Jared Meidal 20 Jul '14

20 Jul '14

Got it working now. I'm not sure if I fixed this or someone else. The news article was set to be published, but the publish time was future in my timezone. I moved it back 6hrs and the link on the homepage works for me now. (This also messed up the RSS feed until the link began to work again.) --Jared > > Message: 3 > Date: Fri, 18 Jul 2014 15:46:52 -0700 (PDT) > From: alvinpenner <penner@...1856...> > Subject: Re: [Inkscape-devel] Inkscape 0.48.5 Released > To: inkscape-devel(a)lists.sourceforge.net > Message-ID: <1405723612463-4971012.post@...2730...> > Content-Type: text/plain; charset=us-ascii > > glad to hear it! > > just writing to note that, on the site: > http://www.inkscape.org/en/news/2014/07/ > > the link that says "Inkscape 0.48.5 Released" does not work. > > Alvin

9 25

two new icons propose
by Jabiertxo Arraiza Cenoz 19 Jul '14

19 Jul '14

Hi to all. Because GTK declare obsolete "yes" and "no" icons, and "accept" and "cancel" icons are handled by his label -so you can not change his label to a custom text i think-, I propose the creation of two icons in the icon files of inkscape. I want particulary to use in the new LPE parameter "Toggle Button", now is used in experimental branch -Simplify LPE-. For this LPE I'm using "system-run" and "process-stop" GTK default icons, but i think is better a toogled button for example like bullets here[1]. http://www.inkscape.org/en/develop/next-release/ Any problem to add it? I could do it but maybe we can ask for on inkscape-user list. Regards, Jabier.

2 2

Optimization talk
by Johan Engelen 19 Jul '14

19 Jul '14

Hi all, If you are interested in optimization of C++ code (by the compiler): https://www.youtube.com/watch?v=eR34r7HOU14 regards, Johan

1 0

Inkscape 0.48.5 Released
by Josh Andler 18 Jul '14

18 Jul '14

Greetings! The Inkscape community is proud to announce the stable bug-fix release of Inkscape version 0.48.5. This is the fifth bug fix release for 0.48 and it contains over 60 bug fixes to improve stability and functionality on all platforms (over 190 for OS X since our last available package). Check out the release notes [1] for a summary of some of the fixes and improvements, the milestone page [2] for the full list of closed bug reports, or just jump right to downloading [3] your package for Windows, Linux or Mac OS X. We will be focusing our efforts on 0.91 and are not currently planning any further bug-fix releases in the 0.48 series at this time. Stay tuned for more news! Cheers, Josh [1] http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48.5 [2] https://launchpad.net/inkscape/+milestone/0.48.5 [3] http://inkscape.org/download/

2 1

Compiling 0.91 branch for RHEL 6
by Shamit Verma 17 Jul '14

17 Jul '14

Hi All, I am trying to build Inkscape for an environment where only RedHat 6 distribution of Linux is available. Has anyone tried to build .91 codebase on this distribution? What would be the dependencies that I would need to build this codebase ? Regards, Shamit

2 1

0.48.5 packages needed
by Krzysztof Kosiński 16 Jul '14

16 Jul '14

The Windows installer is up at sourceforge.net, and the tarballs are at Launchpad. We still need the portable version and the Mac bundle before we can announce the new release. Anyone up for it? Regards, Krzysztof

6 8

Re: [Inkscape-devel] 0.48.5 packages needed
by Jared Meidal 15 Jul '14

15 Jul '14

Josh, I tested the OS X package on two Mavericks systems yesterday and they seemed to work great. I tried it on a Snow Leopard system today with a good install. Thanks! Initially the load time for the newly installed version seems to take 2-3 minutes, but subsequent loads are under a minute. --Jared

1 0

New extension: Multi-page PDF export
by unknown＠example.com 15 Jul '14

15 Jul '14

Hi, I've written an extension to save the layers of an SVG file to a multi-page PDF. You can find it at https://github.com/wvengen/inkscape-addons Would someone be willing to either give me a wiki account, or update the extension repository page? http://wiki.inkscape.org/wiki/index.php/Extension_repository Cheers, - Willem

1 0

trunk vs. experimental: Snapping with alt-drag
by Johan Engelen 15 Jul '14

15 Jul '14

Hi Diederik, all, There is a discrepancy between experimental and trunk with regards to snapping when alt-dragging. When the grid is enabled, alt-dragging should move the selection in grid-spacing steps. But when the movement is less than one grid-spacing, there is no snapping. Diederik, can you look into this? Thanks, Johan

4 5