This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: separating user interfaces


Telford Tendys <telford@eng.uts.edu.au> writes:

> > Of course you could trim it down.  The reason it tries to cover
> > everything is because it is intended to be a proper and complete
> > solution, and not a 80% solution.
> 
> This is one philosophy that I (as an engineer) have a big problem
> with. There IS NO 100% complete solution. Whatever you do will be
> a compromise in one way or another, this applies to guile, to any
> library that you care to write and to any specification too.

I said it tries to be a complete and proper solution, not that it is a
100% solution for the entirey of it's supposed problem space.  In
other words, it put completeness above simplicity and ease of
implementation.  This is quite different from say, Tk, or DBI, or
various other libraries.  For this reason it can seem a bit baroque,
but that is not the same as broke. 8)  It is also a respectable
engineering philosphy.

> > It is conceptually clean, can be
> > broken down into various substrates, and provides for expansion and
> > customization.
> 
> I like the bit about being broken down into substrates because that
> is what allows each implementation to decide its own compromise point.
> I'll chase up the postscript version and hopefully get a better idea
> of where the subdivisions fall.

Yah.  This is what I am in the process of doing in CL right now.  The
CLIM spec really just identifies the geometry substrate as an outright
substrate, and then you get a couple of other components which do not
quite fit nicely into substrates, but which can be simplified quite a
bit, although in reality they are not at all that complex.  The
various protocols in CLIM can be simplified.  

For instance there is no need for the Region Composition Protocol if
your dealing with just non-overlapping text windows.  The ink and
drawing can definetly be simplified out, as can various other aspects
of the unique output mechanisms it provides.  Then there are gadgets
and various things which are built on top of the lower levels, the
equivalent of widgets.

> Well when it comes to actual working code, less code that does the
> job is better than more code that does the job because it uses less
> memory and runs faster -- so brevity is good without a doubt.

I don't see how you support this direct relationship between code size
and resource consumptions.  But it's kinda unimportant in the scope of
the immediate topic, guile, and interface management.

> I see specifications as much the same thing. They don't directly enforce
> the implementation but they do have an influence on it. If I want a rough
> idea as to what to expect from a specification, I will look at a few
> implementations of that specification and get some judgement from that.
> Admittedly, it's not a totally fair test nor guaranteed to be correct
> but it does at least point in a sensible direction.

But the implementations are done with vastly different programming
systems than what we are immediatly working with.  The resource
consumption is such a minor issue in comparison to getting a nice
workable and extensible interface manager that can support text and
graphics without massive lossage.  I suggest we worry about this only
after you have a prototype coded up.