DUI questions

[MMcM]

I am trying to get caught up on the plugin API with an eye to converting the more complex plugins or at least scoping the effort. Other demands on my time have meant that I have not kept up completely. I have gone through the manual and the postings here, but I am sure that I have missed a few things.

Some observations on the documentation.

There is no mention of SetCallbacks, which is essential to getting the events that it does describe.

The fields are global LUA objects, that is, tables. Among other things, the routines in dui.cpp are wrappers for the LUA API for manipulating the tables (object slots). It might be worth mentioning this, since otherwise it's hard to see how LUA is involved when using C++ functions to manipulate everything.

It seems like it ought to be possible, perhaps even desirable, to implement the duOnEvent handling in LUA directly with a script. That is, things like enabling and disabling controls based on one another's state. This could be done from the page callback by calling a LUA function, but perhaps there is some more standard way.

There is a standard trackbar control. But I do not see a spin+edit combination, which some existing UI's have. Is it hard to add one?

I do not see a control property for visibility. Maybe there is one in the implementation, but it isn't documented (yet). Or maybe showing and hiding controls is considered bad style.

Which brings me to some bigger questions. I see that one of the goals of DUI is to standardize the user interface among the various parts of Girder. So it seems a bad idea for plugins to go out of their way to subvert the standard.

Right now, I have some action plugins that choose an action from a drop-down list and set state according to the choice. In the case of LCD, some of the state is very specific to the choice (like a variable name) and some is common for a variety of choices (like position). Should they continue to use this interface style? Or should the choices become subactions with separate nodes in the plugin's group and separate interface pages? One issue is that it is much harder to change a subaction like that: you pretty much have to recreate it from scratch.

Do I understand right that the Settings button in the Plugins section of the Settings page is being phased out in favor of custom plugin pages in that dialog? Since the real estate is shared, I imagine that a single plugin should contribute at most one page. Concretely, the LCD plugin in multi-device mode would have the device list on that page with a modal tabbed dialog for editing a single device. But what about single-device mode? Would it just show a text summary of the one device with a single push button to edit it with the same tabbed dialog? In Girder 3, it pops that up directly from Settings. I don't think that there are many fans of multi-level tabs in a single window.

[birty]

i take it youve looked at this post:
http://www.promixis.com/phpBB2/viewtopic.php?t=10895

[Ron]

I have gone through the manual and the postings here, but I am sure that I have missed a few things.[/qoute]
For my part I am sure I didn't document everything yet. (sorry)

[quote="MMcM"] There is no mention of SetCallbacks, which is essential to getting the events that it does describe.[/qoute]
Every node that can have a callback, like a Form (duItem) or a Control (duControl) can have a callback function assigned to it. For most cases this will be one and the same function but you can set it to many different functions as per example.

[quote=MMcM] The fields are global LUA objects, that is, tables. Among other things, the routines in dui.cpp are wrappers for the LUA API for manipulating the tables (object slots). It might be worth mentioning this, since otherwise it's hard to see how LUA is involved when using C++ functions to manipulate everything.
Will do.


It seems like it ought to be possible, perhaps even desirable, to implement the duOnEvent handling in LUA directly with a script. That is, things like enabling and disabling controls based on one another's state. This could be done from the page callback by calling a LUA function, but perhaps there is some more standard way.
If you look at the TDUIItem structure you'll find something called LuaCode. It has not been implemented yet but I am planning on doing exactly what you suggested.


There is a standard trackbar control. But I do not see a spin+edit combination, which some existing UI's have. Is it hard to add one?It should not be. I will investigate.


I do not see a control property for visibility. Maybe there is one in the implementation, but it isn't documented (yet). Or maybe showing and hiding controls is considered bad style.
I am not aware that this might be bad style, I will see if I can add this one.


Which brings me to some bigger questions. I see that one of the goals of DUI is to standardize the user interface among the various parts of Girder. So it seems a bad idea for plugins to go out of their way to subvert the standard.
Yes, if plugin can fit into the DUI then please do so :-)


Right now, I have some action plugins that choose an action from a drop-down list and set state according to the choice. In the case of LCD, some of the state is very specific to the choice (like a variable name) and some is common for a variety of choices (like position). Should they continue to use this interface style? Or should the choices become subactions with separate nodes in the plugin's group and separate interface pages? One issue is that it is much harder to change a subaction like that: you pretty much have to recreate it from scratch.
If the user goes back an forward between the different action-sub-types then maybe it should be one action with this dropdown just being an option instead of an actionsubtype. (Does this make sense?)



Do I understand right that the Settings button in the Plugins section of the Settings page is being phased out in favor of custom plugin pages in that dialog? Since the real estate is shared, I imagine that a single plugin should contribute at most one page. Concretely, the LCD plugin in multi-device mode would have the device list on that page with a modal tabbed dialog for editing a single device. But what about single-device mode? Would it just show a text summary of the one device with a single push button to edit it with the same tabbed dialog? In Girder 3, it pops that up directly from Settings. I don't think that there are many fans of multi-level tabs in a single window.

If the DUI turns out to be sufficient for our plugins then we will drop that button indeed. Yeah it would be best if a plugin doesn't contribute more then one page, but if needed there is nothing that is prohibiting a plugin from entering more pages.

Also see this discussion that we had with Mark about a similar topic,

http://www.promixis.com/phpBB2/viewtopic.php?t=10904

[Ron]

Mike, for the Spin Control to make sense for the 'dumb' DUI it should have a label attached to it, is that good for your application?

[MMcM]

