- Inkscape Devel - Inkscape Mailman

Inkscape is SVG
by Martin Owens 04 Jan '18

04 Jan '18

Hello Inkscape-makers, I found this ammusing, while searching for "CM350 brother inkscape" in google, google sometimes searches for synonymous terms. In this search is adds 'SVG' as a synonym for Inkscape. So google things Inkscape IS the same thing as SVG. That's a super cool position to be in, in an odd kind of way. Because it says that googles black box thinks that the pinnacle of SVG, the exemplar, the practical reference for the standard IS Inkscape. OK, back to work. :-) hope everyone had a good new year. Best Regards, Martin Owens

1 0

Inkscape Board Meeting
by Bryce Harrington 03 Jan '18

03 Jan '18

Our monthly board meeting is scheduled for next Friday, Jan 5th, 10am Pacific time in #inkscape-devel. All members are welcome. http://wiki.inkscape.org/wiki/index.php/Board_Meetings Agenda: + Madras Printer's and Lithographers' Association + Boston Hackfest (March) + Merchandise sales + Board election process review [tedg] + DigitalOcean Infrastructure hosting [bryce] + Preliminary preparations for 0.93 [tav] + Other Business Bryce

4 3

Vectors team meeting this Sat?
by brynn 02 Jan '18

02 Jan '18

Hi Friends, Lazur recently posted a calendar showing meeting dates for the board and also for the Vectors team. It shows a Vectors meeting for this Saturday. But is there actually going to be a Vectors team meeting this Sat? All best, brynn

2 1

Survey: Default beabiour on clones with path operations
by Jabier Arraiza 02 Jan '18

02 Jan '18

Hi all: I just commit a branch [1] that convert shapes and optinaly clones to paths previously any of this path operations: Booleans, Stroke to paths, Object to paths, Combine and Break Apart. The cuestion is simple: ¿Whats is your prefered option about symbols? This is done in preference section and can be change by the user, but we are speaking about the default behabiour. A: Convert to path clones and apply the operation B: Retain clones in this operatios ignoring the operation Thank for take time to reply. [1] https://gitlab.com/inkscape/inkscape/merge_requests/159

8 18

Trunk PPA working - Merry Christmas!
by Alex Valavanis 25 Dec '17

25 Dec '17

Hi All, Hope everyone's having a nice holiday. I've fixed the Trunk PPA uploads. The issue was that since we moved to git, there is no longer a universal sequence number for the commits... in other words, every time we merge a branch, the auto-numbering got screwed up. The solution (albeit a bit ugly) was to move to time-stamps in the version string, as recommended by the Launchpad documentation [1], rather than using a commit log number. The version strings for the built package now take the form: 1:0.92.0+devel+{time} This expands to something like: inkscape-trunk_1:0.92.0+devel+201712242340~ubuntu17.04.1 So it's a bit messy, but it's still a unique sequential ID. Best wishes, AV [1] https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_a…

1 0

holiday graphics for website?
by brynn 22 Dec '17

22 Dec '17

