- Inkscape Devel - Inkscape Mailman

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

Fwd: 0.48.5 packages needed
by Liam White 14 Jul '14

14 Jul '14

Oops, forgot to add the mailing list when sending this message. ---------- Forwarded message ---------- From: Liam White <inkscapebrony@...400...> Date: Sun, Jul 13, 2014 at 9:53 PM Subject: Re: [Inkscape-devel] 0.48.5 packages needed To: Krzysztof Kosiński Here is the Windows portable version: http://goo.gl/hdrLXB I think we need to get this signed by a PortableApps person, but there's the base installer. On Fri, Jun 27, 2014 at 4:22 PM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote: > 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 >

2 1

Save a copy of the current document with all converted into curves leaving original untouched and get measures of all objects
by Nadie Nathing 11 Jul '14

11 Jul '14

Hi! I'm making an Inkscape extension that does this: 1-. Save a copy of the current document in a folder as .ai with all objects converted into curves (leaving the current document with text, spirals, polygons...) 2-. Take the measures of the bounding box that appears when I select all objects and save it to a file. 3-. Call an executable in the system path. I'm using Inkscape nightly build.

1 0

New swatches dialog and questions
by Tomasz Boczkowski 10 Jul '14

10 Jul '14

Hi! I'd like to post a video of a new swatches dialog[1]. It displays color swatches and patterns as preview tiles divided into palettes. The palettes are read from .gpl and .svg files in stock directories. One category "Current document" is special, as it shows paint servers from currently opened document. The dialog allows applying swatches to fill and stroke. It is also possible to create new swatches based on current object solid fill or stroke. New pattern can be created by invoking "object to pattern" command from add menu. How do you like it? I still have some issues to be implemented and I'd like to ask you some questions about it. 1) I would like to implement modifying existing patterns. My original idea was to create new dialog "swatch properties". Now I think using existing "object attributes" and "object properties" dialogs would be simpler and more versatile. After clicking a modify button a popup will appear [2]. Each option would show appropriate dialog. The content of the property dialogs is based on current selection, and there is no option to display the properties of arbitrary objects. I have two possibilites: * set selection to swatch element (having solidColor, gradient or pattern tag). Selection API allows it, but only visible objects are selected in inkscape so far. * modify the property dialogs to enable editing arbitrary objects by adding a setObject(SPObject *) method. Which of the options is favourable? 2) The dialog should enable removing swatches. I think placing, rather long, implementation of this feature in swatches dialog class might not be the best solution. Where else can I place the code? 3) Old swatches dialog supplies an "auto" palette. It consists of swatch objects from current document that have "obs:swatch" attribute defined. The new one displays all swatches from current document. Should I keep the the palette? Regards, Tomasz [1] https://www.dropbox.com/s/80f9r6ct9w2fktx/swatches-dialog.mpeg [2] https://www.dropbox.com/s/hn8cqvu64ke364b/modify_swatch.png

3 4

Re: [Inkscape-devel] Large filter areas
by Niko Kiirala 08 Jul '14

08 Jul '14

8.7.2014 8.52 kirjoitti Michael Grosberg <grosberg.michael@...400...>: > > Krzysztof Kosiński <tweenk.pl@...360...> writes: > > > > > We could do three things > > a) put in some logic to arbitrarily stop rendering an effect when the > > dependent area crosses some threshold > > b) use stacked box blur instead of true Gaussian blur (though I doubt > > it would be faster) > > c) speed up the existing Gaussian blur implementation - it shouldn't > > be that slow > > > > Regards, Krzysztof > > If it's OK to contribute my two cents as a user, I would prefer loss of > quality in the work area over a slowdown. If for example zooming in to a > blurred shape would make large chunky pixels visible, that is still better > than having to contend with a slow system. So if you have a way of replacing > the blurred object with a static bitmap instead of having to recalculate > the blur every time the display changes, that would be acceptable. > I'm talking about the work area display only, of course, not bitmap export. > > BTW, I've been working with Inkscape in a production environment for years > but lately I've upped my usage even more and I'm using it almost all day. > Even though I have the latest version of Illustrator installed I still vastly > prefer Inkscape - it is so much easier to work with. It's likely quite a forgotten thing, but filters as they stand, do contain a crude method along these lines. If you go into settings, you can drop the filters rendering quality, which will limit the rendering resolution when editing. You will get quite notable artifacts, but it's vastly faster in many cases. There are a couple quality settings available in the filtering code. It could be useful to look into those and see if there's some better default combination than what we have now.

1 0