March 2023 - Inkscape Devel - Inkscape Mailman

call of 'virtualenv' with option 'p=python3' syntactically wrong
by fi＠igh.de 04 Jun '24

04 Jun '24

Dear Maintainers, after pulling revision 5448704355e03a97d2838e1ba30272db335f0dbb I have built inkscape according to https://inkscape.org/develop/getting-started/ Trying to manage extensions (Extensions -> Manage Extensions) I receive the following error message: There has been a problem creating the python environment: Return Code: 3: b'' b'The path =python3 (from --python==python3) does not exist\n' args: ['/usr/bin/virtualenv', '-p=python3', '/home/xx/.config/inkscape/extensions'] Indeed the call is syntactically wrong. Instead of '-p=python3' the option '-p python3' ### without equal sign should be used. As far as I understand, the problem seems to exist in inkscape/share/extensions/extension-manager-bootstrap.py:69 call('virtualenv', TARGET_DIR, p='python3') which then in inkex/command.py:to_args() is evaluated to the wrong sytnax. According to the (very good) comments in to_args() :Keyword Arguments: * *name* (``str``) -- Becomes ``--name="val"`` ... * *n* (``str``) -- Becomes ``-n=val`` ... it should become ``-n val``. I do not know whether a change would result in problems using other programs that want -n=val. Which should that be? Best regards Torsten -- ------------------------------------------------------------------------ Torsten Finke fi(a)igh.de ------------------------------------------------------------------------

3 2

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Inkscape 1.3 About Screen Contributor Voting until April 9
by Maren Hachmann 05 Apr '23

05 Apr '23

Hi Inkscape Contributors! It's that time of the year again :) We invite you to cast your vote on the 5 awesome About Screen Contest submissions that were favorited by 242 voting Community members. For this year's About Screen Contest, we have had 55 submissions from the Community, 49 of which met the requirements (licensing, branding etc.). These are the 5 items they liked the most: * "A long journey“ by Chris Hildenbrand * "Contest“ by Djelita Abderrahmane * "Creative Growth“ by Chris Hildenbrand * "Isometric Madness“ by Denis Kuznetsky * "Portal“ by Milad Moosavi (in alphabetical order) In this two-step selection process, it is now up to us, the Inkscape Contributors, to select the About Screen that we want for Inkscape 1.3. It's going to be a difficult choice, as they are all so cool :D Step 1: ======= Make sure that you are an Inkscape Member (see previous message or link below), and if you're not one yet, apply for membership and ask 3 of your team mates or other contributors whom you have worked with to confirm your membership. More info: https://inkscape.org/*membership/blog/inkscape-signs-new-fsa-sfc/ Step 2: ======= Visit https://inkscape.org/gallery/=artwork/inkscape-13-about-screen-contributor-… and rank the 5 images by clicking on the little circle right below them in order of preference (most liked first). The voting period starts NOW, and ends on April 9, 23:59 UTC. Voting is on the website only. The announcement of the winning entry is planned for April 11. Thank you to everyone who contributed to this year's About Screen Contest! Maren

1 2

Become an Inkscape Project Member!
by Maren Hachmann 28 Mar '23

28 Mar '23

Dear Inkscape Contributors, it's time to make your Inkscape Membership official! With that come voting rights for all kinds of regular contributors - like translators, social media managers, forum moderators, documentation writers, testers, bug managers, ... - (not only developers anymore!). The first occasion we will be using that for is the Contributor Vote for the ongoing About Screen Contest (contributor voting starts tomorrow, and will end on April 9, 23:59 UTC, there will be a separate email for that!), which is also going to be a bit of a test of the membership system for the upcoming Inkscape PLC election. Read all about it here: https://inkscape.org/*membership/blog/inkscape-signs-new-fsa-sfc/ If you have any questions or are looking for people to confirm your membership request, please ask away in the #general rocket.chat channel. In some cases, it will be helpful to state the nature of your contributions to the project, or to approach those directly who know about your contributions. Please approve membership requests of those whom you know to be a contributor by first hand experience, and do not approve other membership requests, as in the worst case, when the person is not a contributor, that can get your own membership revoked. Thank you to the PLC and the SFC for getting that set up for us, to the website team for providing infrastructure for it, and to the Vectors team for writing about it! Maren

2 2

Problem- (P6-Refactoring) Remove dependence on object-set.h in files in src/livarot directory.
by Kaustubh Kongile 27 Mar '23

27 Mar '23

