Bug#247045: this needs cdebconf work
On Wed, Jan 12, 2005 at 01:08:50AM +0000, Colin Watson wrote:
> On Sat, May 22, 2004 at 11:23:13PM -0700, Joshua Kwan wrote:
> > The original reporter of this bug wants to be able to cancel DHCP
> > autodetection. This is a good idea, but it needs some cdebconf firepower
> > so we can perhaps bind a callback function to a Cancel button during a
> > progress bar or set some sort of status flag. Is this possible?
>
> (Also Konstantinos' bug #251974.)
>
> The simplest way I can think of to do this would be to have the progress
> bar functions (i.e. db_progress <anything>) return some new error code
> in the 30-99 range if the cancel button was pressed since the last time
> a progress bar function was called. Then individual udebs can cope with
> that however they like, and will have the opportunity to clean up
> properly.
>
> As you suggest, a CAPB is needed to ensure that code that doesn't expect
> these extra return codes never gets them.
>
> If people like this idea, I hereby volunteer to implement it.
Well, I gave it a go. Unfortunately, I don't see how to do this in the
newt frontend. newt is not event-driven; you have to be actively running
a form in order for the button to be active, and if you're doing that
then the frontend can't be doing anything else, like replying to the
udeb so that it can do the things it needs to do between the progress
bar steps.
The only way I can see to do this is to do some very grotty stuff to
cdebconf's internal design in order to allow frontends to influence
confmodule communication, which would enable the newt frontend to do
newtFormWatchFd() on the confmodule input fd and then say "instead of
your idle state being read() on the confmodule input, please make it be
newtRunForm() instead". That way you could have the progress bar running
and still be able to process commands. That just makes me feel ill,
though.
The other frontends seem to be less of a problem.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: