[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] heads up: changes to engine/include/options.h
From:       Luciano Chavez <chavez () us ! ibm ! com>
Date:       2001-09-18 9:45:02
[Download RAW message or body]

On Thu, 2001-09-13 at 10:08, Luciano Chavez wrote:
> For those of you working on getting options in your engine plugins, I
> ask that you read this. I am intending to make some changes to the
> option_descriptor_t structure in order to support some new flags to
> allow the UIs to make some better/more exact determinations on what is
> needed by the plugin.
> 
The changed options.h is in CVS now.

> Originally, there was a field called capabilities that had some things
> in it that just didn't make sense. For example, was the option value
> settable? 99.999 % of the time you want to set the option value. I've
> renamed the field to simply "flags" and renamed the macros accordingly.
> I also added a couple of #defines, mainly EVMS_OPTION_FLAGS_REQUIRED and
> EVMS_OPTION_FLAGS_VALUE_SUPPLIED.
>

I Actually made it EVMS_OPTION_FLAGS_NOT_REQUIRED and
EVMS_OPTION_FLAGS_NO_INITIAL_VALUE. In most cases the option indicates
required input and you should set an initial value, especially when a
constraint is given. Some of you will have to change your code that used
to look like

context->option_descriptors->option[0].capabilities = EVMS_CAP_SETTABLE;

to

context->option_descriptors->option[0].flags = 0;

In some cases you don't provide an initial value so the
EVMS_OPTION_FLAGS_NO_INITIAL_VALUE should be turned on.

For those that have calloc'd or malloc'd the max size string buffer for
a text entry option and the string is empty just realize that I don't
use that buffer for storing the input string. This is IFF an initial
value is supposedly supplied.

Rather, I strdup the initial string value to initialize the input widget
with. Then when a change occurs, I retrieve the string value from the
widget a copy the string into a buffer that is as large as specified by
the size field in the option descriptor. If the evms_set_option_value()
modifies the string, I turn around and update the widget value
accordingly.

So, if you have text input that you don't have an initial value for then
I suggest you simply initialize the following option descriptor fields
as:

context->option_descriptors->option[0].flags =
                                   EVMS_OPTION_FLAGS_NO_INITIAL_VALUE;
context->option_descriptors->option[0].size = MAX_SIZE;
context->option_descriptors->option[0].value.s = NULL;

I'll take care of the rest.

One last thing, remember that the number of options can not change
throughout the life of a task context. You can change flags, initial
values, constraints, etc. as long as the changes were signaled through
the info field returned by a evms_set_option_value() call, i.e.
EVMS_INFO_RELOAD_OPTIONS is returned.
 
> The first flag is used to determine if the application MUST supply an
> option key_value_pair_t in the option array for this option when it
> makes the API call for the corresponding task.
> 
> The second flag indicates if the value field in the option descriptor
> was initialized. This was mainly to determine if there is a real pointer
> to a string rather that junk or an actual meaningful numeric value in
> the field. In some case, there is no initial value or constraint value
> such as when asking for  new input from the user.
> 
> The inactive flag is interpreted by the UI to mean that this option
> exists but is neither optional at this point or required. It is possible
> that the setting of another option then makes this option become active
> and possibly required.
> 
> I currently can see that Steve P and Don will need to make the proper
> adjustments. Both of you will have to decide which options are required
> or optional rather than simply making them settable which is now
> defunct.You'll also have to OR in the value supplied flag as necessary.
> 
> I also intend to remove the EVMS_Type_Group from the value_type_t enum
> as it is not a type and the group_info_t in the option descriptor and
> extended info structures replaces it.
> 
> Lastly, I also intend to get rid of the EVMS_INFO_READY flag returned
> from the set option value API calls to indicate all required options
> have been set. Since the option descriptor now identifies what options
> are required, I can keep track of this myself. This way, I can run down
> through all the widgets initially or when they change values to see if
> all required options were set to allow the task button to invoke the
> action. Each UI can do this rather than each plugin. I am not sure that
> you were using this anyways.
> 
> I suspect, knowing what is optional or required may help Ben's CLI spit
> out more specific syntax requirements for a plugin operation.
> 
> Please let me know if you have any questions. I expect to make the
> change AFTER the 0.2.0 tarball is released.
> 

regards,

Luciano Chavez

[prev in list] [next in list] [prev in thread] [next in thread]