View Full Version : API Issue

February 4th, 2005, 01:01 PM
My fellow plugin developers - I have a conceptual issue regarding the API design that I'd like some input on.

When I create a new command in Girder, and then select my plugin on the tab and press Settings, Girder calls gir_command_gui and then gir_command_changed with a command structure. Experiment shows that the command structure ActionType is not initialised to the plugin number but to 1. From the behaviour of the GUI, this is the Window Click command. Now, I disable my command GUI if the selected command is null or not from my device type, but how do I allow my GUI to edit a newly created command? At present, I'm just allowing it to edit ActionType = 1 as well as my device number, but is this future proof and safe?

It does not seem ideal - would it not be better for Girder to set the ActionType to the plugin device number when Settings is pressed for a newly created command?

While we are on the subject, it would be nice for an addin to be able to disable the Target button if it is not relevant.

Mark F
February 4th, 2005, 02:07 PM
This is a specific example of a more global behavior as the ActionType can be anything. :) Think about this scenerio:

I define a command in the tree. This command uses plugin A to send data to a device. Plugin A puts it's ID in the ActionType field before giving the updated structure to Girder.

I next decide that I want to redefine that same command to use plugin B to get data from a different device. What should plugin B do? The ID doesn't match it's own and probably isn't 1.

The solution I reached was:

If the current command pointer is NULL, disable the plugin settings UI except the Cancel/Dismiss/About button.

If the ActionType of the current command does not match the plugin ID I expect, pretend this is a new command (put the default values in the settings dialog). If the user doesn't press the OK/Save/Apply button on the settings dialog, don't send the updated command to Girder.

Using this solution, as you point at different objects in the command tree, you will see the following behavior of your UI:
Point to an eventstring, folder, multicommand -> UI disabled
Point to a command defined, not yours -> UI enabled, filled with defaults
Point to a command defined, yours -> UI enabled, filled with command data

Does this help?

February 4th, 2005, 02:49 PM
also note that the api concerning this is completely different and much better and easier to program in girder 4

February 4th, 2005, 04:14 PM
Thanks Mark, yes that makes sense and I'll do it that way.

Looking forward to recoding for 4.0, but we do seem to have been waiting rather a long time for it now! :wink: Is the new API publically available?

Mark F
February 4th, 2005, 04:32 PM
Contact Mike C. I don't know how wide of an audience the current G4 Alpha is targeted for. I'm guessing the API will possibly change between now and release so you might be looking at a shifting target.

February 4th, 2005, 05:42 PM

All developers were to get an email for beta testing.. If you didn't PM Ron. Its up and running great. API is pretty solid.

February 5th, 2005, 05:02 AM
Thanks, I'll make contact with Ron again - I've been quiet doing other things for well over a year now, so he's probably taken me off his list.