Alvin Penner wrote
> just for curiosity, is the Fill & Stroke dialog loading adversely
> affected by this?
Could you clarify? I don't really understand this question and how it relates to the XML Editor dialog.
Possibly (but I haven't verified yet by testing with archived builds) the internal refactoring of the XML Editor (replacing GtkCTree with GtkTreeView, see bug #903676) is partially responsible for the performance regression when opening the XML Editor if the current file has a huge amount of child objects inside one node of the XML tree (e.g. in a layer, or a group).
IIRC some of the drop-down lists in the Fill&Stroke dialog had to be refactored too to prepare the migration to GTK3 (e.g. replacing the deprecated GtkOptionMenu widget with GtkComboBox - bug #903671, bug #943225) - if you see performance regressions with 'Fill&Stroke', I would propose to file a separate report about it, with sample files and steps to reproduce.
Alvin Penner wrote
> just for curiosity, is the Fill & Stroke dialog loading adversely
> affected by this?
Could you clarify? I don't really understand this question and how it relates to the XML Editor dialog.
Possibly (but I haven't verified yet by testing with archived builds) the internal refactoring of the XML Editor (replacing GtkCTree with GtkTreeView, see bug #903676) is partially responsible for the performance regression when opening the XML Editor if the current file has a huge amount of child objects inside one node of the XML tree (e.g. in a layer, or a group).
IIRC some of the drop-down lists in the Fill&Stroke dialog had to be refactored too to prepare the migration to GTK3 (e.g. replacing the deprecated GtkOptionMenu widget with GtkComboBox - bug #903671, bug #943225) - if you see performance regressions with 'Fill&Stroke', I would propose to file a separate report about it, with sample files and steps to reproduce.