- Inkscape Devel - Inkscape Mailman

Survey Results 2025
by Martin Owens 07 Nov '25

07 Nov '25

Dear Developer Team, Big thanks to everyone who filled out this year's developer team survey. These are the digested results as a summary, full results can be provided on office.inkscape.org Admin note: We'll use office.inkscape.org for next year's survey exclusively. There was no difference between google and nextcloud in functionality. 26 people responded, 77% claimed to be programmers, 65% were active, 70% were new (and didn't fill out the 2024 survey). For developer platform we have a fair split between Debian based (35%), Fedora or Arch based (35%) and macOS (23%). With Windows being 4% (1 person), so a considerable deficit in windows developer retention this year. Testing looks little better with 60% able to test on Wayland, 50% on X11, 46% Windows and macOS. Extra 23% Android and one person on macOS intel and one on ChromeOS. Most people who needed help are finding help in the chatroom. Only one person needed help and didn't find it. Build instructions were found by everyone except 2 people. And only 1 person couldn't get their build to work. Most people fixed issues they wanted to or was interesting. No one couldn't find issues to work on. Merge requests was our biggest failure this year with a lot of problems reported ion Slow Reviewing, Reviewers asking for too many changes (usually diverging from the original work with refactoring challenges) and also a new problem, merge requests getting stuck waiting for the UX/UI team to respond. This is the first time where we've tried to put a pause on merges until they can be checked by the UX team but we're going to have some rules about how long we can wait for volunteers to become available to check the work. (and how big the requested changes can be before it should just be a rejection) Testing was good. We're getting better at requesting people write tests. though most people didn't think testing frameworks were expressive or extensive enough yet. A direction the project is improving on this year. The majority of people work on Inkscape as Volunteers for Public Service (54%),followed by Education and Leisure (42%), 3 people were hired to work on inkscape and 9 people said "Other" mysteriously. What we should work on ranged from improving programmer documentation, tutorials and videos to help developers get started. To full breakdowns of all the various parts of the code. A big problem highlighted was the massive duplication of documentation on the wiki, website and code repository was highlighted by the vast majority of people. Other things of note were timing of meetings (see Tav's poll) and and paying more people to work on inkscape. Lots of people thanked the project for keeping everything moving and how helpful an friendly our community it. Well done everyone! That's it for this year. Thanks to everyone for responding and I'll see you all next year. Best Regards, Martin Owens

1 0

Measurement input UI suggestion
by Ray at Daylon 03 Nov '25

03 Nov '25

Hi everyone, I was wondering if it would be worthwhile to modify Inkscape's UI where input of measurement values are used. My apologies if this has been discussed before. Currently (version 1.4.2) measurement input fields use an edit box containing the number and a combo box to specify the measurement unit. My suggestion is to use an edit box alone, with the user indicating the measurement unit after the number by typing its name e.g. "4.2px". A space may be optionally used if desired e.g. "4.2 px" (current locale is used to interpret and display decimal points). Okay, but why? - Less UI widgets to place, show/hide/enable, reflect to/from, etc. - Less chance of accidentally using the wrong unit by forgetting to change the combo box selection. - Ability to use multi-unit measures e.g. "2p4" to indicate 2 picas and 4 pts, common in typography, or things like "6ft 2in". - Percent symbol (%) can be used where appropriate to indicate a percentage of some contextual distance e.g. a document dimension, lessening the need for users to figure out the computed distance. If this is of any interest, I have some C++ library code to help with implementation. Ray Gardener Daylon Graphics Ltd. www.daylongraphics.com

3 3

Developer Meeting, Nov 2nd 2025
by Martin Owens 02 Nov '25

02 Nov '25

Hey Everyone, Sunday meeting this week, Monday next week, big thanks to everyone who came today. Event: https://inkscape.org/cals/event/64/ Attending: Martin, Willy(ltlnx), Marc, Philip(pbs), Tav Next Meeting: https://inkscape.org/cals/event/1/ There was a discussion about live path effects and merge requests. We reviewed a merge request which was stuck in review and got it un blocked by the consensus of the team. We talked about some of the difficulties with live path effects and getting things fixed while waiting to get lpe structures refactored. We talked about the release for 1.4.3 and some of the outstanding issues, the file opening in macOS and the language change crashes in windows. A review of a bunch of different issues depending on their priority on the milestone mostly between Itlnx and Pbs. We talked about a Gio security bug which can cause a security issue, but it's an upstream issue and it's only breaking on Windows. We tried to think up ways of testing the issue given out limited access to windows machines and experts who can help debug it. Marc will report a bug upstream to Gio / security gnome org. Marc has moved the translation work their own po files and communicated with the developer and translation mailing lists. Thanks Marc! Martin has paused working on the engine waiting for reviews, they're working to get a new paint order widget which is a restackable widget that allow values based on their order and is poking Gtk with the specific UX they want. Willy was working on the default canvas colors in the preferences and has been looking at some of the difficulties in Gtk4 widgets for color selection. Tav has been working on getting his merge requests merged and reviewing his color font work again. Martin will do the developer survey results next week. Thanks everyone for joining on this Sunday Evening/Morning. Best Regards, Martin Owens

1 0

New submodule: po/
by Marc Jeanmougin 31 Oct '25

31 Oct '25

Hi devs, po/ is now a submodule pointing to https://gitlab.com/inkscape/translations.git If you have any issues with this folder in your branches/MRs, make sure when you rebase to get the content with "git submodule update --init" to be able to build :) Apart from that, not much changes for translations on the dev side, just more automation. Small changes 1 : You don't need to specify a new translatable cpp or inx file manually - if you want to mark a new file with strings as NON-translatable, you will still need to add it into POTFILES.skip, now in the translations repository Small change 2 : If you fix a typo in the source code and don't want to fuzzy its previous translations, you'll need to do the po file search and replace into the translations repo If you have any questions, feel free to ask :) Best, -- Marc

1 0

Developer Meeting, Oct 25th 2025
by Martin Owens 25 Oct '25

25 Oct '25

Hey Devels, Event: https://inkscape.org/cals/event/1/ Attending: Marc, Martin, Elendil, pbs Next Meeting: https://inkscape.org/cals/event/64/ Martin asked everyone to fill out the developer survey. We first talked about adjusting the developer meeting times now that we have lots of new developer and people with new schedules. Tav was to create a survey for possible new times, Marc will follow up with Tav to get that poll. We talked about the data access API, Martin asked Ryan to do a DX (Developer Experience) test of the new API adding a dithering filter. Also added was a color transformation filter and Martin is looking forward to his working being code reviewed. Martin has added a multi page SVG update moving inkscape's custom inkscape:page element to the SVG2 view element. The attributes are pretty much the same. An update mechanism is added and lots of tests for various things. Testing with Firefox and Chrome this work should allow multi page support in other SVG viewers and editors. Marc is working on the translations repository. Finished migrating to weblate and moving the po directory with a submodule and clearing out all the merge requests outstanding. Creating CI jobs for updating and is weighing up an automated or manual process. Now to figure out if we need to remove the CI translator checker, Martin agrees. Elendil has been working on a regression with the version attribute which appears to be missing from the svg files that we are currently exporting from 1.5. Marc wants to talk about XSLT export hidden objects and the way the extensions don't current handle XSLT effect extensions, Marc will write this code to put it in. Martin talked about adding such a feature directly to the export dialog since it's already doing much of the same work for hiding objects off the page. The code already exists. Pbs has touched the recolor artwork google summer of code. Looked into a new packaging system called "Sharon", this might let us deliver AppImage type builds with Vulcan support. Martin and Pbs talked about the color access API and some of the direct and compile time problems between that and the color API itself. Martin answered questions and requested code review as the primary help needed. We talked about some of the llm influenced merge requests and how to handle people who don't even talk without using an LLM. Philip asked Marc about heap and symbol problems, and if plugins (compiled ones) have ever worked in windows because the issues if you need to access things outside of the inkscape binary. There was a discussion about how the extensions and various plugins should work and what is known out in the wild. We talked about the release of 1.4.3 and the focus on bug fixing. Martin would like more developers to consier working on things in the milestone to get it as good as possible. Marc wanted to know about capypdf packaging and what kind of packaging we should expect to see for the 1.5 release. Martin says we're likely to need an up to date version and Marc says he'll make a Debian package and make sure it's available mostly for the PPA. We talked about various packaging strategies. Thanks everyone for coming to this week's meeting. Next one is Sunday 2nd November. Best Regards, Martin Owens

