moderators need ability to curate the description in gallery
by brynn
Hi Friends,
Reference the 3 images uploaded by this member:
https://inkscape.org/~yendrifernando/
The images appear to be made with Inkscape, but in my opinion, the links
in the description are spam. As a moderator, I would like to be able to edit
the description (via Curate) and remove only the "www.". In that way, the
description still tributes the inspiration for the images to that website (as
the member appears to intend), without having an active link to the website.
Breaking the link removes the spam.
Martin and I have had an extended private discussion about this. But he
disagrees with giving moderators the ability to edit the description. He says
that we need to have a community discussion about it.
I'll have to be honest and say that I don't understand his position, or
even really know exactly what his position is. Even if I did, I wouldn't try to
represent it. So he'll have to do that. Our discussion ranged far and wide
over moderation subjects, but none of his arguments really hit home to me, as a
good reason not to allow moderators to edit (curate) the description. So it
seems we've hit a stalemate.
I'll be honest again and say that I'm not sure if the purpose of this
discussion is to repeat our discussion publicly, or just to get opinions on
curating the description. Because a lot of his concerns seemed to be about
potentially overly aggressive moderation. Or maybe it's both? But I think I'm
a fair moderator and can train fair moderators, so I'm ready either way :-)
Martin, I hope this is a fair introduction of the issue?
All best,
brynn
4 years, 2 months
Mailing list neither enabled or disabled
by Terry Brown
Perhaps this happened to a lot of people and maybe it's been discussed,
but I dropped off inkscape-devel and inkscape-users. I think I signed
up for the new lists as soon as I saw the announcement, but checking my
settings just now the radio buttons
Delivery status: Enabled [ ] Disabled [ ]
were both off, the mailing list was neither enabled or disabled.
Wonder if it happened to others.
Fixed from my point of view now.
Cheers -Terry
4 years, 3 months
development
by Andrew Kurn
I'd like to ask your advice on how to set up a development
environment for Inks.
Can I do it on an old 32-bit machine? Can I do it on a
Raspberry Pi?
Can I do it with just gcc and make?
If there is someone who is willing to answer questions of this
type, perhaps you would like to mentor me.
Andrew
4 years, 3 months
TV coverage on LGM
by Maren Hachmann
Hi everyone,
I just got a reply from Agnès from K8, about the press coverage.
Starting at ~ 24:00 of
https://www.sr-mediathek.de/index.php?seite=7&id=74463 , there's a TV
report about the mapathon before LGM, which ends with pictures of some
charitable open source graphics software developers (aka Mc, @jnweiger
and @mgmax ) around minute 27.
She wrote that a team from the French TV was there, too, but that their
report isn't available yet. When it will be released, that will be at
https://www.tv8.fr/VOD/Grenzenlos/09-05-2019-grenzenlos-TME4BFMq1i.html.
Regards
Maren
------------
>
> Hallo Maren,
>
> hier den Link zum SR-Bericht:
> https://www.sr-mediathek.de/index.php?seite=7&id=74463
>
> Aus Frankreich war der lokale Sender TV8 Moselle Est da aber der
> Bericht ist noch nicht online. Er wird Teil der Sendung "Grenzenlos"
> sein. Hier den Link zur Sendung, man soll halt etwas Geduld haben...
> https://www.tv8.fr/VOD/Grenzenlos/09-05-2019-grenzenlos-TME4BFMq1i.html
>
> Liebe Grüße Agnès
4 years, 3 months
upcoming opening of new Inkscape forum
by brynn
Hi Friends,
The Inkscape website will be opening a new forum in August 2019. The primary
purpose of the forum will be providing support for Inkscape, but it will serve
the whole project and community, in whatever way it can. It will function in
much the same way that InkscapeForum.com
(http://www.inkscapeforum.com/index.php) and Inkscape Community's forum
(https://forum.inkscapecommunity.com/index.php?action=forum) currently do.
Concurrently to opening the new forum, Inkscape Community's forum will
essentially close. All of its forum traffic will be diverted to the new forum
(although its tutorials and other resources will remain available). Since the
Inkscape project has lost contact with the owner of InkscapeForum.com we assume
it will remain open.
Please make plans to change your forum bookmarks, and to visit the new forum in
August. If you're not already registered on the Inkscape website, you will need
to register. Once you're logged in to the website, you're also logged in to the
forum.
We will be thrilled to welcome you, and to provide the same quality of support
you're accustomed to! Here is the link to the new forum. Although please note
that posting will not be allowed until August. But you can look around and see
everything about how it works, except for posting a message.
https://inkscape.org/forums/
If you have any questions, please feel free to ask.
All best,
brynn
4 years, 3 months
forum rules finalized, message posted
by brynn
Hi Friends,
Since we've had a volunteer to hear escalated complaints re the CoC
(thanks C R !!), I was able to finalize and post the forum rules and guidelines.
I made the sticky forum post about this. If anyone has any comments or
suggestions about what I wrote, please let me know and I'll edit it.
https://inkscape.org/forums/forum-news/forum-rules/
(Note that you can't post in the forum yet.)
All best,
brynn
4 years, 3 months
Board meeting Friday Jun 7th at 10am Pacific
by Bryce Harrington
Our monthly board meeting is scheduled for Friday, Jun 7th,
at 10am Pacific in #inkscape-devel. All members are welcome.
http://wiki.inkscape.org/wiki/index.php/Board_Meetings
Agenda:
-------
* CoC: escalation point person needed
* Hackfest debrief [http://libregraphicsmeeting.org/2019/ LGM 2019]
* Infrastructure
** mailing list migration off SourceForge
** Wiki migration off OSUOSL
* GSoC
* Other Business
** CoC Escalation Point
*** Need someone to handle escalated complaints re CoC, since Krzysztof Kosiński has resigned. Hopefully someone with training or experience with conflict resolution or mediation. Not much time needed, probably would never happen, but need to be ready just in case. Currently it's vacant.
** Forums: Should a job postings area be included?
*** Discuss the possibility of having something like a jobs board on the new forum. Something similar to https://forum.inkscapecommunity.com/index.php?board=12.0 Would need strict rules to prevent misuse, spam, liability, etc.
Action Items from last meeting:
-------------------------------
== Bug Migration ==
♢ ACTION: (Blocked) Check with SFC if amounts of $100 / $50 / $25 for 1st, 2nd, 3rd is within IRS limits [bryce]
♢ ACTION: (Blocked) Hold referendum on top game prizes after confirmed by SFC [bryce]
== Inkscape 1.0 beta ==
♢ ACTION: Check in with people doing test case conversion [Tav]
♢ ACTION: ping jimmac/barbara about the symbolic icons for adding the theme to Inkscape [scislac]
♢ ACTION: Plan video for Inkscape 1.0 release [crogers]
♢ ACTION: Brainstorm plans for 1.0beta / 1.0 commemorative merch [crogers, tedg]
=== Sponsorship Management ===
♢ ACTION: Find out about the new event insurance from #conservancy [tedg]
Transcripts of previous meetings:
---------------------------------
http://alpha.inkscape.org/board/meetings/transcripts/
Bryce
4 years, 3 months
Profiling Inkscape startup performance
by octycs
Hello everyone,
While I'm an Inkscape user for some years now, I'm fairly new to it from
a developer point of view.
In terms of performance, I've been recently doing some analysis with the
help of cpu profiling tools.
My aim in this mail is to present some of the things I noticed and maybe
some ideas how to improve them.
The tools I've been using are the gperftools and more recently the linux
performance tool `perf` together with FlameGraphs (Disclaimer: Since
I've been using them for the first time I don't have a deep knowledge
about them).
Both tools can capture the stack at a timed interval, so it is possible
to estimate how much time is spent in different functions. These can be
visualized for example by a flame graph which I found quite handy. In
theses graphs the x-axis shows the stack records alphabetically sorted
(not chronologically) and if possible merged. The y-axis shows the call
stack.
Recording the startup of Inkscape just until before the Window shows
up[1] results in the attached results[2]. The original file is an SVG
file (Note: This is a large interactive SVG and primarily intended to be
opened in a browser[3]). By looking at the result I identified some
parts that might be of interest (See annotated PNG file).
- A - (100ms):
Based on some individual function calls (e.g. get_preferred_width) I
assume this is related to the layout calculations. Noteworthy is here
that the stack mostly has a depth of up to 80-90 frames. I don't know
whether this is usual for gtk, but for me this looks like the
calculation of the layout might get very complex. Maybe it is possible
in some places to simplify the layout (I'm referring e.g. to [4]). While
this part only takes around 100ms in this record, the actual impact
could be larger because the recording stops just before the window shows
up. However, even after it shows there is a noticeable delay until it
gets responsive.
- B - (170ms):
This part is the setup of the toolboxes at the top. I find interesting
here that with the exception of the TextToolbar, each Toolbar only takes
5-10ms to load, but because there are so many of them, they sum up over
100ms (again without the TextToolbar).
One idea I'll therefore try to look into in the next time is whether it
is possible to lazy-load them, so that the GUI relevant initialization
only runs as soon as required (when the tool is used the first time).
Since most toolbars initialize in up to 10ms the delay is insignificant
when clicking on a tool.
- C and D - (65ms / 80ms):
These relate to the initialization of the menu resp. the DesktopWidget.
I haven't had a much closer look yet, but both take longer than I
assumed. There might be some optimizations possible as well (e.g. I
noticed SwatchesPanel::_rebuild is called at least twice, each running
nearly 20ms).
- E - (260ms):
The last section is about loading the extensions. I don't know a lot
about the extensions system now and the future plans, but I also
wouldn't have expected this part to take that much time.
- Looking further -
The attached recording of the startup here is of course only a part of
interesting parts for optimization (And there are also a lot of parts
that I cannot identify with certainty).
One second aspect I want to look more into is for example the fill and
stroke dialog, which takes up to 600ms to load (not part of the attached
profiling) because all marker images are expensively loaded and rendered
as SPObjects at runtime. And if it is open on startup this time adds up
to the delay before the window even shows up.
--
All in all I admit that this a rather chaotic collection of maybe or
maybe not promising parts for performance optimizations. This surely
only touches the surface of possible analysis and improvements, but I
wanted to share this early because maybe you have some ideas as well (or
there were some things done in the past that I don't know of).
If you have any feedback I'd appreciate it a lot.
Best regards,
octycs
[1] I did this by calling exit just before
`InkscapeApplication::window_open` returns.
[2] The results still have parts that are marked as "[unknown]". I tried
solving this by passing "-fno-omit-frame-pointer" (see FlameGraph
documentation for more), but this did not have an effect. Though this
could also be because cmake automatically re-ran when I started building.
[3] Direct link:
https://octycs.eu/static/shared/190608_perf_startup_999hz.svg
[4] https://gitlab.com/inkscape/inkscape/issues/9#note_132218218
4 years, 3 months
Build time vs. Dev time extensions
by unknown＠example.com
Dear developers,
Thanks to Tav's for his excellent hackfest overview which related
general annoyance about extensions, it pointed to Uniconvertor being a
particular issue.
I'm sorry I wasn't at the meeting to talk about the issues around
packaging extensions more directly. So I'm hoping this email can fill
in for that and get some of the information I would have conveyed at
the meeting.
I won't speak to the API breaking, since Thomas and others have done
very good work making sure that the API has greater backwards
compatibility and is much less likely to break in older code. (now)
But the specific issue here is about how we ship different extensions.
There has historically been a fixed relationship between the
`share/extensions` directory and what we ship. When we moved the
extensions into their own repository, we included the git as a sub
module to continue this relationship.
But as development has progressed, it's become clear that there's way
too much variability to both have a solid extensions project and keep
this fixed one to one relationship.
Take Uniconvertor as an example. It's a bunch of extensions that call
software which must already be installed to work. Which are both
important to Inkscape and impossible to corral into a standard code
quality framework. They've been moved to[1] so they can be developed
separately to provide them with more latitude.
Now this breaks the build time assumptions about what is in the
share/extensions directory at dev time. Because now we have a situation
where packagers are not guaranteed to have all the extensions they may
want to ship. But this must be so, because while the core extensions
should provide a stable API, the doc callers for the help menu and
basic extensions; other extensions are often not written in python,
have no tests, don't have code quality checks, use external programs
which may not be installed and are even only used on windows (but we
ship them to linux users currently).
The future of extensions will be the extension-manager[2] which will
allow inkscape users to install extra functionality[3] without
requiring Inkscape to ship quite so many extensions by default. You can
see Uniconvertor extensions packaged on test pypi here for a flavour of
what this would look like[4]. (The plan for 1.0 is to ship the manager
as a stand alone app that can be installed separately for testing)
But before that glorious future; all Inkscape packagers need to be able
to bundle in extensions different locations so that they can package in
all the things their users will need. This should provide them with far
more power to decide what's important than currently, where extensions
are denied from installers because of developer reasons.
I do not know how packagers wish to do this. Linux packagers may want
to link to uniconvertor as a recommends package with it's own
dependencies (which would be good). Windows and Mac may want to
literally include the code into their distribution. (I'm hoping this
email can spark a discussion so we can get the tooling right for all
packager types).
So far I feel that I've ruffled feathers by removing extensions. But I
don't believe that the build time extensions are the same thing as the
developer time core extensions and I hope this email goes some way to
laying out the logic for this and why it would make the Inkscape
project stronger to do it this way.
Best Regards, Martin Owens
1. https://gitlab.com/inkscape/extras/extensions-uniconvertor
2. https://gitlab.com/inkscape/extension-manager
3. https://twitter.com/realdoctormo/status/1134107821249847298
4. https://test.pypi.org/project/inkscape-uniconvertor/
4 years, 3 months
