Re: GTK fe: multiselect handler and hw-detect/select-modules problem

[Attilio Fiandrotti <fiandro@tiscalinet.it>]

To be precise it doesn't crash anything , but since the forward button 
doesn't work the installation process is stuck at the first question of 
the hw-detection step (control never reaches the boolean next question).
With the modifications proposed the installation process can get past 
that point with no problems by simply aswering "forward" to the 
0-options multiselect question that is now displayed.
Anyway how should behave the frontend when 0-options questions are 
passed? should it display the user an empty question and wait for him to 
press next or should it automatically answer back "DC_OK" to the client 
to force him to ask the following question? If so the appropriate 
mechanism has to be implemented.
I've noticed that the NEWT frontend simply skip that question and 
automatically proceeds to the next one.

ciao

Attilio


Colin Watson wrote:
> On Mon, May 23, 2005 at 10:08:54PM +0200, Attilio Fiandrotti wrote:
>
> > at lines 645-647 in gtk.c we can find
> >
> > defcount = strchoicesplit(question_getvalue(q, ""), defvals, count);
> >    if (defcount <= 0)
> >    	return DC_NOTOK;
> >
> > here i suppose we check thet a multiselect question without options is 
> > not displayed, but i think this should be changed to
> >
> > defcount = strchoicesplit(question_getvalue(q, ""), defvals, count);
> >    if (defcount < 0)
> >    	return DC_NOTOK;
> >    else if (defcount == 0)
> >    	return DC_OK;
> >
> > to prevent multiselect questions with no options (that, although 
> > illogical, should be correctly handled ) from crashing the frontend.
> > This is exactly the case of hw-detect/select-modules if there are noa 
> > vailable modules to be loaded.
>
>
> I actually made hw-detect >= 1.16 not ask that question if it would be
> zero-length.
>
> You say it crashes the frontend, but doesn't it just return an error?
> I'm ambivalent about whether or not that's the right thing to do ...
>
> (Either way, all cdebconf frontends should do the same thing in this
> regard, so if this behaviour changes it should change in newt, text,
> etc. too.)