Hi, > 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. Yes, we need to record user's choices not the resulting state of the system. That way we have no "revert" problems, because we have no or minimum of side effects. When going back we could just show the GUI filled with what the user set previously. But Ales was working on dispatch cleanup, not the whole UI redesign, which is much bigger task. This is just the beginning folks... as Ales is trying to say this is step 1) make the table look organized so we see what we are doing > 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) > > > 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. Well before we undertake the next step of gutting the whole iw/ subdirectory and writing it again, we should think about the relationship between steps and views... Right now we call "direct" steps as methods and call UI methods to process other steps for us. That is completely wicked. We should execute all the steps in the same way and pass the UI instance to them instead. Let the steps decide what to do and return what should happen next (eg. constants for going back or forward). That way the "direct" steps are no different to the others and can contain their own logic (should it be reversible? or can it do something multiple times? that should be decided by the step, not by some logic in dispatch). The steps should also contain all the data necessary for them to work (when the execution is separate, it will hold only the user's choices, that is where we want to go, right?) If we get to that state, we can even move some steps to the execution part without disturbing the rest much. Because everything will be self-contained. GUI code will just prepare the infrastructure for the step to use. So API to create dialog, fill it by data and read the data back. The validation should be done in the step which is using the GUI. There will be some logic, which will limit user actions in the GUI, that is unavoidable, but the logic should contain no side-effects and after the user confirms the selections, the step will validate and record the data. > > > 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. > Yes I like this approach too, but first we have to cut all the logic from GUI code to the step's codes... -- Martin SivÃk msivak@xxxxxxxxxx Red Hat Czech Anaconda team / Brno, CZ _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
