Re: GUI's and the Rouge, Part III (yes, finally) 1/2

On Tue, 2002-07-23 at 19:07, Clifford Heath wrote:
> Tom Sawyer wrote:
> > it was stated that a main goal of Rouge was to create a cross-compatible
> > gui api that "boiled down" into the native gui of each platform.
> 
> As you've found, it's a *major* piece of work. I should know - I designed
> and my company built such a product (called OpenUI) in the 1st half of
> the 90's. There are better toolkits out there for this now, of which I like
> Qt and fxruby best. You definitely shouldn't build your own, it's a problem
> that needs multiple hundreds of thousands of lines of code to solve.

interesting OpenUI...well i'm not really building my own. i'm building a
layer on top of pre-existing api (ClanLib). wouldn't really consider
writing it all from scratch.
 
> > i think too that this is a fantastic idea.
> > so that's the final piece and we end up with basically this:
> 
> You've described the architecture of OpenUI, but perhaps haven't understood
> the factor that makes it really work: rich asynchronous message passing.
>
> I'm still of the firm opinion that this is the single integrating feature
> which is needed to revolutionise GUI programming. Message delivery needs
> to be based on hierarchies of objects, including propagation of undelivered
> (or partly-delivered) messages up the hierarchy, publish-subscribe propagation
> down the hierarchy, and proxy-address mapping for remote objects. Add that to
> the basic queueing facilities needed for asynchronous delivery, with a
> priority-nesting feature to provide some minimal sequencing control for
> consequential messaging (needed for remote validation for example), and you
> have an exceptionally powerful and flexible application framework supporting
> separation of presentation and semantic content to the fullest extent possible.

rich asynchronous message passing. does it really need to be that
"fancy"? perhaps. the communications layer is optional, but i tend to
think standard tcp/ip + marshaling might do the job. after all networked
games these days don't use much more. (i think). if this part proves too
much of a bottle neck we can either do without it or hopefully pull
together something more like what you describe. ClanLib also includes
some networking features for netowked games. perhaps that would be
useful.

> The native GUI widgets should be assembled into hierarchies not by API calls,
> but by a hierarchical description language - XML probably. In fact I started
> making "qtml" - a Qt markup language, which allows simple assembly of arbitrary
> widget hierarchies (UIs), and embedded scripting to animate and control the UI.
> I'd love to use Ruby with this, it's the most suitable language for the purpose.

well, i disagree here. i thought about that option: whether the models
should be in markup versus executable code. i went executable b/c we can
always make markups that "compile" into the transaction code. but you
may be interest in a little program that i threw together that builds tk
interfaces from xml. i've attached it. you'll need rexml to run it and
you may need to tweak the require statements. tkxml-l.rb is the simple
example.
 
> Sorry that much of the above discussion is kind-of schematic, incomplete and
> probably confusing, I can discuss the ideas further if they ring anyone's
> bells. Suffice it to say that people who've used these ideas in the form of
> our (now obsolescent) product have found them to be truly revolutionary.

no apology required. thanks for the comments. i'm interested to know
more about OpenUI and if you should decide that you could contribute to
the project please let me know.

~transami