[Top][All Lists]

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

Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom

From: C Y
Subject: Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom
Date: Fri, 29 Apr 2005 12:52:02 -0700 (PDT)

--- Camm Maguire <address@hidden> wrote:

> Agreed on the complementarity, and the desirability of a common gui.
> Isn't this exactly what texmacs was designed to be?  What advantages
> over texmacs might accrue from implementing similiar natively in
> lisp? 

Well, off the top of my head the ones that come to mind are interactive
plots in mathematical documents and a much greater focus on CAS
specific GUI interaction mechanisms.  Then there is also being able to
extend Maxima's line breaking code to graphical displays, which is a
non-trivial ability for a math GUI to have.

In once sense, I suppose TeXmacs could in theory do all of this (and
I'd be cheering it on) but it seems like the greatest flexibility would
come from writing an interface, plotting library, etc designed
specifically to be an interface for Maxima and Axiom, rather than
embedding a math environment in TeXmacs.  It's possible the tradeoff
isn't worth it, but the nice thing about open source is that its not a
tradeoff :-).  We can have our cake and eat it too if we are so

> Agreed that no precise prediction can be made, but surely the likely
> contributers are a subset of dedicated lisp users, which, alas, are
> in short supply at present.  This is not to argue against the
> possibility for possible future renewed interest in lisp, but it 
> does, in my mind, argue for a tight lisp binding to a widely used C 
> library at the base, with mcclim as a higher level lisp option on 
> top.  Then we can lever both sets of users.

Agreed.  Save the Lisp Machines themselves all lisp graphics I'm aware
of are ultimately written on top of some other library (X, OpenGL, tk,
java, what have you.)  Since at the moment some intermediate library is
going to exist anyway, I agree a widely used one is a good idea,
although in theory McCLIM would allow us to have multiple backends if I
understand it correctly.  I don't see how we leverage both sets of
users except in the sense the underlying library is well tested - is
this what you mean?

> > With the exception of Garnet, which was used in some special
> > purpose apps long ago, McCLIM is the only of these toolkits 
> > where I do know of a program written using it - Gsharp.  There 
> > was also the Closure web > browser, although I don't know if that
> > has been maintained.  
> This is encouraging!  But I think we will agree that these few apps
> pale in numerical comparison to those directly exercising both the
> gtk+ and qt libraries.

Of course.  But the same could be said for Lisp in general.  And the
situation will never change if we all keep writing in bare gtk+ and qt
libraries - someone has to break the ice :-).  McCLIM is maturing, and
Axiom/Maxima might be just the applications to use to develop and
introduce to the world cross platform Lisp graphics.

> Mike has also mentioned the wxwidgets backend, which would appear
> attractive. 

My main concern with wxWidgets is that we are in effect introducing an
extra layer between the lisp GUI toolkit (if we decide to go that
route) and gtk/X/(Whatever windows uses)/Carbon/the other API on Mac. 
The main argument for wxWidgets is write once, run anywhere - I'm
hoping McCLIM+QT could be capable of the same thing, and perhaps
eventually McCLIM+native.  wxWidgets are effective though - wxMaxima is
an excellent tool for Maxima which is being written with this toolkit.
> Indeed.  By whom?  We will never match the testing that goes into
> gnome or kde.   So perhaps one option should be as close to these as
> possible, (with perhaps wxwidgets in between for windows), and then
> build mcclim for the power users on top of this.

That might work, but I would still prefer to write in McCLIM and treat
gtk/qt/wxWidgets as backend libraries rather than the primary coding
language.  But I think things get rather tricky at this level.  Time to
make a flowchart.
> This is well taken, but we should keep in mind that even any lisp
> solution will involve learning a completely new set of functions,
> which few people currently know.  If there were a large body of
> existing knowledge distributed among the contributors, this would
> be quite important, IMHO.

True.  But my hope would be that using McCLIM for this purpose and
extending its reach across platforms will help make knowing McCLIM a
very useful skill :-).  That's not the purpose of Axiom of course, and
not relevant to the decision.  But it's a nice dream.

> Here is the tradeoff between 'native look' and gpl'ed windows apps,
> which can in turn be resolved with wxwidgets at the expense of the
> massive user base.  Getting consensus on the priorities is the
> hardest part, but if you are doing the work, your priorities are 
> the ones thatcount :-).

Well, if we have both QT and wxWidget backends for McCLIM, and both
worked well, the user could in effect choose based on license.  I still
think writing a wxWidget backend for McCLIM is like writing a QT
interface for GTK, but perhaps I have that wrong.

Despite your kind words, my opinion is worth very little until I
actually produce useful code, so once I get the Maxima units package in
reasonable shape I'll start digging into McCLIM and backends and see
just what I'm actually proposing so glibly ;-).


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

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