About knots selection
by Antonio Ospite
Hi,
I was looking into fixing
https://bugs.launchpad.net/inkscape/+bug/1707919 and, after compiling a
recent Inkscape version I noticed that the behavior of knot changed wrt.
selection and dragging compared to 0.92.x.
After some research on the mailing list I found the change mentioned
here:
https://inkscape.org/en/news/2017/07/12/what-happened-hackfest-2017/
I can see the benefit of keeping knots selected to be able to move
them with the keyboard but I still find the new behavior a little
unintuitive, at lest for shape editing:
1. The colors of the mouse-over and selected states are the same,
maybe the coloring scheme of node paths can be copied: where
mouse-over color is different from the selected and dragging colors
which are the same.
2. Previously selected knots look still selected when _another_ knot
is dragged without pressing Shift.
Steps to replicate:
1. Change size of a rect using one corner.
2. Then change the size using the opposite corner.
The firs corner looks still selected.
3. Shift-click does not really select arc knots for ellipses, or
rounding knots for rects, because this action is already used for
something else, e.g. to close the arc instead.
Would it be possible to use Ctrl-Shift-click for the current
function and leave Shift-click for the normal select behavior?
IMHO this would be more consistent.
4. Dragging with the mouse only affects the last selected knot, even
if multiple ones are selected, but this is not a big deal, the
behavior is different compared to path nodes, but both make sense
IMHO.
I'll resume working on https://bugs.launchpad.net/inkscape/+bug/1707919
after the details from above are sorted out, to avoid overlapping
problems.
Thanks,
Antonio
P.S.
When verifying 1. I also noticed that path nodes change their size when
clicked the _first_time_ but then get smaller again if the object
is unselected and re-selected; however this is unrelated to the message
above, I'll file a separate bug report for that if it can considered a
bug, what do you think?
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
4 years, 4 months
Problems building on Ubuntu 16.04
by mathog
Upgraded the Ubuntu 14.04 system which had endless build problems to
Ubuntu 16.04.
It doesn't seem to like 16.04 much better. Different problems, but
still problems.
Cleaned out the build directory and did:
cmake ..
which failed at
...
WITH_OPENMP: ON
WITH_PROFILING: OFF
WITH_YAML: OFF
------------------------------------------------------------------------
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
POPPLER_INCLUDE_DIR
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
used as include directory in directory /usr/local/src/inkscape_trunk
<SNIP many lines>
-- Configuring incomplete, errors occurred!
See also
"/usr/local/src/inkscape_trunk/build/CMakeFiles/CMakeOutput.log".
This is at revision 15617. These poppler pieces are present
ii gir1.2-poppler-0.18 0.41.0-0ubuntu1
ii libpoppler-dev:i386 0.41.0-0ubuntu1
ii libpoppler-glib-dev 0.41.0-0ubuntu1
rc libpoppler-glib4 0.12.4-0ubuntu5.2
ii libpoppler-glib8:i386 0.41.0-0ubuntu1
rc libpoppler19:i386 0.18.4-1ubuntu3.1
rc libpoppler44:i386 0.24.5-2ubuntu4.4
rc libpoppler5 0.12.4-0ubuntu5.2
ii libpoppler58:i386 0.41.0-0ubuntu1
ii poppler-utils 0.41.0-0ubuntu1
What needs to be tweaked to make this work?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
4 years, 11 months
slow, sluggish drawing with pencil & calligraphy tool solved
by Yale Zhang
Hi, I've identified why drawing is lagging with GTK+3.
https://bugs.launchpad.net/inkscape/+bug/1723247
It's because of GTK3's motion event compression:
https://bugzilla.gnome.org/show_bug.cgi?id=702392
Adding a * gdk_window_set_event_compression (window, FALSE);* in
SPCanvas::handle_realize() makes things much smoother.
At 1st I thought it was because the events were sitting in the queue for
too long. So I added some timing code to measure the latency between when a
motion event was generated in GDK to when SPCanvas::paint() is called.
Actually, I detect bursts of mouse moves or redraws and only use the 1st
for latency measurements since there might not be a 1 to 1 relation between
motion events and redraws. I was seeing a 4 to 10ms latency for head (GTK3)
but only 0.5 ms for 0.92 (GTK2).
I thought I was on to something, but this mislead me for a while. Finally,
I saw that the # motion events and redraws were 10x higher for GTK2.
I haven't stayed up to date with the GitLab migration. I tried to push a
patch to my branch simdgenius_inkscape, migrated from Bazaar, but access is
denied. I just requested project access, so appreciate it if someone grants
it.
-Yale
4 years, 11 months
Releasing Inkscape onto the Website
by Martin Owens
Dear developers,
The website supports developers submitting releases using the releases
app, we haven't linked to the releases app publically, but thanks to
Maren and others it's a mostly complete history of Inkscape package
files.
To upload an inkscape package:
a) Go to the website and login
b) Click the "Upload Art or Resource" (or click Submit in any of your
galleries to better organise your files)
c) Fill in all the fields you want, make sure to include the uploaded
file and gpg signature.
d) Select "Inkscape Package" in the category drop down.
e) Save.
f) Now re-edit the new upload.
This will give you the two new fields of "Release" and "Platform",
these ONLY appear if: The upload is in the Inkscape Package category
AND you have permission to edit releases. If you don't see these
fields, make sure you join the releases team at https://inkscape.org/en
/*release-team and try again.
You can only have ONE resource per release, per platform. So the
Inkscape 0.92.2pre0 release can have ONE Win32 MSI Package, ONE Mac OSX
10.9 DMG, etc etc. If you try to over-write, it will deny you setting
the platform and release fields.
We're going to try and keep the permissions to one person for each of
the main platforms. So bryce can do source uploads, tgh can do Mac
uploads etc etc. We make have some backups, but user wise it shouldn't
need every developer to be a release team member.
Let me know if you have issues.
Best Regards, Martin Owens
Your Friendly Website Admin
5 years
Inkscape Board Meeting
by Bryce Harrington
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
5 years, 2 months
Survey: Default beabiour on clones with path operations
by Jabier Arraiza
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
5 years, 2 months
Trunk PPA working - Merry Christmas!
by Alex Valavanis
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...
5 years, 2 months
holiday graphics for website?
by brynn
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
5 years, 2 months
GDL broken under Wayland
by Tavmjong Bah
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/
5 years, 2 months
Re: [Inkscape-devel] Embroidery extension
by Lex
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
> ===========================================
>
5 years, 3 months
