On 05/18/2011 03:18 PM, Chris Lumens wrote:
>> My patchset allows for an alternative where there would be one
>> method for going forward and one for going back, like 'storageinit'
>> and 'storageinit_revert'. The steps that don't need it would not
>> implement the '_revert' method.
>
> Just thinking out loud here - if a step were a class, perhaps we could
> have some sort of class decorator where actions were executed on
> entering and leaving.
I think this is on the right path, but I might take it a step further - we
could, with relative ease, have a class hierarchy like:
Step
One-shot Step
Resetting Step (if we decide we need to)
>>> Second, there's still the concept of steps that take a function to call
>>> and steps that look up the function to call in a stepToClass dict in the
>>> UI. This really needs to get unified.
>>
>> I am totally open to suggestions here. The problem is that executing
>> the step 'bootloader' in GUI does something completely different
>> then in text. IOW, what a step with a screen does is given by what
>> interface it is running under. So this information should be kept in
>> the interface anyway (or we need interface-agnostic steps, i.e. no
>> calls to gtk/snack from there: a whole different and bigger job).
>
> Having interactive and non-interactive steps comingled just bugs me. We
> may have to put this off until the UI rework ramps up, though. Assuming
> we go with the plan of getting everything from the user, then applying
> it all, that would separate out interactive steps into one list and
> non-interactive into another. They wouldn't be interspersed like they
> are now.
I do really think we need to consider making the UI into an application
that writes a kickstart file. Then when the user mashes the big "GO"
button, we're basically only executing it.
> Hm, I am curious why you are going with the threading approach vs.
> completely separate processes and a communications protocol between
> them. Seems to me that'd be an even more strict separation between the
> logic and presentation layers.
This would work well with what I said above.
--
Peter
In computing, turning the obvious into the useful is a living
definition of the word "frustration"
-- Alan Perlis
01234567890123456789012345678901234567890123456789012345678901234567890123456789
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