Hello, Thank you for considering me to present my suggestions for removing the dependence on object-set.h before submitting my proposal for gsoc 2023. Here are the steps we can follow to remove the dependence on object-set.h: Identify where object-set.h is being used in the code by looking for #include statements and code that directly uses classes or functions defined in the file. Determine the functionality being used from object-set.h to find suitable alternatives. Research and find alternative solutions or libraries that provide similar functionality. Modify the code to use the alternative solution or library, replacing any references to object-set.h and modifying code that uses its classes or functions. Once we have verified the changes, we can commit them and submit them for review. I hope this information is helpful. If you have any questions or concerns, please let me know.I am not sure about the amount of time required to resolve this issue, so I would appreciate your guidance and suggestions on the matter. Best regards, Kaustubh

1 0

Developer Meeting Notes, March 26th 2023
by doctormo＠gmail.com 27 Mar '23

27 Mar '23

Hi Everyone, This is our first online meeting since the hackfest. Last week's meeting was canceled, so don't worry, you haven't missed any previous notes. Event: https://inkscape.org/cals/event/1/ Present this week: Lazur, Martin, Jonathan, Tav, Thomas, Jabier, NPJ, Marc, Mikekov, Rafael Next Meeting: Monday, April 3rd # Release Plans The alpha release has been uncertain because of reports of deadly crashes on undo. The reports have been a little anecdotal though. The general consesnsus at the meeting is that we should release the alpha right away and then re-release a new alpha if this issue can be confirmed in the latest versions after several fixes. Users can be asked to be brave so long as they understand the risks. Martin created the 1.3 and 1.3-alpha0 release objects on the website and Marc is planning on pushing the alpha out in the next two days. The mushroom about screen was used as the graphic for the alpha. We have a few outstanding merge requests which we can merge immediately. The developer team spent some time looking at these merge requests for our activity at the end of the meeting to clear the backlog for the release. # Jabier Wants to merge some branches, some are minor fixes but need to have better and more descriptions to help reviewers understand what they do, we managed to merge two and attach reviewers to three others. Martin wanted to make sure the corners LPE upgrade is scheduled for after 1.3 since it's quite large. # Jonathan Some reverse engineering of the AI format and helping Nicco putting together the ai importer. Progress is going well, text is likely to be supportable. Asked tav about the mesh gradient and having a number of nodes on the edges of the patches. Gtk4 proposal is ready and waiting to be sent to the PLC. An email got lost and has been resent to Marc and Tav was asked to push the PLC election, nominating the proctor Pono to run the election. # Marc Has been busy and sick, with appologies. # Martin Recovering from travel. Made a video for the hackfest which has been well recieved. Bug accellerator program fixes are submitted and merge request management and pushing for the alpha release. Some website fixes for the about screen contest voting. # MikeKov Looking at a bug #4186 with the new preserve path functionality and trying to work around a fitting alogorythem. We could detect when it's not going to work well and then try a different method, or try to remove the constraints but with bad output. Bug has been assigned and tagged for 1.3. #NPJ Experimenting with Apple archetecture. #Rafael Worked on bugs as part of the accelerator program. Fixed four issues this week, one fix actually fixed two issues. Currently looking into a regression in patterns, where you can't see a marker using a pattern as a context-fill. Pair up with Martin to look into the problem. #Tav Spent a little time in the last week playing with Gtk4, try out the new Gtk List View, it wasn't performing quite as expected. It only generates widgets for things which are on the screen, but this makes the scrolling weird. Made a lsit of 10,000 items, it would scroll for a little bit but then it would jump around. # Thomas Doing some experiments for how to fix menus in macOS, contuing the work from the hackfest to see if there's an upstream patch that can be created. # Team Activity We looked at five merge requests with the Approve Please tag, and merged two, and assigned the rest to reviewers for further testing. Thanks to everyone for coming to the meeting, see you all next week!

3 2

Contribute / GSoC
by Mateus Krause 23 Mar '23

23 Mar '23

Hello people from dev mailing list, My name is Mateus Krause and for a long time I want to contribute with Inkscape. I've been using the program for a few years now and really appreciate the work put into the project. I just found out that Google Summer of Code is open and maybe this could be a good starting point for me to help. Currently, I study Computational Mathematics at Universidade Federal de Minas Gerais (UFMG) - Brazil, and I have some knowledge and practical experience in small-medium C++ projects, using Make or C-Make, external libraries, and I think Inkscape would be a good place for me to start contributing in a bigger project with code for the first time. I would really be grateful if someone can help me with my GSoC application. The suggested project ideas that catch my attention are: P9 - Path Library Improvements, I really liked this one because of my mathematics background, and it looks fun; P12 - Customizable Appearance of Canvas Controls, it's a part I interact very often and I really see how this can improve the experience, I also have a background in web dev, so dealing with CSS would not be an issue; P5 - UI-Free Inkscape, this looks interesting because of the challenge managing dependencies. I think I have the knowledge to complete any of this tasks, so at least for me it would be a great opportunity to be familiarized helping in a big community and learn with the experience. For now, I only have gone to the "getting started with Inkscape development" page and did the basics. As part of the application, I'm looking the bug tracker to see what can I complete. Either way, I want to contribute with this project, so any guidance would be awesome. Thanks in advance. -- Mateus Krause

3 2

Hackfest notes from Pono
by Daniel Pono Takamori 17 Mar '23

17 Mar '23

Hey everyone, Here are some notes I took after collecting some questions from people at the Hackfest. I'll dump them here and here's a link to the markdown file on Nextcloud: https://office.inkscape.org/nextcloud/index.php/s/62TS2K4obzat4Rd At the end of the week I asked the people here what they liked about the project, what could be improved, how was the Hackfest and what can SFC and I do to better support the project. After I presented these comments and some of my own thoughts about them, we opened the conversation up to discussion and the bits at the bottom are the resulting conversations. Thanks again for having me, and I'm looking forward to building out the in-person events so everyone can come or participate to the best of their abilities. -Pono ## Things to celebrate about Inkscape and it's community There's a good spirit of volunteering and people taking on tasks that are interesting to them. This goes both ways though and sometimes means there are tasks that get left behind for no one to pick up. Liberal code contribution culture which has enabled lots of innovation and creativity. Receptive to new ideas. People are empowered to express themselves, regardless of their position in the world. People focused project, doesn't require lots of technical expertise and has a low bar to picking up. Mature project with lots of good momentum. People love Inkscape! ## Improvements to be made to Inkscape and it's community Diversity of participants was something that came up a lot. Working to have better outreach to make sure all groups and teams are represented. How can we get younger users and contributors? Make it easier for people to contribute non-code (I'm not sure what the processes around documentation, how-tos, etc work). We need better onboarding docs so we don't have to explain "basics" over and over again. "Inkscape on Twitch" - related to other outreach efforts Spending money... we need to come up with a more formal budget to support all teams and I (pono) think that a budget will make it easier to get money to flow since when things are within an accepted budget, it's easier to get things moving. Listening and communicating with users - surveys, forums, Rocketchat, etc. We need more dialogue with users (technical and non). How are artists, scientists and makers using Inkscape? Formalizing subgroups - with fear of over administering, how do we codify the teams so that they can operate autonomously but be included in all decision making processes? **pono idea - seats for each subteam on the PLC and more communication between groups** How do we get Inkscape in schools? This is something SFC has been thinking about in general ## Hackfest ### Things that went well Relationship building is unmatched in person. This was a great opportunity to meet and chat and the travel being handled if needed, was great. Length was good, maybe a long weekend could get more people. In person communication makes it much easier to clear up miscommunications and intentions. The venue was great and everything was made easy to focus on work and relationships. ### Things to be improved Calling it a 'Hackfest' might've discouraged teams from participating and we *need* all teams to participate. 15-25 people would be a better group. More diversity among participants, *pono let's get some scholarships for new and minority contributors* Open space and loud conversations made it hard to focus, providing quiet spaces would help. More thought into how to include remote participants. Have one with users? Does it have to be this event? More regular cadence makes it easier to get people here. ## SFC - how can we do better and what have we done well being clear about our limits SFC is not just an anonymous thing to help with managing things, we need to establish a more close relationship rewarding volunteers financial help was great and improved attendance Pono/SFC is very helpful for networking between FOSS projects, like introducing the right people and thus increasing the chances of successful collaborations Be a sparring partner for discussing policy & fundamental issues, "outside" person that can help when an outsider is need. E.g. CoC issues within the PLC, election proctor Also to escalate things within SFC if progress is slow. SFC should monitor foundations for grant opportunities & forward them to potentially relevant member projects making sure contracts and money flow smoothly SFC done a good job with mediation and spending money ## Notes during discussion hackfest rebuilds energy 5-10 is good for hacking OutreachFest colocating an event? FOSDEM! https://libregraphicsmeeting.org/ conference in Northeast? develop PenPot relationship Jabier and Adam Belis what we need from Inkscape to use PenPot for UI Scribus? Blender? subteams marin - didn't like term leader, have an organizer, contact, representative can switch off! describe as not one person, but a team collectively divvies up responsibilities if you want to be a formal group, you need to meet a set of criteria jonathan and ted thinking about it community building things graphics for teams, hat or graphics mousepads :P vectors, developers, documentaion, testing, translation, UX https://inkscape.org/user/teams/ recognized groups have duties benefits: PLC can delegate technical decisions to dev team, outreach to vectors, etc formalize duties and expectations keep outside FSA probably partners program GNOME has a Sponsors section allows relationship management *ChromeOS* ?? maybe we can talk with Google? how to package for those chromebooks schools helps schools administer the program krita and blender are on steam maybe need someone android? google funding for gtk backend? putting out more video for exposure - Chris attractive to sponsors build up vectors to make more content budget for video how does krita do it? need to try more things what do people like from Inkscape? we don't really know Youtube channel? surveys! demographics working with TuxDigital presskit press list for SFC Plausible website is contributor friendly not marketing slick friendly branding is not a singular thing it's there to tell your story "the only vector software that is a community project" more concious of public image

1 0

Proposal for accelerating the GTK4 migration
by Jonathan Neuhauser 16 Mar '23

16 Mar '23

Dear Inkscape developers, the Hackfest in Bensberg has been very productive and one of the outputs is a proposal to accelerate the GTK4 migration, as discussed during the recent development database. For this, we propose to hire two contractors for a span of 4 months, one GTK expert and one Inkscape expert. (Recently, on the PLC mailing list, I mailed around a version of the proposal including only the GTK expert. Feedback there and further discussions here have allowed to combine both into one proposal again.) Please find the proposal attached, including the job postings for both. I'll try to incorporate feedback until Sunday, March 19, so a PLC vote can be held afterwards. Feel free to contact me via email or on RocketChat. Best regards, Jonathan (joneuhauser on RocketChat)

1 1

Draft for a refactoring and improvement of the test suite
by paolo fx 14 Mar '23

14 Mar '23

Hello inkscapers, I could contribute to the development of the code in my spare time if the following idea makes sense and is of value. While talking in the #irc dev channel and in the last developer meeting, it turned out that the test suite in testfiles directory is somewhat messy and a refactoring could be desirable for some reasons. Here's my proposal. First of all, tests should be grouped in coherent and standard categories. A standard classification is: end to end testing ---> integration testing ---> unit testing This classification, translated into a dir tree would be: ---------------------------------------------------------- testfiles |______end2end_tests | |_______gui_tests | |_______cli_tests | |______integration_tests | |______unit_tests | |______CMakeLists.txt | |______CTestCustom.cmake.in | |______README.md [SUBDIR] gui_tests: empty for now, just add a TODO/FILL-ME note inside it. [SUBDIR] cli_tests: *) rendering tests are made with CLI (as the CMakeLists.txt confirms), so they should be moved inside cli_tests. Therefore, move here svg files from "rendering_tests" and move rendering_tests/test.sh as cli_tests/rendering.sh *) leave here the current content of cli_tests *) add an "images" dir containing all the graphic files [SUBDIR] integration_tests: it will contain cpp or script files in the form: operation1_operation2_..operationN.cpp (or .sh, or .py etc). [SUBDIR] unit_tests: a software unit can be meant both as: 1) (see testfiles/src/curve-test.cpp) a self-referential "concept" 2) (see testfiles/src/uri-test.cpp) as a class, or even a single function, from the API. The important thing is to separate unit tests from integration tests, which are sequences of different tasks. From what I see, the "testfiles/src" dir currently contains unit tests (if cpp files perform integration tests, they should be moved to the testfiles/integration_tests dir) In addition, do move lpe images here (inside an "images" dir). Add a note on the README that lpe stuff is here (as it partially is, actually). [FILE] CMakeLists.txt [FILE] CTestCustom.cmake.in [FILE] README.md: note: only ONE readme will be used for describing this test suite. It will describe what the tests do and how to launch them separately. It will also contain a very short mention - one or two lines - of the model (e2e tests ---> integration tests ---> unit tests) used. -------------------------------------------------------------------------- There are two possible concrete values/advantages in this new struct: 1) The reordered code would be much more readable, especially in the perspective of finding and running on the fly a specific test for a specific need or in the perspective of adding new ones, or deleting obsolete ones. 2) Integration tests could significantly speed up bug fixing, other than giving a more robust validation procedure of the released software. Let me show an example. An integration test could consist in the same steps described in a submitted bug: open a file ---> modify a curve ---> apply a filter ---> export to png In the integration_tests dir, there could be, together with test files, one (or more than one) file called "integration_test_template.cpp", which is meant as an example, with basic operations done sequentially (open, modify, filter, export etc.). Then, if another example called "integration_test_custom.cpp" is created by the developer (but not added to the source tree and added to .gitignore), it would contain code modeled on the basis of "integration_test_template.cpp" and it would be automatically compiled because as a part of the CMakeLists directives. In this way, we have a ready-to-use environment for testing the API. So, when a nasty bug is described together with its steps, a "integration_test_custom.cpp" file can be created on the fly by using chunks of code taken from "integration_test_template.cpp" in order to replicate the steps. What do you think? And do you think that the integration_tests template would be really useful? In this last case, could you share an example (or more than one) of a bug that can be managed with "integration_test_custom.cpp" so as to have a useful case study? If the idea appears good and collects approval, I can start making a fork and a new branch for it on my local clone.

2 1