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

List:       evms-devel
Subject:    Re: [Evms-devel] Just when you thought you were done with options...
From:       Luciano Chavez <chavez () us ! ibm ! com>
Date:       2001-09-21 21:52:02
[Download RAW message or body]

On Fri, 2001-09-21 at 22:37, Kevin Corry wrote:
> On Friday 21 September 2001 19:09, Andrew Clausen wrote:
> > On Fri, Sep 21, 2001 at 07:48:51AM -0500, Kevin Corry wrote:
> > > Unfortunately, my original example, PE size, has a range of 8k to 16G,
> > > which produces a list of 22 values.  But, if the GUI can find a creative
> > > way to display a large list, then I suppose this example isn't all that
> > > bad either.
> >
> > I don't think 22 is too bad... but it is getting borderline...
> >

While all the formulas sound great, ultimetly I intended the widget
itself to be the constraint and only enforce allowable values. For
purely numeric values (integer or real), I intend to use a slider bar if
the maximum value is small or the increment is large enough to keep the
selections from min to max to be small. For other ranges, I was going to
allow a spin button. Both allow defining a min, max, and increment. 

For the PE size case, providing the PE size as a value_list_t contraint
containing the 22 integer values in sector units may not be a bad idea.

I have two widgets, the pulldown selection menu and the combo box
pulldown menu that I am using for valid choices. The selection menu was
going to be good for 20 - 25 max items. Above this, the combo box would
be necessary since it provides a scrollbar for the longer lists.

The nice thing about the lists is that I can convert sectors to
something friendlier for display and then convert it back to sectors
when updating the value with the plugin.

Bottom line, PE size may work best as a value_list_t as opposed to a
value_range_t. Fill the constraint with a list with the (unsigned)
integer values in sector units (unit is EVMS_Unit_Sectors). Don't enable
the EVMS_OPTION_FLAGS_NO_UNIT_CONVERSION bit in the flags so conversions
get done.

The user will then see a pulldown list that will show "8 KB", "16 KB",
... "128 MB", "256 MB", ..., "2 GB". As selections are made, they will
be converted back to sectors when you get an update request (since that
is the unit value you specified on the option descriptor).

I hope the other UIs follow suit.
 
> > Another option is to allow the user type in anything, and as soon as they
> > hit "enter" (or whatever), the GUI automatically rounds to the closest
> > valid value, and updates the on-screen value immediately.
> 
Yep. I could do that but sometimes folks don't know to hit enter for
each text entry field. I could do it if the text entry field lost the
keyboard focus. This might not work for the last text entry field still
containing the focus. Open-ended (non-constrained) option values are
always entered through text entry fields in the GUI (booleans don't
count since they are constrained implicitly to yes/no, true/false,
on/off, etc.). They offer their own challenges which I will eventually
solution.

> Actually, this will already happen in a way. The GUI and the plugin have a 
> way to negotiate on options before the actual create command is issued (or at 
> least this is how I currently understand it). The GUI starts by asking the 
> plugin for all of its possible options for the create. The plugin fills in a 
> set of data structures describing those options, along with default values 
> and range/constraints. The user can selects a value for an option, and the 
> GUI calls back to the plugin to "verify" that option. If the plugin is 
> alright with that value, it leaves it alone. If that value is invalid, it can 
> return an error, or try to "correct" the value to something valid or more 
> reasonable. Thus, the user will essentially just see the option be updated to 
> the nearest valid value, as you stated.
> 
> Luciano, does this description sound right to you?
> 

Wow. Correct. I couldn't have said it any better. If the GUI is given a
constraint though, normally I select a widget that will self-contain the
allowable selections to avoid the plugin either adjusting or rejecting
them.

For me, when no constraint is given, it is essentially up to the plugin
to handle the validation (obviously). A text entry widget is used for
non-constraint options. I can only validate a few things such as if it
is a string that it can't exceed a certain length or if an integer it
must be a valid integer value. 

regards,

Luciano Chavez

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