1 0

Inkscape Developer Survey 2025
by Martin Owens 24 Oct '25

24 Oct '25

Dear Developers, As a follow up from last year's developer survey, could I get all developers to fill out this year's survey and your experiences with Inkscape as a programmer this year. The goal is to gage how easily it is to contribute, people's thoughts and the ongoing improvements in onboarding and making this work enjoyable: https://forms.gle/HPggfawPou2aHS6i6 Thanks everyone. Best Regards, Martin \owens

1 1

Developer Meeting Notes: Oct 17th 2025
by Martin Owens 17 Oct '25

17 Oct '25

Hey Developers! Event: https://inkscape.org/cals/event/64/ Attending: Mikekov, Martin, Jabier, Willy, Tav Next Meeting: https://inkscape.org/cals/event/1/ We kick off with Willy who has two open open merge requests for the developer team to consider. One is the rotation snapping which is ready to be re-reviewed. It uses a regulr Spin Button instead of a Math Spin Button so it's got some regressions still. The second is a 1.4.x patch for the toolbars so the buttons dispear one by one instead of chunking entire groups at a time. We talked about the 1.4.3 issues and the open issues and when we can schedule the release. We suggest a December release with a project wide request to focus on fixing some of the remaining issues for 1.4.3 so make it a really stable release before 1.5 comes out. We talked about the 1.5 release and Martin's idea for releasing 1.5, 1.5.1 and then calling the 1.5.2 Inkscape's 2.0. This is in an attempt to promote stability an give users the time to field trial some of the new functionality before we make a big splash with the 2.0. We talked about freeze policy. Mikekov went through some of the remaining open issues in Gtk4. Martin asked if our Gtk upstream needs help or not or if things are progressing organically at the right speed for our release on macOS, windows etc. We talked about the dificulty of getting program admins who can organise projects that pay people to work on different aspects of our release issues. And our recruitment of volunteers that tends to depend heavily on programmers instead of people who might be more stilled in admin releated organising. Mikekov helped with the Dash2 issues, and doing merge requests. His currently thinking about the preferences dialog. He's been medidating on how to clarify the preferences to reduce the amount of duplicate code and depend on the glade file directly. There's a couple of routes to having preferences paths defined in glade files and widgets constructed with simple APIs, there's a refactoring pathway for how we would get there too. But the ultimate aim would be to remove most of the code until only loading of the glade file remains. We talked about how Gtk custom widgets work so we don't need to load each widget by Id. Tav has been working on color in CSS issues with export. He wants to have a meeting with Martin to talk about Color further. He's looking into the problem of integer artefacts and generating example files in 16bit to test how browsers are currently dealing with the older limitations and if they have been overcome. Some of these artefacts are actically used by filter designers as inputs to produce iteresting results. Report on Bug Accelerator Program, Tav has a few hours left. Martin talked about his engine improvements and walked through the entire plan for filters, color, memory surface management and the stepping stones that are being worked on to get everything in place for CMYK support. Tav and Martin talked about various details in support and what it means for SVG. Tav says that the attendance at the late meeting is very poor. Should we redefine a new time for that meeting so it's easier for other contributors. Martin asked Tav to make a survay for all the new contributors about their availability. Thanks to everyone who was able to come to this week's meeting. Best Regards, Martin Owens

1 0

Inkscape Developer Meeting, Oct 1st 2025
by Martin Owens 01 Oct '25

01 Oct '25

