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