Re: Design problem with radio items

[Michael Meeks <michael helixcode com>]

Hi Martin,

On 15 Oct 2000, Martin Baulig wrote:
> Wouldn't it be more logical to have one ID "Interpolation" per radio
> group and then set the state to "bilinear" on it when the user selects
> this ?

        I would like to allow both behaviors, but this is indeed one of
the things I have been wanting to implement for a while. Your design seems
good.

> 1.) after setting the state of the old item ("InterpolationNearest") 
> to "0" (and before setting the state of the new one to "1"), the radio
> group has an invalid state (no item is selected).
>
> 2.) from the component point of view, it's more work to add listeners
> for all the IDs of one radio group and only perform an action when the   
> state is "1" than to provide one listener for the whole radio group.  

        Yes; sure, I merely copied the way the functionality worked in the
old UI handler, it is simpler to implement this way.

> I don't have a patch yet, but I can make one :-)
  
        That would be great; here are some things to bear in mind

* As you suggest the group name should be put in the command namespace and
a node created for it.

* since we currently have a way of setting the state of the items by
putting state="1" on the individual radio items, how do we sync this state
with the group state ?
  
* we need to keep track of the state when items are de-merged from a radio
group; it is quite possible for a radio group to contain items from
different components. Hence we need to attach to the destroy signal on the
group and somehow switch to another item if we are destroyed.
  
* the value to set the state of the group name command should be the id /
verb of the item.
  
        It'd be great to see a patch for this.
  
        Thanks,
  
                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot