gutopia-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rgui-dev] About output (thoughts)


From: Tom Sawyer
Subject: Re: [rgui-dev] About output (thoughts)
Date: 20 Aug 2002 15:12:21 -0600

On Thu, 2002-08-15 at 20:15, Massimiliano Mirra wrote:
> The meta controller [term (c) 2002 Tom Sawyer :-)] will, at one point
> or another, have to poll information from the model that must be
> presented to the user.
> 
> The meta controller would not know whether the message has to be
> written to stdout, to a requester, to a log, and whether it should be
> written in big or small characters, black or read, or the name of the
> application should appear along with the message.  In short, it would
> not know the style and means of the output.

this is a good idea. i think the current code accomplishes this to some
degree. we'll have to see just how far we can take this.

> However it would know things such as the type and the importance of
> the output, e.g. error message, warning, data result.

not sure how this would fit. as it stands all bindings have the same
degree of importance and are proccessed merely in the order that they
happen to be in. it happens pretty fast though, so i don't know how much
precidence will need be considered. let us move forward and if this
proves necessary later then well back up and put it in. unless i'm
missing something here? 

> I propose that the meta controller package every output message in
> descendents of an OutputMessage class, such as ErrorMessage,
> WarningMessage, ResultMessage, DebugMessage...  Then, based on runtime
> parameters, the backend would decide how to present that message.  If
> the application is running in a console, a DebugMessage might be shown
> on stderr or logged or both; if it is running in a window system, it
> might be shown in a text widget.

now this is another good notion. there has been some consideration of
eventually implementing a communications layer between the GUtopIa
metaVC (View + Controller) and the Backend via a TCP/IP socket layer.
having such classes may be instrumental to this.

we need to discusss this more. at this point we are at the stange of
getting into the nitty-gritty of the GUtopIa API. we have to consider a
couple of things: 

how does the coder work with GUtopIa? via code as the prelimenary
example presents, or via markup (something i've been considering more
lately). 

then at the level just below that, how does this get communicated to the
backend. currently the backend is represented by a single Platform class
(for each GUI type: FOX, GTK, etc) to which messages are transmitted.
such a class should be easily "wrapped" via DRb or other rpc mechinism.

what considerations/thoughts do you all have toward this?

~transami





reply via email to

[Prev in Thread] Current Thread [Next in Thread]