Hi All,
In preparation for the Hackfest, I'd like to start looking at ways to reduce (eventually eliminate!) our use of GtkAction.
One of the main uses we currently have for them is in toolbars, where the tool widgets (buttons, spinbuttons etc) are all some kind of subclass of GtkAction, which has been removed from Gtk+ 4. This means that when the user clicks on the button, it triggers an "activate" signal, which is handled by a callback function.
My question is basically, "what's the point?" Is there any reason why we can't just use a plain old button in most cases, and just connect up the "clicked" signal instead?
If it really needs to be some kind of Action, we could migrate to the GAction API, but this may be much more difficult.
Best wishes,
Alex
On Wed, 2018-03-14 at 20:05 +0000, Alex Valavanis wrote:
Hi All, In preparation for the Hackfest, I'd like to start looking at ways to reduce (eventually eliminate!) our use of GtkAction.
One of the main uses we currently have for them is in toolbars, where the tool widgets (buttons, spinbuttons etc) are all some kind of subclass of GtkAction, which has been removed from Gtk+ 4. This means that when the user clicks on the button, it triggers an "activate" signal, which is handled by a callback function.
GtkActions have two modes: toolbar and menu. When a toolbar is too short it automatically switches to menu mode, accessed by the triangle at the left of the toolbar.
My question is basically, "what's the point?" Is there any reason why we can't just use a plain old button in most cases, and just connect up the "clicked" signal instead?
If it really needs to be some kind of Action, we could migrate to the GAction API, but this may be much more difficult.
I've done quite a bit of investigation of GActions. I think they are a much more useful than GtkActions. They are not bound to GUI elements like GtkActions. The are more akin to our verbs but with an easy way to attach them to different GUI elements solely by an XML file. (They can be triggered directly by code and they even have a DBUS interface built in.) Replacing GtkActions by GActions is a lot of work but our code will be much simpler.
I have a toy program that uses GActions that I plan on presenting at the Hackfest. I can make it available ahead of time.
Tav
Best wishes,
Alex
Thanks both!
-----Original Message----- From: Tavmjong Bah <tavmjong@...8...> To: Alex Valavanis <valavanisalex@...400...>, Inkscape Devel List <inks cape-devel@lists.sourceforge.net> Subject: Re: [Inkscape-devel] GtkActions in toolbars Date: Thu, 15 Mar 2018 09:10:07 +0100
On Wed, 2018-03-14 at 20:05 +0000, Alex Valavanis wrote:
Hi All, In preparation for the Hackfest, I'd like to start looking at ways to reduce (eventually eliminate!) our use of GtkAction.
One of the main uses we currently have for them is in toolbars, where the tool widgets (buttons, spinbuttons etc) are all some kind of subclass of GtkAction, which has been removed from Gtk+ 4. This means that when the user clicks on the button, it triggers an "activate" signal, which is handled by a callback function.
GtkActions have two modes: toolbar and menu. When a toolbar is too short it automatically switches to menu mode, accessed by the triangle at the left of the toolbar.
My question is basically, "what's the point?" Is there any reason why we can't just use a plain old button in most cases, and just connect up the "clicked" signal instead?
If it really needs to be some kind of Action, we could migrate to the GAction API, but this may be much more difficult.
I've done quite a bit of investigation of GActions. I think they are a much more useful than GtkActions. They are not bound to GUI elements like GtkActions. The are more akin to our verbs but with an easy way to attach them to different GUI elements solely by an XML file. (They can be triggered directly by code and they even have a DBUS interface built in.) Replacing GtkActions by GActions is a lot of work but our code will be much simpler.
I have a toy program that uses GActions that I plan on presenting at the Hackfest. I can make it available ahead of time.
Tav
Best wishes,
Alex
--------------------------------------------------------------------- --------- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks Tav,
That makes sense. It sounds, though, like any GtkToolItem can still show as an overflow menu item as long as a proxy menu item is created. See the following:
https://developer.gnome.org/gtk3/stable/GtkToolbar.html https://developer.gnome.org/gtk3/stable/GtkToolItem.html#gtk-tool-item-set-p...
If that's the only feature of GtkAction that we're trying to preserve here, we can just set the proxy menus on non-actionable widgets. In that case, it should be possible to remove GtkActions as a toolbar dependency fairly easily.
For the GAction stuff, I guess ideally we should be moving to GtkApplication, so we can register actions with application scope. As a starting point, though, I've had a play with registering GActions with Toolbar scope, and it seems to behave OK. I just swapped a few things round in the Connectors toolbar if you want to take a look at the diff: https://gitlab.com/inkscape/inkscape/tree/gtk-actions-migration
This way, we could do the migration fairly incrementally, rather than needing a complete overhaul of the application.
If you could share your toy application, that would be great - I'm still trying to get my head round all the options!
AV
On 15 March 2018 at 08:57, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Thanks both!
-----Original Message----- From: Tavmjong Bah <tavmjong@...8...> To: Alex Valavanis <valavanisalex@...400...>, Inkscape Devel List <inks cape-devel@lists.sourceforge.net> Subject: Re: [Inkscape-devel] GtkActions in toolbars Date: Thu, 15 Mar 2018 09:10:07 +0100
On Wed, 2018-03-14 at 20:05 +0000, Alex Valavanis wrote:
Hi All, In preparation for the Hackfest, I'd like to start looking at ways to reduce (eventually eliminate!) our use of GtkAction.
One of the main uses we currently have for them is in toolbars, where the tool widgets (buttons, spinbuttons etc) are all some kind of subclass of GtkAction, which has been removed from Gtk+ 4. This means that when the user clicks on the button, it triggers an "activate" signal, which is handled by a callback function.
GtkActions have two modes: toolbar and menu. When a toolbar is too short it automatically switches to menu mode, accessed by the triangle at the left of the toolbar.
My question is basically, "what's the point?" Is there any reason why we can't just use a plain old button in most cases, and just connect up the "clicked" signal instead?
If it really needs to be some kind of Action, we could migrate to the GAction API, but this may be much more difficult.
I've done quite a bit of investigation of GActions. I think they are a much more useful than GtkActions. They are not bound to GUI elements like GtkActions. The are more akin to our verbs but with an easy way to attach them to different GUI elements solely by an XML file. (They can be triggered directly by code and they even have a DBUS interface built in.) Replacing GtkActions by GActions is a lot of work but our code will be much simpler.
I have a toy program that uses GActions that I plan on presenting at the Hackfest. I can make it available ahead of time.
Tav
Best wishes,
Alex
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2018-03-15 at 10:42 +0000, Alex Valavanis wrote:
If you could share your toy application, that would be great - I'm still trying to get my head round all the options!
I've uploaded the code to GitLab:
https://gitlab.com/Tavmjong/gtk_sandbox/tree/master
Tav
Great! ...and thanks for the comments on my toolbar hacks.
From a quick look at your test, am I right in thinking that you haven't yet
hooked up the spinbutton to an action? I'm still not quite sure (a) how we'd handle spinbutton actions in our toolbars, and (b) whether we'd actually need to... I guess we can just use a callback to the "value-changed" signal?
AV
On 15 March 2018 at 18:49, Tavmjong Bah <tavmjong@...8...> wrote:
On Thu, 2018-03-15 at 10:42 +0000, Alex Valavanis wrote:
If you could share your toy application, that would be great - I'm still trying to get my head round all the options!
I've uploaded the code to GitLab:
https://gitlab.com/Tavmjong/gtk_sandbox/tree/master
Tav
OK, some (probably) good news...
I've done some more digging in the toolbox code. Basically, it was written so that auxilliary toolbars (the one under the main menu) could EITHER:
* be loaded from a UI Manager file, and have GtkActions hooked up by a "prep" function OR * be created from scratch using a "create" function
This, I think, makes our life *much* easier. We can just define Gtk::Toolbar subclasses for each Inkscape tool. The "create" function would just run their constructor and return the underlying GObject pointer.
I've updated the code documentation a bit in my branch. Next step (for the Hackfest?) is just to make the replacement C++ toolbars (without GtkAction!) and hook them up :). We can use GtkBuilder for the UI widgets if we want, or just define them directly in C++.
In future, we'd also be able to assign application-scope GActions to these, so that the toolbars can more easily run actions like "app.exit" if we want.
AV
On 15 March 2018 at 21:47, Alex Valavanis <valavanisalex@...400...> wrote:
Great! ...and thanks for the comments on my toolbar hacks.
From a quick look at your test, am I right in thinking that you haven't yet hooked up the spinbutton to an action? I'm still not quite sure (a) how we'd handle spinbutton actions in our toolbars, and (b) whether we'd actually need to... I guess we can just use a callback to the "value-changed" signal?
AV
On 15 March 2018 at 18:49, Tavmjong Bah <tavmjong@...8...> wrote:
On Thu, 2018-03-15 at 10:42 +0000, Alex Valavanis wrote:
If you could share your toy application, that would be great - I'm still trying to get my head round all the options!
I've uploaded the code to GitLab:
https://gitlab.com/Tavmjong/gtk_sandbox/tree/master
Tav
python but I think extensions can also be written in several languages.
On 3/17/2018 8:59 AM, Martin Owens wrote:
On Sat, 2018-03-17 at 08:48 +1300, Mark Schafer wrote:
If there was a way this could be exposed to the extensions that would be nice.
Extensions (py) or extensions (c++)?
Martin,
I've pushed a C++ migration of the Dropper toolbar (because it's the simplest!) to my branch.
Any feedback much appreciated :)
https://gitlab.com/inkscape/inkscape/tree/gtk-actions-migration
On 17 March 2018 at 09:49, Mark Schafer <mschafer@...2596...> wrote:
python but I think extensions can also be written in several languages.
On 3/17/2018 8:59 AM, Martin Owens wrote:
On Sat, 2018-03-17 at 08:48 +1300, Mark Schafer wrote:
If there was a way this could be exposed to the extensions that would be nice.
Extensions (py) or extensions (c++)?
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2018-03-17 at 22:49 +1300, Mark Schafer wrote:
python but I think extensions can also be written in several languages.
Ah then no. Extensions don't have any access beyond creating the simple widgets dialog. I'd love it if we have a better extensions system, but for the moment, there's no extra functionality for python extensions.
Best Regards, Martin Owens
participants (5)
-
Alex Valavanis -
Jabier Arraiza -
Mark Schafer -
Martin Owens -
Tavmjong Bah