> When user keeps hitting back in the gui, steps should revert what > they did previously so they can be reexecuted later(at least in > theory, it's not always necessary). Tell me if you think otherwise, > but we need to keep this ability. To do that right now, yes, they > check the dispatch.dir variable and react accordingly. Our relatively short term plan is to come up with a whole new UI. Given that, I think we can afford to throw out some of our old behavior where it makes sense to. Perhaps here is one of those places. I think first off, we should consider breaking our steps down into more discrete chunks. I am positive we've got some non-interactive steps doing way more than they really ought to. Then, I think we can get rid of the concept of steps resetting. I think preserving the data makes more sense - especially in a model where we have everyone enter their selections beforehand, and then press the big "GO!" button. I think it's the less surprising behavior. If you think about it, there are really only three interactive steps that are sufficiently complex to require resetting: filter, partitioning, and packaging. Partitioning even has a reset button. I haven't thought this completely out, but I think a combination of the non-resetting approach, making finer grained steps, and perhaps thinking of how some steps should be one-shot and some should execute every time allows us to kill a lot of this nonsense. > 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. > >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. So, I guess I'm fine with what's going on here for the time being. > >Third, I was really hoping that any control flow rework would also > >provide us with a proper main loop. Peter's been talking about wanting > >that for years, and we'll need one if we ever want anaconda to be a dbus > >message producer in addition to consumer. And I've already got at least > >one reason for wanting that. > > Yeah, this is a pain in the ass. A 'proper' main loop what do you > mean by that? > > The Dispatch.dispatch should act as the main loop and I tried to > make it that way as possible, yet it still has to exit and be > reentered. This is because we have another loop, gtk.main and one of > the loops needs to be running the other loop (one of them needs to > be on the stack above the other one): in our case it must be > gtk.main, because we don't want to quit it and start it again over > and over. And we can't just keep gtk.main sitting above either, the > gui would never do anything. In a main loop approach, anaconda would be event driven. We'd set a bunch of stuff up, call g_main_loop_run (for instance - could be something else), and then all the step moving would be driven by events like button presses. > The solution to this is having gtk.main run in a separate thread. > But I had to start on this feature first and having the steps with > attributes is the first, huh, step. > > So all in all, this set enables a lot of things we couldn't do > before and breaks (hopefully) none. Plus I remember from fudcon the > main complain was it was never possible to tell if a step is going > to be run > or not and I think I helped that by making the scheduling interface > more strict. 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. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
