John wrote:

> 
> You need to look into a concept called MVC - it stands for 
> Model/View/Controller.
> 

I've looked at that in the sense of reading about it.  But general 
concept isn't so specific about separating the "view" from the other 
parts.  As an example of a specific issue, suppose the "view" has a 
window with fields X,Y, Z.  When the user changes Z, we want X and Y to 
be updated.  I suppose the idealistic approach would be for the view to 
tell the controller to update Z and inform the view about the new X and 
Y.  The server-client or "communicating processes" implementation of 
this would make it clear that the "view" is, in some sense an 
independent entity.  But one could take the single-process approach and 
made the "view" a gui which treated the model and controller as a set of 
functions to be called at appropriate times.

The "communicating processes" way seems to carry a lot of overhead with 
it.  On the other hand, I've thought of schemes with even crazier 
amounts of overhead.  When I think about a system of gui's abstractly it 
seems to consist of "windows" and in these windows are various visible 
things.  Some are passive and merely display information.  Some take 
inputs.   Others can be activated and cause further windows to appear. 
So I think of the abstract architecture of a gui as something like the 
typical display of a tree (like the Windows registry keys).  The folders 
are abstract windows.  I ignore anything about their position, size etc. 
I merely think of them as an abstract data structure.  Each is either 
"active" or "inactive".  The things on them are not specified by any 
appearance (like "button" or "radio dial" ) or any geometrical location 
in the window.  They are merely described by the type of data they 
display or input.  So the idea would be to create the abstract 
architecture of a gui.  Then one could interface various real gui's with 
this to implement something useful.   For example, in one interface the 
field that displays X and Y might be a text field, in another interface 
it might be a two thermometers, etc.

This is such a nice concept but it also seems like so much trouble that 
I doubt anyone will every bother to do it.

It also does not solve what I find most irritating about the coding of 
guis.  Namely that it is laborious to make changes in what component is 
a child of what other component.   One thought for a gui designer is 
simply to build into the gui writing system the feature that when a 
certain global variable, say, "DESIGN_STAGE" is 1, then each component 
can be selected (perhaps by the awkward ALT-TAB way of moving focus) and 
caused to pop down a little menu that says "Edit Me" and offers the user 
options to modify it.  It should be easy to change things that are 
parametric.  For example to change the size or color.  But it would be 
harder to change the type of the component (say from button to check 
box). It would be very hard to implement moving a component from one 
parent object to another parent object.  As far as I can see, in the 
current systems for writing GUIs, this would amount to a recode and 
compile on-the-fly.  I suppose this is what GUI design programs must do, 
but a self-designable gui system would be doing this to itself.   I 
don't know what computer science it would take to make moving child 
objects from parent to parent possible, but I would like to see a system 
of writing GUIs where this was easy  (thus making the dream of the 
built-in gui designer possible).


-- 
Posted via http://www.ruby-forum.com/.