What is it ?
Developing with GUI is different from bash straight processing. GUI is event based, bash should ready to run whatever function or event. Consolidating these action into gtkdialog definition is now should be a breeze. Lets look at how things will work. We just use a simple example to see how this work, In real dev, it might be different case but still the concept is still the same - modularity.
Once upon a time you make a fictional app - App to run browser. You start small and decide to add things later.
First - you create a button, its will run firefox, later on you add a menu - run firefox &, more functionality yeah ? after few weeks, you decided to add toolbar, still do the same thing - run firefox &. All do 1 thing in common - firefox &. Works great. Lets add a button to run IE ?. After editing 3 places you have IE button, menu and toolbar. Great.
Suddenly, you decided, if user ran firefox, they don't want IE anymore and vice versa. You have to disable the other. There are 6 different place you have to edit there buddy...... or would you like to edit 2 line only ?
What if later you want the command have arguments ? 6 place or 2 line ?
or bring up a messagebox informing browser is/already running ? 6 place or 2 line ?
It add up to more dev time.
Get it ?
With gmould, you simply create a button and assign it an .action file. Later, add a menu and use THE SAME action file, and so on with toolbar. For IE, you repeat but with a different .action file. Any change in the action file will be reliase in ALL widget that use it.
Edit 2 line and you are editing 6 widget, is that productive or not ?
Oh I see...
This is the reason action are grouped. Same task performed by different widget and its easily modifiable. For customized behavior I do have the idea of chaining action files, but that will make gmould more complex.
If chaining action applied, we can have a lot more flexibility, but of course it come with complexity :). For now, lets stick with the basic.