Seems like a great idea to me. Thanks Martin!
I believe this will make it much easier to test to tweaks.
-C
On 16 Jun 2017 03:24, "Martin Owens" <doctormo@...400...> wrote:
Dear developers,
I've just completed a section of work which you can find here:
https://gitlab.com/inkscape/inkscape/merge_requests/15
I'd appreciate a good review of the code, especially for things like memory leaks which I'm particularly weak on. A second point is the removal of ifdefs, which I can't rally do with resource files, but I'm hopping it won't matter (famous last words).
I wanted to bring up to the whole community my plans going forward. You can see how I've moved the toolbar user interface XML from being compiled in, to being a file in share/ui.
The reason for this, is I want to encourage experimentation on inkscape's user interface, which we can't do at the moment without recompiling the program.
With this change, it looks for the ui files, not just in /usr/share/inkscape/ui, but also ~/.config/inkscape/ui so users can generate a set of custom files with their own toolbar buttons ordered the way that they want. It's not a lot of customisation, but it's something to get going with.
The future vision is to start pulling some of the complex cruddy widget creation code out and putting that into a meater ui file. I might start with some dialogs like the document properties dialog. These are more interesting, because they have things like signals and anyone editing them needs to be very careful.
But if we have good code that has some good error messages and such, a designer could open the ui file in glade and mess about with the widget locations, paddings and a bunch of other visual pieces.
What are all your thoughts?
Best Regards, Martin Owens
------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Looks like a good idea to me too. Might help bring the build time down a bit too if we can break more of the UI code out!
AV
On 16 June 2017 at 07:13, C R <cajhne@...400...> wrote:
Seems like a great idea to me. Thanks Martin!
I believe this will make it much easier to test to tweaks.
-C
On 16 Jun 2017 03:24, "Martin Owens" <doctormo@...400...> wrote:
Dear developers,
I've just completed a section of work which you can find here:
https://gitlab.com/inkscape/inkscape/merge_requests/15
I'd appreciate a good review of the code, especially for things like memory leaks which I'm particularly weak on. A second point is the removal of ifdefs, which I can't rally do with resource files, but I'm hopping it won't matter (famous last words).
I wanted to bring up to the whole community my plans going forward. You can see how I've moved the toolbar user interface XML from being compiled in, to being a file in share/ui.
The reason for this, is I want to encourage experimentation on inkscape's user interface, which we can't do at the moment without recompiling the program.
With this change, it looks for the ui files, not just in /usr/share/inkscape/ui, but also ~/.config/inkscape/ui so users can generate a set of custom files with their own toolbar buttons ordered the way that they want. It's not a lot of customisation, but it's something to get going with.
The future vision is to start pulling some of the complex cruddy widget creation code out and putting that into a meater ui file. I might start with some dialogs like the document properties dialog. These are more interesting, because they have things like signals and anyone editing them needs to be very careful.
But if we have good code that has some good error messages and such, a designer could open the ui file in glade and mess about with the widget locations, paddings and a bunch of other visual pieces.
What are all your thoughts?
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 21.06.2017 um 12:44 schrieb Alex Valavanis:
Might help bring the build time down a bit too if we can break more of the UI code out!
How so? Or rather, if the UI code needs time to compile won't that meant that we slow down Inkscape startup when using UI files in consequence? If the latter is the case wasting time in a one-time compilation for one person seems a lot better than slowing down every startup for every user (in which case I'd say a caching mechanism would be a minimum requirement)
Regards Eduard
Aren't the UI layouts just loaded from file when required, rather than all being part of the large binaries loaded into memory at startup? If so, I guess there shouldn't be much impact on startup time. Complex dialogs might take a bit longer to load though.
Martin - any thoughts?
AV
On 21 June 2017 at 12:05, Eduard Braun <eduard.braun2@...173...> wrote:
Am 21.06.2017 um 12:44 schrieb Alex Valavanis:
Might help bring the build time down a bit too if we can break more of the UI code out!
How so? Or rather, if the UI code needs time to compile won't that meant that we slow down Inkscape startup when using UI files in consequence? If the latter is the case wasting time in a one-time compilation for one person seems a lot better than slowing down every startup for every user (in which case I'd say a caching mechanism would be a minimum requirement)
Regards Eduard
We're regularly having requests for this on the forums (arranging icons in a custom way), so I have tried it out, too (also, I'd remove the zoom and the gradient tool from the list, and clean up many buttons in the command bar for myself if I could...).
Modifying the files in (0.92 and earlier) /usr/share/inkscape/ui currently has zero effect after compilation (although the location suggests otherwise). So, from this I deduct that they seem to be loaded from a different place.
Maren
Am 21.06.2017 um 13:18 schrieb Alex Valavanis:
Aren't the UI layouts just loaded from file when required, rather than all being part of the large binaries loaded into memory at startup? If so, I guess there shouldn't be much impact on startup time. Complex dialogs might take a bit longer to load though.
Martin - any thoughts?
AV
On 21 June 2017 at 12:05, Eduard Braun <eduard.braun2@...173...> wrote:
Am 21.06.2017 um 12:44 schrieb Alex Valavanis:
Might help bring the build time down a bit too if we can break more of the UI code out!
How so? Or rather, if the UI code needs time to compile won't that meant that we slow down Inkscape startup when using UI files in consequence? If the latter is the case wasting time in a one-time compilation for one person seems a lot better than slowing down every startup for every user (in which case I'd say a caching mechanism would be a minimum requirement)
Regards Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, 2017-06-21 at 12:18 +0100, Alex Valavanis wrote:
Aren't the UI layouts just loaded from file when required, rather than all being part of the large binaries loaded into memory at startup? If so, I guess there shouldn't be much impact on startup time. Complex dialogs might take a bit longer to load though.
Martin - any thoughts?
Between the xml files embeded and the xml files in a file, I'd say there was very little in it. Same xml parsing. There might be a small memory foot print by a few kB based on not needing to keep these xml files in memory for all time.
For using the Gtk Builder instead of native code, there'll be a small increase in start time to read in the xml, but the amount of code in some of these functions is dramatic so the main advantage is a decrease in maintenance cost and an increase in the number and types of people able to contribute meaningfully to the UI.
On Wed, 2017-06-21 at 15:46 +0200, Maren Hachmann wrote:
We're regularly having requests for this on the forums (arranging icons in a custom way), so I have tried it out, too (also, I'd remove the zoom and the gradient tool from the list, and clean up many buttons in the command bar for myself if I could...).
Maren, did you try and trunk and you couldn't get it to remove icons?
Best Regards, Martin Owens
Am 21.06.2017 um 16:57 schrieb Martin Owens:
Maren, did you try and trunk and you couldn't get it to remove icons?
- No, I tested the versions that the users used, i.e. released ones, not the latest trunk modifications.
Maren
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (5)
-
Alex Valavanis -
C R -
Eduard Braun -
Maren Hachmann -
Martin Owens