Hi Friends, I'm thinking about starting a tradition of making holiday graphics for the website. Like for example, today I spiffed up the logo for Inkscape Community with some lights (not twinkling, but maybe next year ;-p ). https://forum.inkscapecommunity.com/index.php I'm thinking of just something small and simple like that. Holly and berries, or something. We couldn't do exactly the same thing on the website, because the logo doesn't work the same way as IC. (plus it's pretty small) But there must be some ways to easily slip in some extra graphics into the website? Like maybe in the menu/navigation bar? (could they be red and green? or look like snow is piled on them?) Or the white space between the logo on the top-left and the search field on the right? I saw that cute Inkscape logo with a santa hat in the gallery (https://inkscape.org/en/~jiawhein/%E2%98%85inkscape-logo-christmas), and that's what got me started. But unfortunately, it has a solid white background, which I don't think could be used for the site. I requested either SVG or a transparent PNG, but no answer yet. I made some sort of straight lines of lights, one of which might fit in the white space at the top. But alone, they're hardly creative. Anyway, if someone could explain what those ways might be, where we could sneak in some cute graphics around holidays, I'll take the responsibility to put out a call for such graphics before each major holiday.....or maybe just 4 seasons? Or maybe holidays plus 4 seasons? (I still want to see more graphics on the site, in general. But that's a much bigger project which I can't take a leadership role right now. Well, not unless someone else wants to co-leader it?) Thanks for comments :-) All best, brynn

3 4

GDL broken under Wayland
by Tavmjong Bah 21 Dec '17

21 Dec '17

Hi, It appears that GDL (Gnome Docking Library) is broken under Wayland. >From what I've figured out, the problem is that Wayland doesn't have the concept of global windowing position which means that GDL doesn't know how to do drag-n-drop.[1] The blue "pseudo" window used to indicate where the window is while dragging does not change position. GDL doesn't seem to be under active development so I can't see this being fixed upstream soon. (There were a handful of commits last year, mostly for translation updates.) The code and our interface to it are rather complicated and it would probably take someone a considerable amount of time to fix it. It might be time to rethink how we handle docked and floating dialogs. Any ideas? Tav [1] https://blog.gtk.org/2016/07/15/future-of-relative-window-positioni ng/

2 1

Re: [Inkscape-devel] Embroidery extension
by Lex 18 Dec '17

18 Dec '17

Ah, I see. My machine (a Brother SE400) can't cut the thread and continue stitching. It's a pretty difficult limitation to work with. I try to avoid jumps whenever possible, and when I have to, I place jumps such that they're easy to trim by hand. On August 28, 2017 1:45:33 PM Michael Soegtrop <MSoegtrop@...3339...> wrote: > Dear Lex, > > yes, in case there is a large distance, the TSP solver makes a jump. My > machine can actually do jumps (knot the threads and cut them at both > ends), so my main goal is to optimize the number of jumps. > > What one should do is try to order the groups such that connections can > be hidden below other stitching, but this is complicated, especially > when you don't have the concept of an area (my stuff just works on open > paths). > > Best regards, > > Michael > > On 25.08.2017 21:05, Lex Neva wrote: >> Hi! Sorry for going dark there -- everyday life intrudes fairly often. >> >> Neato, and thanks for the explanation! It does indeed look like your >> stuff follows a similar method to inkscape-embroidery. A few minor >> differences: >> >> * The extension handles creating a "grating" of lines automatically and >> intersects them with the fill region using Shapely (a Python extension). >> >> * The fill pattern is handled automatically through the insertion of >> extra nodes as you mentioned. Currently there's only one pattern: a >> sort of stair-step/staggered pattern that is visually pleasing. I >> cribbed it off of a pattern I bought online that was made using a >> commercial embroidery design program. I'd love to understand how to >> code more complex patterns, but I haven't given much thought to it yet. >> >> * The extension used to have a TSP solver of its own, but it really >> didn't do a particularly good job. I started off trying to fix bugs and >> ultimately just ripped it out. Instead, I carefully order paths in >> Inkscape. The new Objects panel is key for this, and it's a hugely >> awesome addition to Inkscape! The only part I struggle with is that >> Inkscape doesn't want to let you reorder objects relative to each other >> if they don't intersect (or nearly intersect). >> >> Ultimately, the problem I brought up for discussion boils down to the >> same problem you're solving with the your TSP algorithm. *Question: >> *what does your code do if it needs to get from one section to another >> that is distant? Does it just jump-stitch? >> >> Here's a brief description of how to use EmbroiderModder2's >> libembroidery to convert between formats: >> https://github.com/lexelby/inkscape-embroidery#optional-conversion-program >> >> I'd suggest that your code simply output a CSV in the format >> libembroidery understands, and then you can make use of its knowledge of >> pretty much every manufacturer format to convert it to a format >> compatible with your machine. >> >> --Lex >> >> On 7/30/2017 11:47 AM, Michael Soegtrop wrote: >>> Dear Lex, >>> >>> I guess we are trying to solve the same problem, but differently. I >>> wanted to have more control than semi automated fillers provide, so I >>> added 3 LPEs, which are in Inkscape 0.92.2: >>> >>> 1.) A bool LPE to do intersections / unions, ... of areas, so that one >>> can construct the areas to stitch from drawing areas. >>> >>> 2.) A path / path group trimmer LPE, which restricts a set of paths to >>> an area (or oustide of an area. There are already two path interpolation >>> LPEs which allow to create sets of paths with fine control over local >>> direction and density. >>> >>> 3.) An LPE to convert a set of paths into stitches. This includes an >>> almost reasonable traveling salesman problem (TSP) variant solver for >>> ordering groups of stitches to minimize the traveling in between. It can >>> still be improved. It is a bit more complicated than standard TSP >>> solvers, because it looks into groups of parallel stitches which have 4 >>> possible ends. >>> >>> >>> My approach is as follows >>> >>> 1.) Make a drawing >>> >>> 2.) Use the bool op LPE to create (in a new layer) the areas to fill >>> with each color / stitch style. >>> >>> 3.) Create a set of path to control density and direction using path >>> interpolation LPEs. This allows a great deal of control, e.g. for hair. >>> I don't think any commercial tool allows this amount of control. >>> >>> 4.) Use the path trim/cut LPE to trim the paths created in 3.) to the >>> areas created in 2.) >>> >>> 5.) Use the embroidery stitch LPE to convert the paths to stitches. >>> >>> Sometimes I use the cut / trim filter also to create intermediate nodes >>> in paths to create special stitching patterns. These nodes are not >>> visible in normal drawing, but after stitching they are visible. >>> >>> Of cause for simple cases, it would help to extend it with a more >>> automated approach, which is what you appear to be working at. >>> >>> I am very interested in the import/export library you mentioned. >>> >>> It would be great to work together on this. >>> >>> Best regards, >>> >>> Michael >>> >> > > -- > =========================================== > = Dipl. Phys. Michael Sögtrop > = Datenerfassungs- und Informationssysteme > = Steuerungs- und Automatisierungstechnik > = > = Anzinger Str. 10c > = 85586 Poing > = > = Tel.: (08121) 972433 > = Fax.: (08121) 972434 > =========================================== >

6 8

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 139, Issue 24
by Lex Neva 18 Dec '17

18 Dec '17

> That's really impressive. > I wonder if an extension is capable of setting the keyboard shortcuts ? > If it was then you could add an embroidery extension to set and unset > the shortcuts you use. > That would help to enable the workflows simple for complex domain > specific extensions like this. Neat idea, but as far as I know, there's no good way for an extension to modify keyboard shortcuts. The only method I can think of would be to kill inkscape, modify the preferences file, and restart. That seems like a terrible user experience. > > Question: - if the ice is white - how do you specify a thread change ? > The extension processes objects in their stacking order, lowest to highest. If it sees a color change from one object to the next, it automatically inserts a thread change instruction in the output file.

1 0

Spin slider widget, redux.
by Tavmjong Bah 16 Dec '17

16 Dec '17

Hi all, I've taken into account all the feedback and have developed a little test program that shows of a number of solutions to replacing the Gimp Spin Scale widget. A gzipped tar file of the source code is attached so that you can try out the solutions (should be trivial to compile on Linux if you have the Gtk3 libraries). Not all of the solutions fully work as I didn't take the time to make them... but you should be able to get a feel for them. If you run in debug mode (see README) you can interactively add CSS. I've include an example CSS file you can paste into the debug window (ignore the colors, they were just for experimenting). I've also attached PNGs of the widgets with and without the extra CSS. The five solutions, from top to bottom, are: * Custom Gtk::Range widget couple with Gtk::Spinbutton: This is my current favorite. It works quite well, methinks. Use the 'Alt' key to get into fine adjustment mode. It was rather simple to implement. Could be refined further (add styling properties, rounded corners, etc.). * Gtk::Scrollbar coupled with Gtk::Spinbutton: Works rather well, but doesn't show as well the current value. Using a narrow "slider" prevents it from covering up the text (text not implemented yet). I didn't know it before, but if one clicks on the slider and doesn't move for a second or two it enters into a fine- adjustment mode. * Gkt::ProgressBar coupled with Gtk::Spinbutton: CSS can get this looking pretty good but some extra work has to be done as the ProgressBar doesn't have an "adjustment", the class that actually handles tracking a value. The Gtk::Spinbutton actually contains a ProgressBar but while one can style it via CSS one can't directly access it and it overlaps the numerical entry part of the SpinButton (this is how the Gimp widget works). * Subclassed Gtk::Spinbutton: This is essentially a modified version of the Gimp widget but it has some major flaws as one cannot access the underlying widgets (ProgressBar, Buttons). In this example, the built in ProgressBar is disabled and new code that simulates a narrower ProgressBar has been added. I could not fine a good way to calculate how much narrower the new bar needs to be to not overlap the numerical entry part. Also, when dragging the bar it is easy to highlight the numerical text. The code to do all this is pretty messy. * Gtk::Scale coupled with Gtk::Spinbutton: CSS can make this look reasonable. Reducing the size of the circle will prevent it from covering text (text not implemented yet). Gtk::Scale also has a fine-adjustment mode accessed the same was as for a scrollbar. Tav

6 17