VOTE: Remaining funds in the Bugfix Accelerator Program 2023
by Jonathan Neuhauser
Dear PLC,
In the meeting with Pono on June 14*, the present PLC members have
discussed* the extension of the bugfix accelerator program, and based on
this discussion, I've created the following ballot.
*Background*
The PLC has previously allocated a total of USD 20.000 for both
contractors, but Rafael dropped out very early into his contract. On the
other hand, Martin has made huge efforts to get the 1.3 release as
smooth as possible, fixing - if my stats are correct - 52 issues within
the contract, including 2 blockers and 10 crashes. (You can see the
progress over time on this page:
https://gitlab.com/groups/inkscape/-/milestones/11#tab-issues)
With this vote, I propose to repurpose the funds that have already been
reserved for the Bugfix accelerator program for a contract extension for
Martin so that he can fix issues at the project's discretion for the
bugfix releases of the 1.3.x series.
This is based on the understanding that the contract is not intended to
pay for Inkscape development per se, but for the project's ability to
decide which bugs the contractor work will work on. This includes issues
outside of the contractors "comfort zone", as was the case with the
already-fixed issues.
Regarding a possible repetition of the bugfix accelerator next year: a
poll will be conducted to find out how uses perceive our recent efforts
to spend the project's resources, and where they would like to see our
resources go. Much like the internal GTK contractor position, we would
properly advertise the job posting on the mailing list, and have an open
call for applications (from within the active developers).
* As per the SFC Conflict of Interest policy, Martin was not present
during this part of the meeting. He has stated that he would be available.
*Ballot*:
a. Extend Martin's contract under the terms of the Bugfix Accelerator
Program 2023. The contract volume will not exceed the remaining budget
allocated to the Bugfix Accelerator Program 2023.
b. Do not extend the Bugfix Accelerator Program 2023, the remaining
funds are deallocated.
c. Other: _____
Best regards,
Jonathan
2 months, 2 weeks
Developer Meeting Notes: June 22nd 2023
by doctormo＠gmail.com
Dear Developer Team.
Date: 22nd June 2023
Event: https://inkscape.org/cals/event/1/
Attending: Martin, René, Sanodhya, Tav, Mikekov, Nicco
Next Meeting: 30th June 2023
Since last week's announcement from René that he was taking over the
windows CI building process he wanted to walk us through the CI builds
and demonstrating the builder on GitLab. There are two windows items in
the build system list, a build step which builds all of the binary
objects and then three parallel distribution steps for the nsis, 7zip
and exe installer objects.
Before this work the windows CI was the same as macOS, and it was
disabled for people outside of the inkscape project itself. But now
it's open to everyone who creates branches of inkscape.
René asks where the best place to put documentation about the new
system. The change in the deps collection means changing
msys2installdeps.sh no longer changes the deps that the CI builder will
use. Martin recommended putting breadcrumb links in the main repository
and full documentation in the new windows CI deps repository to explain
how everything works.
Tav has worked on a couple of things. Replaced context menus with new
Gtk4 stuff and it's been a little frustrating with things that are
different. There's a units context menu on rulers, but it has one
problem, it's using actions which are radio buttons and when you pop up
a context menu with radio buttons it doesn't automatically pop down.
We'll leave it like this for now.
Everything has to be converted to using Gio menus and that will take
some time. One context menu was removed from the svg font dialog which
wasn't very discoverable.
Next a drop down issue which was presented by mikekov where we have
multiple columns and Tav looked into the new Gtk DropDown Gtk4 object
and we can replace the Listview inside it with a GridView object.
There's some fragility which might prevent us from replacing ComboBoxes
correctly. There's a ListItem disconnection problem that he's trying to
fix. The Interactive Gtk debugger is a god send for this work.
The new Gtk4 expert starts on the 1st of the month.
Nicco, trying to get into the work again and it's working out well. Has
been working on parsing and doing a pair programming session with
Jonathan and now have a complete raster support.
Jonathan did some extensions refactoring trying to change the internal
data structures for paths to improve the performance with numpy
especially for large paths but keeping the API the same.
Mikekov requests a fix to one of the extensions, the layout extensions
needs one line added to fix missing deps problems. Martin says this
extension should be moved from an effect extension to a template
extension to prevent the crash and be more applicable. Otherwise he's
been playing with grids, the new modular grid which is quite popular as
a new feature on social media.
Martin has been working on improving the shape builder tool with new
semi-transparent canvas options controllable with a slider and a
working shape builder fracturing process for raster images. These are
in heavy draft and aren't ready for a merge request.
Sanidhya has been working on their GSoC project.
Pono is setting up a weekly meeting, but the details are yet to be
confirmed. Likely after the SFC's conference.
Martin will be in Barcelona next week at PenpotFest talking about
Editable SVG. Jonathan is charged with running the next meeting, but it
might be a quiet social if folk are unavailable.
This week's group task was going through old merge requests; we looked
at five WIP requests which are now old and possibly not useful. One was
assigned to Martin to review and the rest were closed.
Thanks everyone for coming. Hope everyone is having a great summer.
Best Regards, Martin Owens
3 months
Developer meeting notes for June 14th 2023
by Martin Owens
Hi everyone,
Date: Wednesday June 14th 2023
Attending: Martin, René, Mikekov, Nicco, Tav, Jonathan, Julia
Johannesen
Next Meeting: Thursday June 22nd 2023
Tav has been investigating color management as well as all the Gtk4
work. Tav, showed us a Firefox bug that doesn't apply the profile
correctly, using the Red to Green profile on the screen showed only img
tags were flipped. But the rest of the web page's colors are not
flipped. Martin suggest that if the ICC profile is applied twice then
you would get a complete inversion in Firefox showing normal colors.
This may or may not be the issue in Firefox, but it brings us to
Inkscape. Double correction may effect us in Inkscape when we set a
screen profile. Between wayland, x11, win32, osx and how Inkscape
transforms it's own canvas for rendering. Pulling in ICC profiles
automatically from the screen seems like the wrong approach anyway
since the screen should already be color corrected anyway and almost
guarantees a double conversion.
Tav would like us to eventually end up with multiple monitor support in
our configuration settings and allow per monitor ICC profiles. But only
manually. Some monitor features are only supported in Wayland, so x11
may not detect the monitor the app is on correctly, Tav is still
researching the issues.
Martin wanted to talk about a simplified story of color management to
help himself and other developers understand what it is color
management is for, and hopefully allow us to know the terms. He says at
the moment he imagines three basic sections of color management in
Inkscape. The screen Profile which is typically in RGB changes the
canvas rendering, The Device Profile which is used for PDF output (when
we support that) and showing out of gamut errors on the screen and the
individual Color Selector profiles which aren't anything to do with
either displaying colors and are only sometimes important for printing.
Their first job is to allow the user to select colors within the color
space, say selecting a CMYK color profile would allow the user to
select a CMYK color reliably. The second function of individual color
profiles is to select spot colors and unique inks, foils, etc. this
information IS passed onto PDF output, but is also important to let the
user select for example how much of that ink to show for example.
Tav says everyone is confused about color management online, not just
in Inkscape. So it's important for us to understand the whole system
and hopefully write some documentation about it.
René is assuming control of the windows CI builder. The last
contributor who was interested was a long time ago, so René is taking
control of it. For a first step he's taken all the tutorials, guides
and all the things we tell users about how to do things for windows.
This is used in René's new GitHub account which builds Inkscape using
the msys2 on the GitHub CI builders. GitHub was used because the
machines are more powerful and are set up is better. For example using
ccache and take a lot less time to run and even then it's 20 minutes
for each correction.
A new project has been created in GitLab which collects all the deps
into an archive so we have a mechanism to counteract the rolling
release model in msys2 which causes us a lot of rolling pain. Pinning
the versions in msys to make the builds more dependable during
development processes. Martin asked that this new project be moved to
the deps group in GitLab. René's GitLab now has a new build step which
is being tested for a few weeks to get used to it. This should fix the
hacky setup we currently have with rerunning builds when they quit half
way through. We should end up with two separate jobs. Estimated time
frame for improvements is between 3 and 6 months depending on how
things go.
Jonathan thanks René for taking responsibility for the windows builds
and is wondering about how this effects Gtk4, which allows us to build
with mvs c++ native compiler which should be much faster than msys2. He
tried it with stock Gtk4 apps. Julia Jonannesen confirmed that she had
also tried the Gtk4 windows compile and got it to work.
Mikekov has been working on translations and improving the polish
translations but worked on some things for templates. Martin thanked
him for focusing on fixing the templating translations.
Nicco is getting back into the work schedule after taking a break and
is coming to the end of the contract and has only a week or two of work
left. He's focusing on documentation and wrapping up where the project
has finally ended up. We'll talk about a review meeting soon.
Martin, after taking a week off, has been working on a draft feature
that allows extensions authors to add pre-processing actions which take
the svg and change it, or augment it with information only inkscape
knows about. Like bounding boxes, text paths. As well as refactoring
the svg2 to svg1.1 compatibility code which are all converted into
actions. Also been working on tidying up remaining issues and focusing
on bugs reported by his patreons for the 1.3 release.
--------------
The team spent the last ten minutes of the meeting looking at merge
requests. First on the back-port proposed requests and second on some
older WIP requests which are now no longer marked as draft. These are
being closed if they are very old, but can be re-opened if needed.
Thanks for coming everyone!
Best Regards, Martin Owens
3 months, 1 week
Developer meeting notes, June 06 2023
by Jonathan Neuhauser
Hi everyone,
Meeting: Tue June 06 2023
Next meeting: Wed June 14
Attending: Tav, Nicco, Rene, PBS, Jonathan, Marc, MikeKov, KrIr17
*String freeze for 1.3*
Marc has backported relevant commits to 1.3.x. Extensions are up to date
in both branches.
No objections to string freeze = now.
We've checked the backlog together, no more MRs with backport:proposed
that contain string changes.
*Vectors update/ Release planning*: Usually 6 week window for
translations -> release around July 23rd at Vector's discretion
Tarball needs to be ready ~ July 14.
Testing completeness of packages? -> testing script by Nathan
Release video: Lazur is doing something
Release candidate: early July(no more non-obvious fixes after that)
Windows 7 support has been dropped by MSYS2, so Inkscape 1.3 will
officially not work on Windows 7.
*Discussion re: po/pot files*
Translators are supposed to use the pot file from the pipeline, but some
are instead using (outdated) po files from the repository.
- Should we update them? ~5m LOC change. Maren supports it. [done]
- How are other projects doing that? -> some are using weblate, which
(at least previously) doesn't like big POT files. Nicco used transifex
(free for open source)
- Could be a student project to refactor the way we organize translations.
*René *
MacOS ARM test failures in 1.3 branch? There is a problem on the Gitlab
side, which affects the file structure. Moved the pipeline back to our
own runner.
Struggling to find time to re-release 1.2.2 including the Ventura fixes.
The Alpha/Beta are already Ventura-compatible.
Has not bought the new Apple developer certificate yet, will do so later
this month.
*Jonathan*
AI Extension:work on importing text+ code for the different coordinate
systems seems to be mature
*Nicco*
Progress a bit slow at the moment, but the roadmap is clear. Some work
on live shapes / rectangles.
Checks again with SFC for April payment.
*PBS*
Added coverage support to 2geom. Currently 47% coverage.
Trying to join the GKT4 migration effort, e.g. dialogs + mjakemans event
controller branch. Few minor issues remain, e.g. double-click to select text
Why is modal dialogs not available in GTK4? They have deprecated it in
favor of gtk::Window and AlertDialog (4.10+). Both of them can be made
modal. [+ additional discussion about the event loop, other GKT4 MRs]
Clips / Mask: We treat it the same. Conceptually, clipping is a vector
operation and masking a pixel operation, and in the spec, different
child elements are allowed. Needs a little bit of rewriting.
Backport MR with cache fixes? Can only break what was already broken ->
Marc decides.
*Tav*
Most things on the list "before the switch" to GTK4 are done. Some don't
make sense to do before, some "at the time of switch" can already be
done now.
*Mike*
Symbols ID fix ready to go. (!5363) - some discussion ensued.
See you next week!
Jonathan
3 months, 2 weeks
Vote: Wilber Week
by Martin Owens
Dear PLC,
The Gimp project has invited us to participate in their Wilber Week¹ at
the Blender HQ in Amsterdam. The main subject they'd like to talk to us
about is coordination between free software graphics tools. This might
be useful to us since we haven't had any Libre Graphics events for a
number of years.
Various people who are invested in this topic were asked if they could
and if they wanted to go². Marc and Chris Rogers were interested. Marc
is organising himself and needs no extra funding, but Chris would like
the travel expenses and some per-diem for the trip. Chris uses all of
these tools in a professional capacity is is very aware of the
challenges of coordinating them, making him a good candidate.
I've split these into two votes:
[1: Travel Expenses for Chris]
(a) Allocate $260 for travel expenses
(b) Do not allocate
[2: Per-diem Expenses for Chris and/or Marc]
(a) Allocate SFC's normal per-diem amount³
(b) Do not allocate
(c) Something else
Thanks everyone.
Best Regards, Martin Owens
¹ Wilber week url is private, please request url for their internal
frama pad notes on the event if you need it
² I was originally asked to go, but it's way too expensive to fly from
the USA so I deferred to other members who are physically closer.
³ SFC Travel policy
https://sfconservancy.org/projects/policies/conservancy-travel-policy.html
3 months, 2 weeks