Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
1. Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+) 2. Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like") 3. Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD" 4. Make it easier for "non-programmers" to create and reorganise custom toolbars and dialogs 5. Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
1. By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code) 2. By activating the action (using its name) from a command-line interface (replacing some of our verbs code) 3. By attaching the action's name to elements in a customised GUI file 4. From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
Alex,
This is very exciting stuff and although I am a poor C++ programmer I would like to do what I can to help the process along - I will checkout the branches later and see how I go.
Many thanks for all your work!
Regards,
Phil.
On 2018-03-31 11:03, Alex Valavanis wrote:
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event
- it's so much easier to deal with tricky design challenges and
project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
- Allow Inkscape to run on machines with future versions of the Gtk+
library (Gtk 4+)
- Provide much better separation between the behaviour and user
interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like")
- Make it much easier to create new "flavours" of the Inkscape user
interface - for example, an "Inkscape for Kids" or "Inkscape CAD"
- Make it easier for "non-programmers" to create and reorganise
custom toolbars and dialogs
- Allow us to remove a lot of older "C" code that is very difficult
for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
- By attaching the action's name to a GUI element in the C++ code
(replacing our SPAction/GtkAction code)
- By activating the action (using its name) from a command-line
interface (replacing some of our verbs code)
- By attaching the action's name to elements in a customised GUI file
- From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
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
Dear All,
The Boston Hackfest 2018 has finished and I'd like to thank everyone who was able to join me here in Boston and especially I'd like to greatly thank RedHat for hosting us and Máirín Duffy for stepping in after MIT.
My work this week has been fairly basic.
= Website =
== Where we are ==
The Inkscape website has some useful features for delivering downloads, news, community, education and so on.
== What's the problem ==
a. The website is slow, it's been slow for a while and the poor machine was just beaten by our relentless users. No matter what kind of caching I added, it just couldn't make up for lack of resources.
b. Developers have also been struggling to get their local development working.
c. The website also has very old content layout which originated in the very old pre-django website and hasn't really been updated in ten years.
d. What it also needs is some new designs for the 'brochure' site.
== What we're doing ==
a. For the website slowness I decided to ask OSUOSL for more resources. They delivered this week and gave us double the CPU and Memory. The machine is now much more responsive.
b. We've created a new server inskcape.rocks which will host a per- user website for development. Developers will be allowed to log in via ssh and do direct development on website code. For example tonya should be able to access her website modifications at tonya.inkscape.rocks.
c. We decided that we needed to find a person who would be able to be the website's curator. A person to think carefully about the pages, their content and not someone who was either worries about the look and feel or the programming of the site.
d. Ryan has kindly been working on this week and I'm sure he will step in to talk about. The rest of the site's design will come later with some great designs from jabier, Mihaela and others.
== What we need ==
a. Anyone who knows systems administration for websites and databases, the web server can't even reboot properly as it won't auto start ngninx or the django website. A specialist doesn't have to be totally responsible but their super powers would be immensely valuable.
b. I'm taking care of this, so hopefully we'll be ready to test it and get anyone interested int he website set up.
c. Any person who can read and write English. No technical skills and it would be better to have someone who wasn't involved with any other parts of the project. In your own time, work to do content design and writing.
d. Less critique, I've been disapointed by the lack of careful constructive feedback regarding the new brochure site. So if you'd like to be involved, please be kindly and peacable.
= Extensions =
== Where are we ==
We currently include a ton of python (and some other) extensions in the main master branch of the main repository. These are built into packages and shipped with Inkscape.
== What's the problem? ==
Extensions are hard to maintain in their current form, lacking many tests, being incompatible with python3 and having a code quality rating of -6 out of 10 (astonishingly bad python) this isn't a shock as the extensions have been a common entry for non-developers and have had no real leadership, code quality checking or processes for testing or requirements for inclusion and dependency checking.
== What we're doing ==
Extensions are separated out into their own project branch. They'll generate their own policy for quality, testing regime and community network.
We're also upgrading extensions to work with python3 and refactoring the shared code into an extensive inkex module.
The goal is to include extensions 1.0 into Inkscape 1.0 and leave future features for Inkscape 1.1
We should also start to use the separate issues tracker to report issues with extensions. But we need to bundle this with the greater migration from launchpad.
== What are we not doing ==
Features which won't be considered because of their destabilising effects but which we talked about at the hackfest will be:
* Improving the Inkscape to script API (dbus, pipe, msg etc) * Adding new inx widget types (file browse etc) * Replacing inkex common features with a lib2geom python wrapper * Removing extensions that call back out to Inkscape to perform actions * Alternative modes, such as directory export, verb scripts and templating.
== What we need ==
We need python developers who can write tests. So many of the extensions need actual and precise tests, including inkex.
We need the original developers to document the code some so we know what functions do. Especially common ones.
We need testers and especially users of extensions to test the refactored versions to ensure they still work and to report issues.
= Other things =
We talked at the hackfest about multi page support and have put together a pretty decent design (thanks Alex for super good ideas!) but this is a feature which will have to wait for Inkscape 1.1 even if we had a person to code the design today.
I worked a little bit on cleaning the layers dialog, it's UI is a bit of a mess (code wise) and should be made clearer what it can do. (i.e hiding layers)
We worked on merging in useful parts of the rogue MacOSX Quartz build on github. The keyboard map was pretty much all we could do without a Mac to test the build and with that fork being based on the older build system many modifications make no sense. So the project is moribound.
Thanks again everyone! sorry if I missed any of the amazing topics we talked about!
Best Regards, Martin Owens
Thanks for the overview of your work at Hackfest, Martin!
I have 3 questions, for clarification, about the Website > What we need, section.
You said:
" d. Less critique, I've been disapointed by the lack of careful constructive feedback regarding the new brochure site. So if you'd like to be involved, please be kindly and peacable."
1 -- What is "the new brochure site"?? I've never even heard of it -- not only related to the Inkscape project, but in general ( -- a search for "brochure site" did not turn up much.) Will that be in addition to the main website, or replace the current website?
You said:
"c. Any person who can read and write English. No technical skills and it would be better to have someone who wasn't involved with any other parts of the project. In your own time, work to do content design and writing."
2 -- When you say it would be better if people who do this aren't involved in other parts of the project, do you mean that they need to have plenty of time to devote only to this?
Because it seems like people who are already involved might be more ready to jump right in, and need less of an introduction, or possibly even less hand-holding (since you're talking about people without technical skills).
Or else is there some other reason why you want people who aren't already involved?
While I am already involved, and my time is pretty well booked, I could probably handle bits and pieces, now and then. Or maybe I could help by answering questions for new "non-technical" helpers, and getting them more oriented to the project?
All best, brynn
-----Original Message----- From: Martin Owens Sent: Friday, March 30, 2018 10:56 PM To: Inkscape Devel List Subject: Re: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
Dear All,
The Boston Hackfest 2018 has finished and I'd like to thank everyone who was able to join me here in Boston and especially I'd like to greatly thank RedHat for hosting us and Máirín Duffy for stepping in after MIT.
My work this week has been fairly basic.
= Website =
== Where we are ==
The Inkscape website has some useful features for delivering downloads, news, community, education and so on.
== What's the problem ==
a. The website is slow, it's been slow for a while and the poor machine was just beaten by our relentless users. No matter what kind of caching I added, it just couldn't make up for lack of resources.
b. Developers have also been struggling to get their local development working.
c. The website also has very old content layout which originated in the very old pre-django website and hasn't really been updated in ten years.
d. What it also needs is some new designs for the 'brochure' site.
== What we're doing ==
a. For the website slowness I decided to ask OSUOSL for more resources. They delivered this week and gave us double the CPU and Memory. The machine is now much more responsive.
b. We've created a new server inskcape.rocks which will host a per- user website for development. Developers will be allowed to log in via ssh and do direct development on website code. For example tonya should be able to access her website modifications at tonya.inkscape.rocks.
c. We decided that we needed to find a person who would be able to be the website's curator. A person to think carefully about the pages, their content and not someone who was either worries about the look and feel or the programming of the site.
d. Ryan has kindly been working on this week and I'm sure he will step in to talk about. The rest of the site's design will come later with some great designs from jabier, Mihaela and others.
== What we need ==
a. Anyone who knows systems administration for websites and databases, the web server can't even reboot properly as it won't auto start ngninx or the django website. A specialist doesn't have to be totally responsible but their super powers would be immensely valuable.
b. I'm taking care of this, so hopefully we'll be ready to test it and get anyone interested int he website set up.
c. Any person who can read and write English. No technical skills and it would be better to have someone who wasn't involved with any other parts of the project. In your own time, work to do content design and writing.
d. Less critique, I've been disapointed by the lack of careful constructive feedback regarding the new brochure site. So if you'd like to be involved, please be kindly and peacable.
= Extensions =
== Where are we ==
We currently include a ton of python (and some other) extensions in the main master branch of the main repository. These are built into packages and shipped with Inkscape.
== What's the problem? ==
Extensions are hard to maintain in their current form, lacking many tests, being incompatible with python3 and having a code quality rating of -6 out of 10 (astonishingly bad python) this isn't a shock as the extensions have been a common entry for non-developers and have had no real leadership, code quality checking or processes for testing or requirements for inclusion and dependency checking.
== What we're doing ==
Extensions are separated out into their own project branch. They'll generate their own policy for quality, testing regime and community network.
We're also upgrading extensions to work with python3 and refactoring the shared code into an extensive inkex module.
The goal is to include extensions 1.0 into Inkscape 1.0 and leave future features for Inkscape 1.1
We should also start to use the separate issues tracker to report issues with extensions. But we need to bundle this with the greater migration from launchpad.
== What are we not doing ==
Features which won't be considered because of their destabilising effects but which we talked about at the hackfest will be:
* Improving the Inkscape to script API (dbus, pipe, msg etc) * Adding new inx widget types (file browse etc) * Replacing inkex common features with a lib2geom python wrapper * Removing extensions that call back out to Inkscape to perform actions * Alternative modes, such as directory export, verb scripts and templating.
== What we need ==
We need python developers who can write tests. So many of the extensions need actual and precise tests, including inkex.
We need the original developers to document the code some so we know what functions do. Especially common ones.
We need testers and especially users of extensions to test the refactored versions to ensure they still work and to report issues.
= Other things =
We talked at the hackfest about multi page support and have put together a pretty decent design (thanks Alex for super good ideas!) but this is a feature which will have to wait for Inkscape 1.1 even if we had a person to code the design today.
I worked a little bit on cleaning the layers dialog, it's UI is a bit of a mess (code wise) and should be made clearer what it can do. (i.e hiding layers)
We worked on merging in useful parts of the rogue MacOSX Quartz build on github. The keyboard map was pretty much all we could do without a Mac to test the build and with that fork being based on the older build system many modifications make no sense. So the project is moribound.
Thanks again everyone! sorry if I missed any of the amazing topics we talked about!
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
Thanks brynn,
Let me try and tackle these one at a time below:
1 -- What is "the new brochure site"??
It's a separate design for one or some pages which is presented to users who visit inkscape.org, it's design is focused on delivering the download and inviting people to join the community. The main difference is that it's not going to include much of the information currently on our front page and is going to focus on new users.
It'll be on our current website and won't replace any other part of it. I can't find the issue where it was being tracked (maybe Ryan will be brave enough to post it once it's ready to review fully)
2 -- When you say it would be better if people who do this aren't involved in other parts of the project, do you mean that they need to have plenty of time to devote only to this?
Yes. Content is a librarian thing, so it's very much a skill orthogonal to a lot of our existing developers and contributors.
I think the best bits and pieces work that everyone could do is just to keep your eyes open for potential new contributors and actively invite them in and see if they'd be interested in contributing in these specific ways.
Or maybe I could help by answering questions for new "non-technical" helpers, and getting them more oriented to the project
That's a great way to help!
Best Regards, Martin Owens
I was looking for an issue in gitlab about the brochure page, so I can learn more about it. Can't seem to find. Has anything been documented about it yet?
Thanks, brynn
-----Original Message----- From: Martin Owens Sent: Sunday, April 01, 2018 1:32 PM To: brynn ; Inkscape Devel List Subject: Re: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
Thanks brynn,
Let me try and tackle these one at a time below:
1 -- What is "the new brochure site"??
It's a separate design for one or some pages which is presented to users who visit inkscape.org, it's design is focused on delivering the download and inviting people to join the community. The main difference is that it's not going to include much of the information currently on our front page and is going to focus on new users.
It'll be on our current website and won't replace any other part of it. I can't find the issue where it was being tracked (maybe Ryan will be brave enough to post it once it's ready to review fully)
2 -- When you say it would be better if people who do this aren't involved in other parts of the project, do you mean that they need to have plenty of time to devote only to this?
Yes. Content is a librarian thing, so it's very much a skill orthogonal to a lot of our existing developers and contributors.
I think the best bits and pieces work that everyone could do is just to keep your eyes open for potential new contributors and actively invite them in and see if they'd be interested in contributing in these specific ways.
Or maybe I could help by answering questions for new "non-technical" helpers, and getting them more oriented to the project
That's a great way to help!
Best Regards, Martin Owens
If you want to hear and see Alex, Ryan, Bryce and Martin talk about this (and other Hackfest things), there's one more video on youtube (got posted to twitter, but not here yet, as far as I could see):
youtu.be/IqQI2Y1PR38
Maren
Am 31.03.2018 um 02:03 schrieb Alex Valavanis:
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
- Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+)
- Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like")
- Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD"
- Make it easier for "non-programmers" to create and reorganise custom toolbars and dialogs
- Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
- By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code)
- By activating the action (using its name) from a command-line interface (replacing some of our verbs code)
- By attaching the action's name to elements in a customised GUI file
- From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
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
Maren,
On 2018-03-31 23:43, Maren Hachmann wrote:
If you want to hear and see Alex, Ryan, Bryce and Martin talk about this (and other Hackfest things), there's one more video on youtube (got posted to twitter, but not here yet, as far as I could see):
youtu.be/IqQI2Y1PR38
Looks like there are only summaries for Day 1 and Day 4 so far?
P.
Maren
Am 31.03.2018 um 02:03 schrieb Alex Valavanis:
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
- Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+)
- Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like")
- Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD"
- Make it easier for "non-programmers" to create and reorganise
custom toolbars and dialogs 5. Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
- By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code)
- By activating the action (using its name) from a command-line interface (replacing some of our verbs code)
- By attaching the action's name to elements in a customised GUI
file 4. From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
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
On Sun, Apr 01, 2018 at 12:57:21AM +1100, Philip Rhoades wrote:
Maren,
On 2018-03-31 23:43, Maren Hachmann wrote:
If you want to hear and see Alex, Ryan, Bryce and Martin talk about this (and other Hackfest things), there's one more video on youtube (got posted to twitter, but not here yet, as far as I could see):
youtu.be/IqQI2Y1PR38
Looks like there are only summaries for Day 1 and Day 4 so far?
We also took a video yesterday for the Roadmap 1.0 discussion, however it's not a summary but a full capture of the work we did. I don't know how interesting it will be to watch, unless you're curious about knowing how we arrived at where we did.
Day 2 was filled with a lot of follow up from Day 1. I remember a lot of heads-down typing that day. :-)
Day 3 was our community outreach day, and we had several local 8th grade students attend for an introductory class in using Inkscape. I don't think any videos were taken that day, but there were some photos which I think may get posted if we get them cleared. We also took a group photo. The actual development work done this day was covered in the Day 4 summary.
For Day 5, apart from the Roadmap video mentioned above, instead of another status video I encouraged all of our attendees to post emails describing their work for the week (like Tav did on his directory reorganization work earlier this week), so watch for those. I would also like to ask you and others to please look for ways to extract interesting information from these emails and help spread awareness through the community (including our facebook, twitter, forums, etc.) and help gather useful feedback.
Thanks, Bryce
Am 31.03.2018 um 15:57 schrieb Philip Rhoades:
Maren,
On 2018-03-31 23:43, Maren Hachmann wrote:
If you want to hear and see Alex, Ryan, Bryce and Martin talk about this (and other Hackfest things), there's one more video on youtube (got posted to twitter, but not here yet, as far as I could see):
youtu.be/IqQI2Y1PR38
Looks like there are only summaries for Day 1 and Day 4 so far?
P.
Exactly :) I don't know if they recorded anything on the other days, I suspect they were working and discussing so much that there wasn't any energy left for doing so.
I hope everyone will get / got home safely!
Maren
Maren
Am 31.03.2018 um 02:03 schrieb Alex Valavanis:
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
1. Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+) 2. Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like") 3. Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD" 4. Make it easier for "non-programmers" to create and reorganise custom toolbars and dialogs 5. Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
1. By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code) 2. By activating the action (using its name) from a command-line interface (replacing some of our verbs code) 3. By attaching the action's name to elements in a customised GUI file 4. From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
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
Thanks for the overview, Alex! And especially thanks for making it more or less understandable by ordinary users like me :-)
I just have one question for clarification. Near the end, when you are asking for advanced users and developers for help with testing, you said:
" If you don't know how to do this, check out our developer guide."
By "developer guide", do you mean this page on the website?
https://inkscape.org/en/develop/getting-started/
Or something else?
Thanks to you, and all the hackers who worked so hard to make Inkscape even more awesome!!
All best, brynn
-----Original Message----- From: Alex Valavanis Sent: Friday, March 30, 2018 6:03 PM To: Inkscape Devel List Subject: [Inkscape-devel] Hackfest 2018: Actions and Toolbars
Hi All,
Here's a summary of my work at the Boston Hackfest.
Before I continue, I'd like to thank everyone who donated their money or time to support this Hackfest. This has been a really useful event - it's so much easier to deal with tricky design challenges and project management stuff when we can meet face to face. It has also brought together people with very diverse expertise across the project (UI, web, build, extensions, project management etc). This week, we've figured out a path to deliver long desired features (multipage support etc), roadmapped our final route to deliver Inkscape 1.0, done some great website design work, and handled some tricky code structure issues that I'll discuss in this message.
If you're able to donate some money to support Inkscape, and future Hackfests, we really appreciate this. You can find the donation link on our website: https://inkscape.org/en/support-us/hackfests/
It would also be great to get some more of the regular contributors from our wider community to join us at future events (i.e., designers, bug-team, experienced users... not just C++ developers!). The developers can learn so much more about the project by discussing it with you.
So... what have I been doing this week?
== What are Actions? ==
Basically, an "action" is a thing that Inkscape can do (e.g., flip an object horizontally), which we can identify using an ID code (e.g., "SP_VERB_OBJECT_FLIP_HORIZONTAL"). We can then hook up buttons, menu items etc to activate these actions. In this example, we would set up our Flip Horizontal button in the select-tool toolbar so that when the user clicks it, it activates the required action.
My work this week has focused on improving the way we implement actions in our code, which will
Allow Inkscape to run on machines with future versions of the Gtk+ library (Gtk 4+) Provide much better separation between the behaviour and user interface (i.e.,, separate pieces of the code will describe what Inkscape "does", and what it "looks like") Make it much easier to create new "flavours" of the Inkscape user interface - for example, an "Inkscape for Kids" or "Inkscape CAD" Make it easier for "non-programmers" to create and reorganise custom toolbars and dialogs
Allow us to remove a lot of older "C" code that is very difficult for current "C++" developers to maintain
== Where we are now? ==
In the Inkscape code, we have a mechanism called "verbs" that acts as a kind of action mechanism... it provides a way of using an ID code to look up the required commands to perform an action.
On top of this, we have another structure called SPAction that essentially hooks up a couple of signals to the verb.
Finally(ish), we use objects called GtkActions from the Gtk+ library, which let us create GUI elements (buttons etc) that we can add to our menus or toolbars that activate the required action.
We have also got a few custom sub-classes of GtkAction that let us create special kinds of tool-item that can activate actions... for example, one of these creates a spin-button (a box with a number in it, and "up/down" arrows) that can also handle units, basic arithmetic, and provides a label.
== What's the problem? ==
First, the GtkAction widget (and hence all our custom sub-classes) is deprecated and has been removed from Gtk+ 4, so we need to change. Since Inkscape 1.0 is intended as a "stable" release, we want to make it as future-proof as possible.
The main reason for this deprecation is that the GtkAction widget is a slightly weird mix of paradigms: it mixes information about how to display a tool/menu item with information about behaviour. This causes some problems... what if we wanted to run a "headless" Inkscape on a system that has no display? What if we wanted to provide several different GUI options for different kinds of user to trigger the same behaviour?
This is one of the reasons why we have the "verbs" system is in place, as it separates behaviour from the GUI. However, there is still quite a lot of code "overhead" needed if we want to hook up Inkscape's Verb behaviour to a GUI element. Essentially, it's "programmers only" territory. What if a designer wanted to add a new toolbar button to their Inkscape to handle a useful feature that is currently buried deep in a menu? What if a teacher wanted to strip out a lot of "advanced" behaviour from the interface to make it easier to introduce Inkscape to their class? At the moment, they have to edit the C++ code, and recompile it... a slow and complicated process!
== Where are we going? ==
We need to move to using GActions (a feature in the Glib/GIO library). This *only* describes the action's behaviour and provides an "activated" signal that we can trigger by simply knowing the action's name. This is completely separated from the GUI. These actions can be activated very easily from a whole range of places, for example:
By attaching the action's name to a GUI element in the C++ code (replacing our SPAction/GtkAction code)
By activating the action (using its name) from a command-line interface (replacing some of our verbs code)
By attaching the action's name to elements in a customised GUI file
From external applications, using the DBus system
Number 3 in the list provides some very exciting opportunities for future releases, as non-programmers will be able to make a customised user interface by drawing one in the Glade application. You then just attach the name of the required Inkscape action to each GUI element. Want a new button? Just edit Inkscape's user-interface file in Glade and see the changes immediately next time you start... no C++ knowledge needed!
== What have I done so far? ==
I've started working through Inkscape's toolbars, and have replaced the deprecated GtkAction-based widgets with standard widgets (buttons etc). Some of these now hook up to GAction descriptions of behaviour, while others are just based on handling GUI signals (e.g., Button::clicked).
So far, I have migrated the toolbars for the Select, Dropper and Connector toolbar, and have killed off a couple of the custom GtkAction-based widgets that were only used in these.
In the process, I have also migrated the toolbar code to C++, which should make it a little easier for the current core developers to maintain. Since all the data is now stored as C++ member variables, rather than as GObject data, we now benefit from better compile-time and run-time type-checking that will help to safeguard against errors being introduced in the code in future.
I have placed the updated toolbars in the Inkscape::UI::Toolbar namespace and made them into proper sub-classes of the Gtk::Toolbar class.
== How can you help? ==
This important refactoring project must be done before Gtk+ 4 is widely used, and represents a major change to the way that our toolbars are implemented. It represents a couple of thousand lines of code changes and will inevitably cause some regression bugs. I will need your help in thoroughly testing that all the toolbars work correcly!
All of these changes are currently in a git branch ("gtk-actions-migration") and will not be merged into the master branch until preliminary testing has been completed. In other words, this will not "mess up" your stable version of Inkscape and will never be part of the current 0.92.x release series! I intend to merge this work well in advance of the Inkscape 1.0 release, so that we have plenty of time for very thorough developer and user testing, and several preliminary bug-fix "alpha" pre-releases before the final stable release.
For the very brave: please checkout the "gtk-actions-migration" branch in git, rebuild and test. Please note that this is work-in progress. Do not use this experimental branch for your regular Inkscape drawing work!!! The Node toolbar will not work... the Select, Dropper and Connector toolbars are highly experimental; all the other toolbars are "at risk"! If you don't know how to do this, check out our developer guide.
For the quite brave: I'll merge this experimental branch into our master development branch in a few weeks once (a) I've completed the basic work, (b) I've had a good amount of feedback on the branch and know that it "works" to some extent. I'll message you again at this stage and ask everyone to help look for bugs. Again, this will only be visible to developers and users of our experimental "trunk" PPA in Ubuntu.
For the intrepid: If you're interested in helping with the code migration - message me and I'll help to divide up the tasks.
== The end ==
I hope this gives an insight into the work I've started doing this week, and will continue over the coming weeks. Thanks once again to everyone who has contributed time, money or even just attention and enthusiasm for the Hackfest.
Best wishes,
Alex Valavanis (valavanisalex)
Inkscape developer
------------------------------------------------------------------------------ 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 (7)
-
Alex Valavanis -
Bryce Harrington -
brynn -
Maren Hachmann -
Martin Owens -
Mihaela -
Philip Rhoades