Re: [Inkscape-devel] Debian 8 compatibility falling apart after one month of Debian 9
by Michael Soegtrop
Ok, I am giving up now. The next issue is the change of
"create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way
to patch this for GTK 3.14, because there Gtk::Menu::Menu(const
Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I
have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
5 years, 6 months
Change introduced last week requires a newer CMake version than specified - what should the minimum CMake version be set to?
by Michael Soegtrop
Dear Inkscape Team,
I found that since a change introduced a week ago the inkscape CMake
files are incompatible with the CMake version which comes with Debian 8,
which is 3.0.2. Ok I should update to 9 ;-)
A question: the inkscape main CMake file mentions minimum version 2.8.2,
which definitely does not work. 3.0.2 also does not work.
CMake Version 3.6.2 does work. According to some googled hints the
specific constructs introducing the incompatibility require at least
CMake 3.2.
My question: what should I set the minimum version to? 3.6.2 since I
tested it with it? Or should I be more relaxed? What is the minimum
version of CMake people are actually using successfully?
Or should the change which introduced the incompatibility with Debian 8
be modified so that it works with older versions of CMake, e.g. 3.0.2?
Best regards,
Michael
5 years, 6 months
Inkscape freezing while adding grid.
by Christophe Lebras
Hi,
Please excuse my bad English.
I have a problem with Inkscape since commit d6f2d85a (jemalloc cmake module)
When I add a grid in Inkscape (Document properties/Grids/New), inkscape
freeze and I must kill it.
I’m under Arch Linux with jemalloc 5.0.1.
If i compile without jemalloc or with version 4.5.0, there is no freeze.
I reproduced the problem with openSuse tumbleweed but not with openSuse
42.1 and Ubuntu 17.04.
With debugger, I found that Inkscape freeze in method
DocumentProperties::update_gridspage(), line 1291:
_grids_notebook.remove_page(-1);
and that it's related to RegisteredColorPicker widgets used in method
newSpecificWidget() of classes CanvasXYGrid and CanvasAxonomGrid.
When i comment the code wich pack these widgets, there is no freeze.
Unfortunately, I did not succeed to go further with debugger (I get stuck
with a call to g_object_unref).
I rewrite the code which manage grid properties without using Gtk:Manage
and there is no freeze.
I will clean my code and do a merge request.
If anyone want to look at this problem, there is maybe a better solution.
Best regards,
Christophe
5 years, 6 months
Unsubscribe from the list
by chandrakant dhutadmal
Dear Community,
Please let me know the process to unsubscribe from the mailing list.
Regards,Chandrakant Dhutadmal
5 years, 6 months
Re: [Inkscape-devel] DTP dictionary for InkScape
by Jabier Arraiza
Hi all, I just recibed this mensage from Jairo. Thanks Jairo.
Best.
On Wed, 2017-07-19 at 10:14 -0300, Jairo Willian wrote:
> Jabier, Tavmjong or Alex
>
> Could you redirect this message for me?
> I have this DTP content and i would like share this material with
> InkScape community.
> I think that, this contents may be interesting in a "help session" or
> another place associated a functions and/or features.
>
> What you think about it? If OK, i can transfer all terms in a CC, GLP
> or other copyleft license.
>
> http://www.terra.com.br/macmania/macmania/resenhas/resenhas_dtp.htm
>
> PS: sorry, but the currency only in pt_BR.
>
> Thanks in advance.
>
> Jairo Willian
5 years, 6 months
gallery moderation, fan art, and copyright
by brynn
Hi Friends,
Another moderation question has come up (mostly just for me), which is
about how we want to define "fan art". Most (if not all) of the moderators
think fan art should be allowed in the gallery. But I think it might be a good
idea to have some parameters about it, and so I'm hoping the community can offer
their thoughts about it.
For a starting point and example, I'm totally ok with the Wikipedia
defintion (https://en.wikipedia.org/wiki/Fan_art) :
"Fan art, or fanart, are artworks created by fans of a work of fiction
(generally visual media such as comics, film, television shows, or video games)
and derived from a series character or other aspect of that work."
Does anyone think it should be expanded or restricted in scope, from
there? Or should the description be more or less detailed or specific?
A separate but related question is whether we want to bother with
copyright issues, or leave it up to the license holder whether they want the
image removed. For example, if someone reproduces a Pepsi or Coke logo. Or I
remember a popular AI tutorial a few years ago, about how to draw the Chevy
logo, which I always wondered whether it was a copyright violation. Those don't
particularly seem to be fan art, at least not by the wikipedia
definition....unless maybe television commercials are considered fiction.
Martin says there is a concept within the DMCA and EUCD known as "safe
harbor" which protects small websites from being responsible if its members post
a copyrighted image. At least that's my understanding, based on the research I
did about it. I might not have paraphrased it technically correctly.
So should we go with the "it's not our job /we're not lawyers" position?
Or should we be a little bit pro-active for blatant copyright issues. If we
want to be a little bit proactive, I'm thinking we should also set some
parameters about that. Or at least clearly state our policy.
Fyi, this is what the current CoC says about it "Art must be your own
original creation or derived from artwork available under an open licence. We
cannot accept submissions that infringe copyrights."
Personally, since Inkscape is an artist's tool (among many other uses),
I think the community should be a little proactive about protecting copyrights
and/or licenses. But I also think that if it requires a long and complex
discussion, or detailed changes to the CoC, then falling back to "it's not our
job" might be reasonable. But if that's the case, then the CoC isn't properly
stating our position, and perhaps should be edited.
Thanks for any thoughts or comments you might have about these things.
All best,
brynn
5 years, 6 months
Bool LPE ready to merge
by Michael Soegtrop
Dear Jabier & Inkscape Team,
I think the Bool LPE updates are ready to merge. I already created a
merge request a while ago (MSoegtrop:lpe-bool-hide-operand).
The changes are:
- split bool LPE into bool LPE and cut/trim path LPE
- automatically hide/unhide operand paths
- issue error message if operand paths have wrong type (open/closed)
- LPE works directly on any object for "this" and operand.
I think the changes in the .POT file in
https://gitlab.com/MSoegtrop/inkscape/compare/master...lpe-bool-hide-operand
Jabier mentioned are ok - it was regenerated to add the new strings from
my files.
Best regards,
Michael
5 years, 6 months