Hey Developers, Event: https://inkscape.org/cals/event/64/ Attending: Martin, Youstena, René, Tav Next Meeting: https://inkscape.org/cals/event/1/ Martin starts off with a quick introduction, and a short update on the website updates and the downtime people may have experienced. René looking into windows CI, it felt so bad that he felt he had to work on it. The goal is to make it faster and usable as being so slow sucks the joy out of everythig. The 7z archive builder is now running on a persistant runner which René said he would never run one again, but it was required to make it much much faster. The mechanism for depedancies was switched from 7z packaged, to a Microsoft based format which has advantages which can mounted and doesn't need to be 'extracted' as well as being more windows native. There's a bit of work more to do which is how easily it is to build depedencies, moving the config back into the main CI builder itself. Martin Martin talked abut Gtk and the need to keep the version we are building with and targeting for 1.5 will have to be a future version because of the known bugs that will have to be fixed in time for release. Martin's work on filter rendering and unit testing and is currently working on Light sources after completing the ConvolveMatrix work last week. A lot of tricky decisions will have to be made about interpolating in other color spaces but the new code will give us the flexibility to choose. Some backwards compatability will be needed for Integer calculations too. Tav has been working on CSS Color parsing and some of the found bugs, checking over our support introduced by Martin in 1.5. The Lch color conversion was wrong and has now been fixed, case insenstivity, and a range issue on Lch. Tav has questions about the color picker, we're currntly using Luv in the color picker. Martin and Tav had talk about color, rendering, document color space. Talking about how to achieve backwards compatibility and various other issues between Inkscape and SVG for color support. Youstena is a student from Egypt who is interesting in contributing to open source and introduced themselves. We asked around if anyone still needed to claim from the SFC, Tav was waiting on something but he'd put it in later too. We may want to make sure per-deim and travel between events where there is more than one event happening should be in the next vote. Thanks everyone for coming!

1 0

Inkscape Developer Meeting, Sept 15th 2025
by Martin Owens 15 Sep '25

15 Sep '25

Hey everyone, Event: https://inkscape.org/cals/event/1/ Attending: Mikekov, Tav, Martin Mikekov has been working on some beautifcation projects, various things like the roller, gradient editor etc. We collectively talked about the failures at the SFC regarding reimbursements and people who are still waiting on reimbursement for items months and months ago. Tav would like to get into fixing the LPE dialog and converting polylines and lines to paths. Martin is working on filter mechanics involving a new cairo surface image access class with unit testing. We reviewed some merge requests. Short meeting this week, Thanks everyone.

1 0

Forbidden attributes in per-tool and last-used styles
by Henry Wong 15 Sep '25

15 Sep '25

Hello Inkscape devs, I'm looking through the code that sets/reads desktop and tool styles (sp_desktop_set_style, sp_desktop_get_style, etc.), and have some questions on some of the attribute filtering that happens. As far as I can tell, there are two kinds of styles (except the 3dbox oddity): * The "last used style": /desktop/style * A per-tool style: /tool/<tool_path>/style For these styles, certain CSS properties are forbidden and are filtered out (e.g,. "shape-inside", "filter", "stop-opacity"). Filtering happens both when reading from the style and writing to the style. For the filters when reading (in sp_desktop_apply_style_tool <https://gitlab.com/inkscape/inkscape/-/blob/master/src/desktop-style.cpp?re…>), the list of forbidden attributes are different for the global style and per-tool style. (More attributes are forbidden for the global style than the per-tool style). There is a different list of filters when writing the styles (sp_css_attr_unset_blacklist <https://gitlab.com/inkscape/inkscape/-/blob/master/src/style.cpp?ref_type=h…>, sp_css_attr_unset_uris <https://gitlab.com/inkscape/inkscape/-/blob/master/src/style.cpp?ref_type=h…>). The rules differ between the global and per-tool style, AND the rules differ from the ones applied when reading the styles. (More attributes are forbidden for the per-tool style than the global style?) Is there a reason the rules ended up this complicated? (Especially the part where the attributes that are writable to the style differ from the set of attributes allowed to be read back.) I'm wondering whether they can be simplified to something like: * Some set of attributes are forbidden from all default styles. Apply the same filter for both reading and writing. Or * Some set of attributes are forbidden for all default styles, and a superset is forbidden for the global last-used style. But the same filters are used for both reading and writing.

2 1