Hackfest 2018: Actions and Toolbars

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Hackfest 2018: Actions and Toolbars

Alex Valavanis-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Philip Rhoades
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  [hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

doctormo
In reply to this post by Alex Valavanis-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Inkscape - Dev mailing list
In reply to this post by Alex Valavanis-3
Hi all,

A lot of exiting things going on here. Separating the GUI from the  
functionality of Inkscape and allowing to use it as a command line tool  
sounds really cool.

Now the question that arises to me is whether that means Inkscape could be  
used as a service and output could get rendered to a client browser? That  
would allow for a wide variety of GUI's to be developed that could cater  
to specific uses. I could envision a touch version and probably a VR  
interface would be more of an option as well. Obviously the fast rendering  
with Cairo would be lost that way, but for limited use cases (for instance  
without filters) that should be fast enough I think.

Cheers,

Jelle

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Maren Hachmann
In reply to this post by Alex Valavanis-3
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
>
>  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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

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.


> 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  [hidden email]

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Bryce Harrington-3
In reply to this post by Inkscape - Dev mailing list
On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:

> Hi all,
>
> A lot of exiting things going on here. Separating the GUI from the
> functionality of Inkscape and allowing to use it as a command line tool
> sounds really cool.
>
> Now the question that arises to me is whether that means Inkscape could be
> used as a service and output could get rendered to a client browser? That
> would allow for a wide variety of GUI's to be developed that could cater to
> specific uses. I could envision a touch version and probably a VR interface
> would be more of an option as well.

I imagine there's a variety of different kinds of solutions that could
be built atop a generalized backend API.  Using it to support web-based
art seems like an interesting area of exploration.  As this is all still
much in the "hand-wavey" stage, it's hard to predict exactly what will
and won't be possible, but the overall architectural vision would seek
to suit a wide variety of "headless" uses.

A lot of work will need to be done before we can say for sure what will
and what won't be feasible to do, and we'll need to be cautious to not
get over-ambitious in our planning - better to do just a few new things
really well, than a whole bunch of different things poorly.  But, we're
all excited by the possibilities and hope others will also be
enthusiastic in joining us to make it into a reality.

> Obviously the fast rendering with Cairo would be lost that way, but
> for limited use cases (for instance without filters) that should be
> fast enough I think.

Could you elaborate?  Why would that be lost necessarily?  

Bryce

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Bryce Harrington-3
In reply to this post by Philip Rhoades
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Maren Hachmann
In reply to this post by Philip Rhoades
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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Inkscape - Dev mailing list
In reply to this post by Bryce Harrington-3
Hello Bryce,

If much of the handling of objects would be done through a command line, I  
can imagine using the browsers rendering engine to create the end result.  
Rendering SVG is something most browsers are capable of, up to certain  
limits (filters a not Edge's strong point I believe). Using SNAP or other  
javascript libraries building a GUI would be fairly straightforward. But  
with the end result being displayed in browsers I see little use for Cairo.

Cheers,

Jelle


On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington  
<[hidden email]> wrote:

> On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
>> Hi all,
>>
>> A lot of exiting things going on here. Separating the GUI from the
>> functionality of Inkscape and allowing to use it as a command line tool
>> sounds really cool.
>>
>> Now the question that arises to me is whether that means Inkscape could  
>> be
>> used as a service and output could get rendered to a client browser?  
>> That
>> would allow for a wide variety of GUI's to be developed that could  
>> cater to
>> specific uses. I could envision a touch version and probably a VR  
>> interface
>> would be more of an option as well.
>
> I imagine there's a variety of different kinds of solutions that could
> be built atop a generalized backend API.  Using it to support web-based
> art seems like an interesting area of exploration.  As this is all still
> much in the "hand-wavey" stage, it's hard to predict exactly what will
> and won't be possible, but the overall architectural vision would seek
> to suit a wide variety of "headless" uses.
>
> A lot of work will need to be done before we can say for sure what will
> and what won't be feasible to do, and we'll need to be cautious to not
> get over-ambitious in our planning - better to do just a few new things
> really well, than a whole bunch of different things poorly.  But, we're
> all excited by the possibilities and hope others will also be
> enthusiastic in joining us to make it into a reality.
>
>> Obviously the fast rendering with Cairo would be lost that way, but
>> for limited use cases (for instance without filters) that should be
>> fast enough I think.
>
> Could you elaborate?  Why would that be lost necessarily?
>
> Bryce

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Grady Broyles
The thought of a headless-inkscape makes me dizzy with the possibilities for developers to create apps to help designers with vector icon sets and UI elements and stuff and USE Inkscape under the hood..

It opens the door to tools like Sketch to be developed without having to reinvent the svg editing "wheel" as it were. 

Also I'd LOVE to automate some of my own icon-creating workflow using just BASH.  Ya know?


On Sat, Mar 31, 2018 at 10:31 AM jelle via Inkscape-devel <[hidden email]> wrote:
Hello Bryce,

If much of the handling of objects would be done through a command line, I
can imagine using the browsers rendering engine to create the end result.
Rendering SVG is something most browsers are capable of, up to certain
limits (filters a not Edge's strong point I believe). Using SNAP or other
javascript libraries building a GUI would be fairly straightforward. But
with the end result being displayed in browsers I see little use for Cairo.

Cheers,

Jelle


On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington
<[hidden email]> wrote:

> On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
>> Hi all,
>>
>> A lot of exiting things going on here. Separating the GUI from the
>> functionality of Inkscape and allowing to use it as a command line tool
>> sounds really cool.
>>
>> Now the question that arises to me is whether that means Inkscape could
>> be
>> used as a service and output could get rendered to a client browser?
>> That
>> would allow for a wide variety of GUI's to be developed that could
>> cater to
>> specific uses. I could envision a touch version and probably a VR
>> interface
>> would be more of an option as well.
>
> I imagine there's a variety of different kinds of solutions that could
> be built atop a generalized backend API.  Using it to support web-based
> art seems like an interesting area of exploration.  As this is all still
> much in the "hand-wavey" stage, it's hard to predict exactly what will
> and won't be possible, but the overall architectural vision would seek
> to suit a wide variety of "headless" uses.
>
> A lot of work will need to be done before we can say for sure what will
> and what won't be feasible to do, and we'll need to be cautious to not
> get over-ambitious in our planning - better to do just a few new things
> really well, than a whole bunch of different things poorly.  But, we're
> all excited by the possibilities and hope others will also be
> enthusiastic in joining us to make it into a reality.
>
>> Obviously the fast rendering with Cairo would be lost that way, but
>> for limited use cases (for instance without filters) that should be
>> fast enough I think.
>
> Could you elaborate?  Why would that be lost necessarily?
>
> Bryce

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

doctormo
On Sat, 2018-03-31 at 18:27 +0000, Grady Broyles wrote:
> Also I'd LOVE to automate some of my own icon-creating workflow using
> just BASH.  Ya know?

We could probably talk about that wrt extensions, ui improvements,
exporting etc.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Brynn
In reply to this post by Alex Valavanis-3
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Brynn
In reply to this post by doctormo
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Bryce Harrington-3
In reply to this post by Inkscape - Dev mailing list
On Sat, Mar 31, 2018 at 07:14:59PM +0200, jelle wrote:
> Hello Bryce,
>
> If much of the handling of objects would be done through a command line, I
> can imagine using the browsers rendering engine to create the end result.
> Rendering SVG is something most browsers are capable of, up to certain
> limits (filters a not Edge's strong point I believe). Using SNAP or other
> javascript libraries building a GUI would be fairly straightforward. But
> with the end result being displayed in browsers I see little use for Cairo.

Oh sure, that's true.  But that's what's great about SVG, it's a
standardized format that should be renderable by many different
renderers.

Thanks,
Bryce

> Cheers,
>
> Jelle
>
>
> On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington
> <[hidden email]> wrote:
>
> >On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
> >>Hi all,
> >>
> >>A lot of exiting things going on here. Separating the GUI from the
> >>functionality of Inkscape and allowing to use it as a command line tool
> >>sounds really cool.
> >>
> >>Now the question that arises to me is whether that means Inkscape could
> >>be
> >>used as a service and output could get rendered to a client browser?
> >>That
> >>would allow for a wide variety of GUI's to be developed that could cater
> >>to
> >>specific uses. I could envision a touch version and probably a VR
> >>interface
> >>would be more of an option as well.
> >
> >I imagine there's a variety of different kinds of solutions that could
> >be built atop a generalized backend API.  Using it to support web-based
> >art seems like an interesting area of exploration.  As this is all still
> >much in the "hand-wavey" stage, it's hard to predict exactly what will
> >and won't be possible, but the overall architectural vision would seek
> >to suit a wide variety of "headless" uses.
> >
> >A lot of work will need to be done before we can say for sure what will
> >and what won't be feasible to do, and we'll need to be cautious to not
> >get over-ambitious in our planning - better to do just a few new things
> >really well, than a whole bunch of different things poorly.  But, we're
> >all excited by the possibilities and hope others will also be
> >enthusiastic in joining us to make it into a reality.
> >
> >>Obviously the fast rendering with Cairo would be lost that way, but
> >>for limited use cases (for instance without filters) that should be
> >>fast enough I think.
> >
> >Could you elaborate?  Why would that be lost necessarily?
> >
> >Bryce

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

doctormo
In reply to this post by Brynn
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

mihaela.jurkovic
In reply to this post by Grady Broyles

headless-inkscape

Sooo dizzy with possibilities!


workflow using just BASH.  Ya know?

I know!

Mihaela


On 31.03.2018 20:27, Grady Broyles wrote:
The thought of a headless-inkscape makes me dizzy with the possibilities for developers to create apps to help designers with vector icon sets and UI elements and stuff and USE Inkscape under the hood..

It opens the door to tools like Sketch to be developed without having to reinvent the svg editing "wheel" as it were. 

Also I'd LOVE to automate some of my own icon-creating workflow using just BASH.  Ya know?


On Sat, Mar 31, 2018 at 10:31 AM jelle via Inkscape-devel <[hidden email]> wrote:
Hello Bryce,

If much of the handling of objects would be done through a command line, I
can imagine using the browsers rendering engine to create the end result.
Rendering SVG is something most browsers are capable of, up to certain
limits (filters a not Edge's strong point I believe). Using SNAP or other
javascript libraries building a GUI would be fairly straightforward. But
with the end result being displayed in browsers I see little use for Cairo.

Cheers,

Jelle


On Sat, 31 Mar 2018 16:22:09 +0200, Bryce Harrington
<[hidden email]> wrote:

> On Sat, Mar 31, 2018 at 12:40:59PM +0200, jelle via Inkscape-devel wrote:
>> Hi all,
>>
>> A lot of exiting things going on here. Separating the GUI from the
>> functionality of Inkscape and allowing to use it as a command line tool
>> sounds really cool.
>>
>> Now the question that arises to me is whether that means Inkscape could
>> be
>> used as a service and output could get rendered to a client browser?
>> That
>> would allow for a wide variety of GUI's to be developed that could
>> cater to
>> specific uses. I could envision a touch version and probably a VR
>> interface
>> would be more of an option as well.
>
> I imagine there's a variety of different kinds of solutions that could
> be built atop a generalized backend API.  Using it to support web-based
> art seems like an interesting area of exploration.  As this is all still
> much in the "hand-wavey" stage, it's hard to predict exactly what will
> and won't be possible, but the overall architectural vision would seek
> to suit a wide variety of "headless" uses.
>
> A lot of work will need to be done before we can say for sure what will
> and what won't be feasible to do, and we'll need to be cautious to not
> get over-ambitious in our planning - better to do just a few new things
> really well, than a whole bunch of different things poorly.  But, we're
> all excited by the possibilities and hope others will also be
> enthusiastic in joining us to make it into a reality.
>
>> Obviously the fast rendering with Cairo would be lost that way, but
>> for limited use cases (for instance without filters) that should be
>> fast enough I think.
>
> Could you elaborate?  Why would that be lost necessarily?
>
> Bryce

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

mihaela.jurkovic
In reply to this post by doctormo
 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.

 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 worried about the look and
feel or the programming of the site.

 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.

The "content layout" is an Information architecture concern. A common method to sort out web content is using card sorting. I see cards flying around in Vectors future :) This isn't a trivial task for one person, with a lot of audiences and purposes for the website it has to be collaborative and get feedback from a wide range of visitors. It also needs to conform with the overall Inkscape identity and what direction to steer more towards. SEO skills are also welcome with anything concerning web content.

Content writing usually requires lots of skills too. Writing a long tutorial is different from writing a news item, a tweet, explaining features as a marketing effort... Actually writing something up takes the least amount of time. More effort goes into editing what has been written to optimize it for voice, clarity, findability, readability, SEO friendliness, find/create images/media for the article etc. And all this after you've familiarized yourself with the topic completely, because that is the only way one can convey anything in a way that is easily digestible by the intended audience. Spewing out your thoughts into a document is only the first step in the writing process.

The content strategy part can be a separate task. I'm guessing a lot of it could come from Vectors in general, because a lot of it would come as a consequence of Vectors work. Not only what Vectors are doing at a certain point in time, but also what they notice making waves from all around the community.

Mihaela





























------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Hackfest 2018: Actions and Toolbars

Brynn
In reply to this post by doctormo
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel