FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-19-2011, 02:02 PM
Peter Jones
 
Default Reworking dispatch

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

01234567890123456789012345678901234567890123456789 012345678901234567890123456789

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-19-2011, 02:41 PM
Martin Sivak
 
Default Reworking dispatch

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@redhat.com
Red Hat Czech
Anaconda team / Brno, CZ

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 04:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org