On 05/18/2011 09:18 PM, Chris Lumens wrote:
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.
I agree, though we are going to have to twist and turn things to fit the
select-and-go model. I'll start looking into that.
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.
Step is a class already, so we have those options.
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.
I can not really imagine this yet, ditching dispatch() and have a
generic main loop transition between steps, it's something to look into.
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 is exactly where I am headed! It's only an implementation thing
that it's easier to start with threading+Queue, but once the separation
is good enough it's straightforward to switch over to processes+IPC.
But that's the same problem as with the other high level goals: the
large body of code does things in a wrong way utilizing some undesirable
mechanism A. We can not simply replace A for B without rewriting all the
code to use B too. This is true for steps granularity, controller/view
separation, the select-and-go model etc. Maybe we should start allowing
both A and B to exist at the same time, deprecating the former and
encouraging everyone to use the latter. In this way those big changes
can happen gradually and everyone can benefit from the new interfaces
sooner. I am thinking about using this for the threading feature.
Ales
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
