Skip to content

Backports for 3.1.2#2080

Open
cameronwhite wants to merge 8 commits intorelease-3.1from
backport/3.1.2
Open

Backports for 3.1.2#2080
cameronwhite wants to merge 8 commits intorelease-3.1from
backport/3.1.2

Conversation

@cameronwhite
Copy link
Copy Markdown
Member

@cameronwhite cameronwhite commented Mar 29, 2026

The changes here largely consisted of resaving in Inkscape after applying its path simplification tool, and eliminating global scales and odd view boxes.

Bug: #1950
(cherry picked from commit e26f79c)
Previously the list items were entirely rebuilt in order to update the UI. This was the root cause of the crash in the referenced bug report, because updating the current layer after a right click could finalize tools and rebuild the widgets (causing the popover menu to be attached to a widget that was about to be removed)

- Add an event to signal that the layer item has changed, allowing the widget to update itself. Using GObject properties and bindings is the "proper" way to update the widget, but currently we can't add properties for a managed subclass

- Avoid unnecessary calls to SetCurrentUserLayer if our layer is already current. This avoids some extra updates from selection change events.

Bug: #1940
(cherry picked from commit 438bd26)
@cameronwhite cameronwhite changed the base branch from master to release-3.1 March 29, 2026 15:50
@pedropaulosuzuki
Copy link
Copy Markdown
Contributor

#2041 is also a good candidate for 3.1.2.
#2007 is also fine to backport.
Also #1935.

@cameronwhite
Copy link
Copy Markdown
Member Author

Yeah those first two look fine to add. I'll look more closely at #1935 but might leave that for 3.2 - IIRC it was only a partial fix and all of the add-ins also need to be updated to fix how they translate those strings.

@pedropaulosuzuki
Copy link
Copy Markdown
Contributor

Yeah those first two look fine to add. I'll look more closely at #1935 but might leave that for 3.2 - IIRC it was only a partial fix and all of the add-ins also need to be updated to fix how they translate those strings.

Oh yeah, I meant the ColorPickerDialog change, since we already use Translations.GetString () when calling the constructor. But you got a point, maybe some addon doesn't and then it might break.

@cameronwhite
Copy link
Copy Markdown
Member Author

Oh yeah, I meant the ColorPickerDialog change, since we already use Translations.GetString () when calling the constructor. But you got a point, maybe some addon doesn't and then it might break.

Yeah I think skipping that one is best - the ColorPickerDialog change was more of a code cleanup but isn't really fixing an actual bug (attempting to translate an already-translated string is a no-op)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants