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


On Mon, Jan 25, 1999 at 10:48:52PM +0100, Klaus Schilling wrote:
> 
> What is the most efficient way to provide a user interface for a guile-based
> application in a non-monoloithic way, i.e. it should be possible to replace 
> the user interface without recompilation? 

I kinda had an idea about this which was to build a small but monolithic
program that supports a cut-down scheme plus a graphics library. It would
then use sockets and scheme commands to act as a front-end terminal for
scheme applications, probably it would run some simplified repl.

The cut-down scheme in the terminal application could be quite simple,
I would say integer-only maths without complex support should keep the
weight down, also no From owner-guile@cygnus.com  Wed Jan 27 22:50:36 1999
Received: (from majordom@localhost)
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id UAA13799;
	Wed, 27 Jan 1999 20:55:16 -0800 (PST)
Received: from holly.ee.uts.edu.au (holly.ee.uts.edu.au [138.25.40.38])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id UAA13793
	for <guile@cygnus.com>; Wed, 27 Jan 1999 20:55:09 -0800 (PST)
Received: from triangle.ee.uts.edu.au (telford@triangle.ee.uts.edu.au [138.25.41.162])
	by holly.ee.uts.edu.au (8.9.1/8.9.1) with ESMTP id PAA08050
	for <guile@cygnus.com>; Thu, 28 Jan 1999 15:55:57 +1100 (EST)
Received: (from telford@localhost)
	by triangle.ee.uts.edu.au (8.8.8/8.8.8/Debian/GNU) id PAA04121;
	Thu, 28 Jan 1999 15:56:39 +1100
Message-ID: <19990128155638.06695@localhost>
Date: Thu, 28 Jan 1999 15:56:38 +1100
From: Telford Tendys <telford@eng.uts.edu.au>
To: guile@cygnus.com
Subject: Re: separating user interfaces
References: <m104tsK-000VSzC@debian> <19990127144613.18011@localhost> <874spdcg3g.fsf@piracy.red-bean.com> <19990127193719.63611@localhost> <87yamobmw7.fsf@piracy.red-bean.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1
In-Reply-To: <87yamobmw7.fsf@piracy.red-bean.com>; from Craig Brozefsky on Wed, Jan 27, 1999 at 10:18:00AM -0800
Sender: owner-guile@cygnus.com
Precedence: bulk

> 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.

Some user may decide that the only acceptable text for their application
is a multicolour font done with an airbrush (so no two characters
are exactly identical) and exhibiting a sparkling shimmer while the text
lines undulate slightly. There probably are some graphics cards out
there which can actually produce such a monster and some game
designers who would see it as desirable. That doesn't mean that
an interface specification should support such fonts, you just tell
the user to use a bitmap because what they are asking is too
unusual. There will always be a point where you have to say,
``beyond the scope of this...''

The question is merely a matter of where to draw that compromise.

> 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.

In my ideal world, about 10 functions should be enough to pop up a window,
put down some line drawings with a bit of text around them and give some
buttons for the user to press. Font's, colour-maps, window geometry,
layout, etc should all be able to get reasonable default values without
any effort on the programmer's part or the user's part. Chapter one
of the specification should say, ``here are these 10 functions, use
them and get your application going, we will worry about the rest later''.

An implementation that just supports those 10 functions and ONLY allows
default values for everything, is still a workable implementation
(provided that it can gracefully decline when asked to do something
from Chapter Two).

> At the same time I
> wonder if you are confusing simplicity with brevity.  I find CLIM very
> simple and clean, considering what it is dealing with.  I hope that
> brevity in the guise of simplicity does not become the guiding
> principal of guile and it's various tool's development.

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.
When it comes to documentation, a little extra documentation is better than
too little documentation so brevity is not good.
I guess that brevity is easy to objectively measure and easy to recognise
while simplicity is a bit of a personal judgement requiring consideration
so I will agree that the concepts are different. However, I do usually
note a correlation between the two.

> What does memory consumption have to do with evaluating various
> concepts used to abstract up from the details of display and user
> interaction mechanisms? That is an implementation detail, and noone
> is suggesting that you implement straight CLIM for guile.  I suggest
> you put the horse before the cart.

Suppose I take a C program and compile it. The actual size of the final
executable is not specified by the program, you could think of it as
an implementations detail of the compiler that you use. No doubt some
compilers are more efficient than others but also some C programs are
more efficient than others. How much should a C programmer leave efficiency
issues up to the compiler and how much should be considered at the
programming stage? It's not exactly clear-cut...

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.

	- Tel