[Gambas-devel] Question about _DrawWith

[Benoit Minisini]

On samedi 12 avril 2008, Robert Rowe wrote:
> Thanks for the info. I rewrote it as you described and it did not cause
> an error but it didn't seem to do anything.
>
> Public Const _DrawWith As String = "uctoolbar"
>
> I surmise this is because the IDE didn't have my toolbar loaded. I went
> ahead and removed it as you suggested.
>
> By the way, try typing _dr. You will see that the IDE does show an auto
> complete list but _DrawWith isn't on the list.
>
> Have you had a chance to work on the action class any? I'm in a holding
> pattern with my toolbar until the action class is written.
>
> Robert Rowe
>

Hi, Robert.

I don't forget you, I just didn't have the time to work on the Action class.

Here is the result of my thoughts...

(1) My first question was: Does it worth making an action class that 
centralizes information about actions? 

At the moment, the action class just takes its information directly from the 
controls associated with the action. It stores nothing.

If the user had to define all action properties in a separate dialog, the 
information defined in the controls become useless. So progressively using 
actions in a project that didn't use them at the beginning need duplicate 
work.

So I think I should keep this design, because it allows the user to 
progressively add action support in its project without having to enter the 
same information twice.

Now, the action class needs to behave as if it stores the action information: 
Text, Icon, Shortcut, Tooltip... So it has to extract them from its 
associated controls, by giving priority to some controls on other ones. 

Action is supported by Menu, ToolButton, ToggleButton, SidePanel, Window, 
ToolBar. 

Window, SidePanel and ToolBar do not count in this history, as they are just 
shown or hidden according to the value of an associated ToggleButton or Menu 
with its Toggle property set.

So, for example, we can choose that Menu > (ToolButton | ToggleButton).

(2) Now how can we define the toolbutton tooltip the way you wanted? I.e. by 
adding the shortcut at the end of the original tooltip.

Let's suppose that you have a Menu and a ToolButton associated with the same 
action. The shortcut is defined in the Menu. It is the only place as, at the 
moment, ToolButton do not have shortcuts.

By deciding that the shortcut will be added between braces at the end of the 
tooltip, we can easily detect it and know if it should be added, or replaced, 
when setting the Shortcut property of the action. Of course, if you set the 
Shortcut property of the menu directly, nothing happens.

I'm not agree with following the KDE/GTK+ design for making a toolbar. It is 
logical, as they didn't have GUI designer integrated initially. 

I prefer that you add features to the existing ToolBar class, that already 
support what your toolbar does not yet, like right-to-left language written 
support.

(3) Now how can you add a toolbar configuration dialog?

First, you must know all possible actions supported by the toolbar. I simply 
suggest taking all the toolbar children controls. 

Then, make a dialog that allows the user to decide which one are visible, and 
which one are not. Then make a Settings property in the ToolBar class that 
makes a list of all hidden controls by using their names.

(4) Now how can the user globally configure the actions of all menus, 
toolbars, and so on?

All actions are registered in the Action class when a control is created. But 
not all controls are necessarily created at startup.

So the user will have to declare the list of all actions used by its project, 
with their name, tooltips, icon name, shortcuts... 

Then, at runtime, an action configuration dialog will be able to be created. 
this dialog will load and save action settings that will be applied at 
application startup, and when the action configuration dialog is validated.

This is not in contradiction with the first point: at design time, the IDE 
will have a dialog centralizing the information about actions, but at runtime 
it will just be some text file used by the action configuration dialog. The 
Action class won't see it.

Well, that's all! Tell me what you think about that design, and if you see 
what you can do in the current ToolBar class from the job you already have 
done.

Regards,

-- 
Benoit Minisini