[PEAK] Towards a GUI facility for PEAK

[Phillip J. Eby]

At 11:28 AM 12/23/04 +0200, Niki Spahiev wrote:
>Phillip J. Eby wrote:
>>At 05:56 PM 12/22/04 +0200, Niki Spahiev wrote:
>>
>>>I hope that my code is better than my words :)
>>>
>>>This is minimal ctypes based demo. test_calc.py is UI with selftest. Its 
>>>completely UI independent.
>>
>>Nice.  There actually is some minor coupling from my POV, in that Action 
>>and InitAll receive 'view' and perform actions on it.  In the ideal 
>>situation, InitAll would be replaced by e.g an events.Value subscribed to 
>>by the GUI.
>
>As i said this design is 10 years old. Now its time to refactor it using
>PEAK.
>
>I experimented with view as Observer and showing same model in many
>windows is something that we use in our latest releases. This way
>InitAll stays but is called from view only, no internal calls to
>InitAll are allowed. Maybe an events.Value should hold the object (m) and
>all views should call m.InitAll(self)?

What I'm saying is that instead of having mapping items in the view like 
'data' and so forth, those items would be exposed as values on the model, 
and subscribed-to by the view.  In order for the mapping to be of any use, 
obviously the view has to know what they correspond to, so it's just as 
easy for the view to pull them off the model and subscribe to any of them 
that are needed.  Using your current design, you could literally just 
subscribe a function that calls the view's __setitem__ in order to keep the 
current implementation.  Thus, there's never a need for an InitAll().  Does 
that make sense?


>>  And I'd tie the buttons to methods rather than using the 100+digit ID 
>> values, since if I understand correctly, those IDs have to be chosen to 
>> suit the GUI layer.
>
>In test_calc.py number IDs for buttons 0-9 are because i am lazy. They
>are not necessary and can all be replaced by event names as is done for
>'add' and 'sub'. IMO routing from events to actions is task that not
>always involves method call as first step e.g. Taskmaster pattern sends
>all events to state machine which then generates some method calls.

Sure, but either the state machine is pure UI, or else it's part of the 
model.  If it's in the UI, sure, let the view manage the state machine and 
call the model when a model-level action is required.  If the state machine 
is part of the model, then do that.  The point is just that the model has 
no business interpreting UI events; it should just ultimately receive model 
method calls.  Thus, there's no need for an Action() method.


>>Indeed, I'd do away with 'Action' and 'InitAll' altogether, because 
>>they're both artifacts of the GUI.  But apart from that, yes, this is 
>>very similar to the concept I proposed here.
>
>Main use of Action( view, .. ) is to call view.AttachFrame(..) to open new 
>windows.

I think this could be handled by some sort of "ui.show(anotherModel)" 
operation, perhaps with some options.  But, it's actually more likely that 
this will be handled by views on command objects, because otherwise it 
would be difficult to handle "modal" windows in a web UI.  That is, there 
can't be a function called by the model to get input, because the model 
should receive input in the form of command instances populated with 
parameters.  The UI framework should handle finding and presenting a view 
for the command object, and then executing the command once the input has 
been obtained.


>  Not sure about InitAll, its responsible for reconfiguring UI too.

How do you mean?



>Here is better example (still not using subscription). What is the English 
>name of concept represented by CalcXXX?

I don't know; I wouldn't split the two up like that.  I'd make the 'oct' 
flag an events.Value on the model, and subscribe to it from the view.  I'd 
probably also make a 'display' attribute (also an events.Value) on the 
model that was the string to be displayed (decimal or octal).  The action 
mappings (digit->digit(), add/sub/etc.) I would put on the view, as calling 
methods or issuing Commands of some kind.  (Where the Commands call the 
model methods.)


>Niki Spahiev
>P.S. I would like this design to be compatible with Web.

The tricky part of doing this with the calculator would be keeping track of 
the state (a,b,sign,oct).  Sessions are a classic way of handling this, but 
for some web applications it would be preferable to put this information 
directly into a cookie, or into the URL or form data.  This suggests that 
models may need to be able to provide a (possibly structured) memento of 
their current state.