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
On Thu, Jun 15, 2017, at 07:22 PM, Martin Owens wrote:
Dear developers,
I've just completed a section of work which you can find here:
...
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?
Hi,
I'll try to give it a good once-over, but might take till this weekend.
The plans to expose those for user configuration have always been around, so the general direction is good.
I'll have to take a look at recent Gtk Builder stuff, but when we had done overviews in the past it was the wrong approach. That is, it was far more like XUL and a focus on pixel-tweaking instead of a good HTML/CSS split with HTML focusing on the structure. We probably want to keep to more of a logical structure in the XML and not a physical one. (BTW, accessibility test cases help highlight issues in this arena)
Also, if I remember correctly the main reason for not having a few files exposed directly was that code crafting many of the gtk actions was not clean enough to allow for placement in different areas (e.g. vertical instead of horizontal). Following up on getting the rest of such abstract 'actions' happy-happy in UI land would probably be good at this point.
On Wed, 2017-06-21 at 08:30 -0700, Jon A. Cruz wrote:
I'll have to take a look at recent Gtk Builder stuff, but when we had done overviews in the past it was the wrong approach. That is, it was far more like XUL and a focus on pixel-tweaking instead of a good HTML/CSS split with HTML focusing on the structure. We probably want to keep to more of a logical structure in the XML and not a physical one. (BTW, accessibility test cases help highlight issues in this arena)
The advantage these days is that with a proper gtk theme css, more of the pixel tweaking would be css based anyway (it's not quite css, but it's 80% the way there).
Accessibility and translations are pretty high on the testing list though.
Best Regards, Martin Owens
participants (2)
-
Jon A. Cruz -
Martin Owens