How to change visible selections in EnumParam
by Michael Soegtrop
Dear Inkscape Team,
my bool op LPE has classical bool operations suitable for closed paths
and line cutting operations suitable for one open and one closed path. I
wanted to adjust the options shown in the EnumParam depending on the
path type, but couldn't find out how. Also it would be interesting to
know if there is way to know when the path in a PathParam is set,
because at this point I need to adjust the options shown. Otherwise I
would make the decision on the main path and always require that the
operand path is closed (and give a warning if not).
Or do you think it makes more sense to have two LPEs, one classical bool
LPE which only works for closed paths and one path trimming LPE to trim
sets of open paths with a closed path. I think separating the two might
be more obvious to the user.
Best regards,
Michael
5 years, 11 months
Re: [Inkscape-devel] How to change visible selections in EnumParam
by Jabier Arraiza
hi:
On Sun, 2017-06-18 at 16:54 +0200, Michael Soegtrop wrote:
> Dear Inkscape Team,
>
> my bool op LPE has classical bool operations suitable for closed
> paths
> and line cutting operations suitable for one open and one closed
> path. I
> wanted to adjust the options shown in the EnumParam depending on the
> path type, but couldn't find out how. Also it would be interesting to
> know if there is way to know when the path in a PathParam is set,
> because at this point I need to adjust the options shown. Otherwise I
> would make the decision on the main path and always require that the
> operand path is closed (and give a warning if not).
You need a header var "Geom:Pathvector older_pv" asigning it in the end
of "do_before effect" and finaly compare it with current path
You also need the definition of the header put the select widget to be
available in all LPE, for this you redefine the "effect::widget" like
in a lot of effects, perspective envelope, Laticce 2....
> Or do you think it makes more sense to have two LPEs, one classical
> bool
> LPE which only works for closed paths and one path trimming LPE to
> trim
> sets of open paths with a closed path. I think separating the two
> might
> be more obvious to the user.
Not sure [UX] team?
> Best regards,
>
> Michael
Chers
5 years, 11 months
Some help needed with making operand path invisible in bool op LPE
by Michael Soegtrop
Dear Inkscape Team,
with my recent pull request, the bool op LPE should work properly.
A few notes / questions:
1.) The operand (other) path is not made invisible. I typically have my
operand paths in an invisible layer. Is this ok, or should the bool op
LPE make the operand path invisible? If so, I wonder how this could be
done. The main problem is that I have no idea how I could re-enable the
operand path when the bool op LPE is disabled (with the eye button in
the bool op list). As far as I can tell, the bool-op code doesn't run at
all when the bool-op is disabled, only when it is enabled.
Or should I change the bool op so that it works on groups of paths (as
created with Ctrl+K)? This would obviously solve the problem, but then I
would need a grouping LPE, because one of my operand paths is typically
a result of an LPE stack, while the other isn't
2.) The cut boolops only make sense if one path is an open path and one
path is a closed path. Should I disable the cut options, if this is not
the case? How can I detect this?
3.) The LPE only works on paths, not on objects. Is this ok? I guess
this is the case for all LPE.
4.) The LPE has options for the fill type (odd-even, non-zero,
positive). For the operand path (the other path) I can find out the
inherent fill type of the path. The problem is somehow that the fill
type is stored in SPItem objects, but the LPEs operator on SPCurve. The
closest point upstream in the call stack is
SPLPEItem::performPathEffect, but the SpItem is not passed down the the
specific LPE code. Any ideas?
Btw.: fill type negative would be nice to have.
Best regards,
Michael
5 years, 11 months
Marketing/Advocacy/Outreach Team - Proposed Objectives
by Ryan Gorley
As perhaps a primer to forming a new team to serve the Inkscape project, I
would put forward for discussion the following *objectives* for such a team:
1. *Increasing the project's contributor base,* as measured by code
commits, non-technical contributions, cash contributions, etc.
2. *Improving the market position of Inkscape*, as measured by user and
target-user opinion studies, favorable press coverage, increased usage, etc.
3. *Increasing community loyalty and engagement*, as measured by
participation in physical meetups, online discussions, social sharing, etc.
Finding consensus about objectives seems more productive at this stage than
strategy and tactics. I'd love to hear what you all think or would
add/remove/edit.
*(Bryce: I had this largely written prior to your response to the other
thread, so feel free to steer this conversation in a different direction if
you wish)*
5 years, 11 months
Join Us to Discuss Marketing Inkscape
by Ryan Gorley
If you're interested in volunteering your time and talent to help promote
Inkscape, join us on the Freenode #inkscape-devel IRC channel (
https://inkscape.org/en/*developer/chat/), next *Tuesday 20 June @ 20:00
GMT*.
This will be an informal meet-and-greet and a chance to take an inventory
of who is interested and what experience we can bring together to spread
the word about this amazing project. If you can't make it but wish to be
involved, don't worry, we'll also organize a follow-up meeting in July.
I look forward to meeting you all there!
Ryan Gorley @ Dijt <https://dijt.co/>
5 years, 11 months
svg-2 text gsoc project?
by Boudewijn Rempt
Hi,
We're currently working really hard to improve interoperability
between inkscape and Krita by rewriting all our vector support
to svg. We're also doing a new text object, based on svg instead
of odg.
So we're really interested in following along the 2017 svg-2 text
gsoc project to see what we can learn.
Is there already a branch and a wiki page for this project we can
follow?
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
5 years, 11 months
CI timeout for merge request
by Maximilian Gaukler
Hi,
as I saw you are migrating to gitlab, I wanted to submit a merge request
for a patch I already proposed on launchpad. Unfortunately, the build
takes way longer than the 1 hour timeout and therefore all my commits
are flagged as "build failed":
https://gitlab.com/mgmax/inkscape/builds/18388005
The first run made it to 77%, the second run to 39% of the build :-(
Greetings,
Max
5 years, 11 months
Git submodule policy / address sanitizer
by Michael Soegtrop
Dear Inkscape Team,
since gitlib is up and running, the question arizes if we want to use
submodules, and if so which folder structure should we use.
I want to add address / memory sanitizer support and use
https://github.com/arsenm/sanitizers-cmake. It is just a few files and I
could copy them verbatim, but it would make sense to add it as a submodule.
In case you don't know what address/memory sanitizer is: it creates
instrumented builds (about 2x slower) which check for all sorts of
invalid memory usage, like access to freed memory or reading
uninitialized variables. The cmake scripts above enable this by a cmake
define, similar to switching between debug and release builds. In my
experience it saves a lot of time in tracking down obscure bugs in
complex C++ code. I right now have a debug/release deviation I want to
track down.
Best regards,
Michael
5 years, 11 months
