- Inkscape Devel - Inkscape Mailman

New feature for master
by Jabier Arraiza 28 Jun '19

28 Jun '19

Hi all. I want to know if is good merge this branch into master. Code wise is done there is only some icons to fix and complete the great collection done by Adam Belis. Also want to know about defaulting if finished the icon set at time to substitute current default icons. Here is a video of the feature working: https://chat.inkscape.org/channel/team_ux?msg=xCidGRBhRfSYfyCNM And here are the MR: https://gitlab.com/inkscape/inkscape/merge_requests/745 Bye!!!!

3 2

Mailing list neither enabled or disabled
by Terry Brown 21 Jun '19

21 Jun '19

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

5 6

development
by Andrew Kurn 19 Jun '19

19 Jun '19

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

2 1

TV coverage on LGM
by Maren Hachmann 11 Jun '19

11 Jun '19

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

2 2

upcoming opening of new Inkscape forum
by brynn 09 Jun '19

09 Jun '19

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

1 0

forum rules finalized, message posted
by brynn 09 Jun '19

09 Jun '19

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

2 2

Board meeting Friday Jun 7th at 10am Pacific
by Bryce Harrington 08 Jun '19

08 Jun '19

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

1 1

Profiling Inkscape startup performance
by octycs 08 Jun '19

08 Jun '19

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

1 0

Build time vs. Dev time extensions
by unknown＠example.com 08 Jun '19

08 Jun '19

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/

1 0

Vectors Meeting (T-Minus 10 hours)
by Ryan Gorley 08 Jun '19

08 Jun '19

Hello All, It's that time of month <https://www.timeanddate.com/worldclock/fixedtime.html?msg=Inkscape+Vectors+…> when we get together and discuss Vectors items. On the agenda are team elections, LGM, fundraising, the new forum, and more. The location is the #team_vectors channel of our chat. For more details visit: https://gitlab.com/inkscape/vectors/general/issues/119 Come join us! Ryan

1 0