Do you mean a static label in addition to the edit text? Or the edit text? What I would want is the edittext with ES_NUMBER and probably ES_AUTOHSCROLL next to the msctls_updown32 with UDS_SETBUDDYINT and UDS_AUTOBUDDY and probably UDS_ARROWKEYS. An extra ltext next to that wouldn't hurt, but does not seem necessary.

Why is there no PlugInDir under HKEY_LOCAL_MACHINE\SOFTWARE\Promixis\Girder\4 for a plug-in's installer?

How does an event-generating plug-in fill the list part of the Event String combo? Is that duEventLoadVars? It isn't in the .H file or the documentation that I can find.

[Ron]

Hi Mike,

The spin control has been added in A12. It comes with the edit control next to it.

Currently we do not have a way for the plugin to let the EventDialog know about what events it can send, What I could do is add a function call into the plugin that requests the eventstrings.

char * gir_eventstring_advise( ... )
{

PCHAR s = malloc (..)

return s;
}


Would that work? Do we need to pass anything? (can't think of anything).

Edit: I'll add the PlugInDir to the next release.

[birty]

you already added the girder directory, which is sufficient ot work out the plugin directory, i posted an nsis script to use it here: http://www.promixis.com/phpBB2/viewtopic.php?t=10318

[MMcM]

I cannot think of anything to pass either when requesting the possible events.

How does the keyboard plugin populate the list of keycodes today? Is it known about specially?

[Ron]

Currently it is Girder handling all of these details. It simply remembers events that came by and adds them to the list.

[MMcM]

In the XML, a combo box control has two lists of strings, one for display and one for value, which is synchronized with the action field in automatic mode. In LUA mode, the manual documents one list of strings and a selected item index. Can one access the second string list and the mapped value via LUA (that is, the ControlSet/GetString API)?

[Ron]

In lua mode you should get the ItemIndex (0-based) to find out what the user selected.

[MMcM]

What will the visibility property be named, Visible? Or is it there already under some other name? I'll use Enabled for the time being.

A label with Lua binding has no initial caption, rather than the name from the XML file. A checkbox with Lua binding has no initial caption and is checked. These are not hard to work with, but not what I expected.

How is the range of the new spin control set? I tried Min and Max, but it stays the same as in the XML file. Position does seem to work as expected.

Can we have a radio button outside a group? It can just behave the same as a checkbox but with a different appearance: I'll take care of unchecking peers in the event callback.

[Ron]

The visible property will be called Visible, however this is not yet available.

Any control that has a lua name assigned to it has to be fully initialized through Lua, the other XML properties are ignored.

The Min, Max and Position should have worked, I will look into this.

I won't be adding a radio button outside of a group. Sorry. (I have to stop adding features at some point or I'll never be done).

[Ron]

I have checked the spin control and it seems to work here is the code I used:

duOnApply:


SafeFree(Command->Action.iValue1);
double pos;
char buf[100];
ControlGetNumber(L, "Spin1", "Position", pos);
Command->Action.iValue1 = GStrDup( itoa( int(pos), buf, 10) );


duOnGetValues


ControlSetNumber(L, "Spin1", "Min", 1);
ControlSetNumber(L, "Spin1", "Max", 100);
ControlSetNumber(L, "Spin1", "Position", atoi(Command->Action.iValue1) );
ControlSetBool(L, "Spin1", "Enabled" , TRUE);


Let me know if you are having any problems with it. Are you running the latest alpha (15)?

[MMcM]

Let me know if you are having any problems with it.

I see. My problem is only when changing Min / Max in duOnEvent. The use case is a combo changed and the range is affected.

[MMcM]

If I change the page in duOnGetPage, the item description in the upper left General area remains that of the initial page.

The use case is an old GML file with the original ActionSubType. Based on other parts of the Action state, it upgrades to one or the other of the separate DUI interfaces.

[Ron]

Okay I tried it seems to work here, can you specify the bug?



void * Range(pLuaRec LuaRec, int button)
{
lua_State *L = (lua_State *)LuaRec->L;
switch (button)
{
case 1:
ControlSetNumber(L, "Spin1", "Min", 20);
ControlSetNumber(L, "Spin1", "Max", 30);
ControlSetNumber(L, "Spin1", "Position",20);
ControlSetBool(L, "Spin1", "Enabled" , TRUE);
break;
case 2:
ControlSetNumber(L, "Spin1", "Min", 1);
ControlSetNumber(L, "Spin1", "Max", 1000);
ControlSetNumber(L, "Spin1", "Position", 35 );
ControlSetBool(L, "Spin1", "Enabled" , TRUE);
break;
}

return NULL;
}


in gir_dynamic_ui for this page:


case duOnEvent:
switch (val2 )
{
case 10:
return Range(LuaRec, 1);
case 11:
return Range(LuaRec, 2);
}
break

[Ron]

If I change the page in duOnGetPage, the item description in the upper left General area remains that of the initial page.

Fixed.

[Ron]

The Visible property has been implemented. New release scheduler for today.

[Ron]

gir_eventstring_advise has been implemented.

[MMcM]

Any control that has a lua name assigned to it has to be fully initialized through Lua, the other XML properties are ignored.

I am having trouble with a brand new action.

duOnApply is called on the page with the checkboxes in this uninitialized state that looks like checked. As a result, the saved state of the new command has the checkbox on.

I see that duOnGetDefaults is called first, but I cannot find it in the manual. Am I right in thinking that for Lua mode controls, this callback must set them to a good initial state which duOnApply will then store into the command? No modification of the command (which arrives with all the fields holding empty strings) is needed in advance of that duOnApply. Correct?

[Ron]

Yes during OnGetDefaults initialize the lua fields for an new action.