Developing with gmould - reason of action group.

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.
Exampli gratia
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.
The problem
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.

TabMenu aka The Ribbon

Today I did have time to work on the TabMenu. The icons constants need to be completed, but with new dialog, I always found a better way to do it, but to do it within gtkdialog is very hard. Not because of code, but lack of it.
gtkdialog problem - There is no established components.

Thats is the point to create gmould. To heighten gtkdialog up to - usable toolkit. Enough ramblings, here the TabMenu aka Ribbon menu. New revamped icons too, lots of icons missing, soon they will be defined in constant.h and headache go away - a bit.

During my research about the ribbon, I found out the best for gtk is like this...
If its only a button - 48 pixel
2 button - 32 pixel
3 button - 16 pixel
4 button - go find a ribbon screenshot showing 4 layer of button and tell me
6 button - 16 pixel, icon only, no text

I'm thinking of building the TabMenu component, but MS Ribbon seems to have lots more of widget instead of only buttons. Maybe later I guess. Icon reorganise is more important. Oh and then theres, the gridview and then the list exchanger and toolbar creator and hbox/vbox creator and...

as I said - No established component.

I DO create better "treeview" component however :). Treeview and Ribbon menu below, also the collapsible panel is seen there