Re: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting

[C Y]

--- Camm Maguire <address@hidden> wrote:
 
> > If someone was planning (I'm certainly not) to write a cross
> > platform backend to McClim I personally would be telling them 
> > to use WxWidgets, which has been connected up very nicely in both 
> > the Scheme and Haskell worlds and is much lighter weight than GTK 
> > while retaining good cros-platform performance and appearance.
> 
> The scheme hooks you mention argue strongly in wxwidgets' favor, of
> course.

Would scheme bindings to wxWidgets translate well to lisp?

> ===============================================================
> Goal: generic GCL gui  -- short term
> ===============================================================
> 
> 1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
>    working on all platforms as quickly as possible (Need feedback
>    from Mike and/or Bill)

Agreed.

> 2) make sure gcl-tk can display bitmaps (I'll take care of this)

Cool :-).

> ===============================================================
> Goal: generic GCL gui  -- long term
> ===============================================================
> 
> Choose an in-process gui option according to the following ranked
> priorities:
> 
>  1) open source

  Agreed.

>  2) massively exercised in the open source world, which for
>     all intents and purposes means the core C libraries used 
>     by the open source desktops with a thin lisp binding 
>     option

  Well, QT is actually C++, but if you mean GTK and QT are 
  the two most attractive "back end" toolkits I agree.

>  3) universally portable

  There are two ways this can work:
  a)  Back end toolkit is ported to all platforms.
  b)  Interface logic written in Lisp toolkit which has working
      bindings to different toolkits on different platforms.

>  4) easy to use, preferrably with a graphical gui builder.

 For GTK there is glade, for QT there is QT Designer.  AFAIK
 both are quite good.

 Interestingly, Craig Lanning mentioned yesterday on the McCLIM
 list that he had written a CLIM interface builder some years
 ago.  If it still works and he is willing to contribute it that
 might help make McCLIM more attractive on the lisp level. Garnet
 did have a UI builder but IIRC it had bugs and I never really 
 got the hang of it.
 
>   5) native 'look and feel'

  This is a major drawback for GTK on Windows.

>   6) supports the option of a higher level lisp layer like
>   mcclim.  This to my understanding can just be layered on
>   top of a thin lisp binding layer. 

That's the theory I guess, although current McCLIM and Garnet bindings
seem to be below toolkit level if I understand correctly.  (clx, and
the experimental MacOSX Beagle backend for McCLIM).

>   7) lgpl better than gpl.  Just to be clear here, if qt4 is
>      selected, all apps using this will be GPL when distributed
>      in binary form -- Mike Thomas has voiced reservations
>      about this in the past, but it doesn't particularly bother 
>      me.

Mike?  Would that matter?  If the source code to Axiom+Interface itself
is more liberal, does the binary version being GPL when using QT matter
particularly?  

>  We should not do any work on this, IMHO, unless we have a
>  confirmed user of such a system.  As I state below, axiom and the
>  other systems currently using gcl might be more easily serviced
>  in other ways.  

Uh - you mean we should wait until someone develops a working GUI to
build on?

>  My feeling is that depending on wxglade functionality, this would
>  result in wxwidgets > gtk+ > qt4

I guess I would disagree - my take on it would be (McCLIM+qt4) >
(McCLIM+wxwidgets) > (McCLIM+gtk+) > qt4 > wxwidgets > gtk+, based on
the following assumptions:

QT4 is more likely to be robust on Windows than either wxWidgets or
gtk, since one of trolltech's major revenue focuses is to sell
commercial licenses to Windows developers - they will be able to bring
more resources to the problem.  On Linux this wouldn't tend to worry me
as much, but in the case of Windows I'm more inclined to trust QT to be
robust, and behave as Windows users expect in the look and feel
department.  (That's just my personal opinion, not experience, and as
such deserves little weight.)  QT works on Windows, Linux, and Mac.

wxWidgets is itself a layer on top of other toolkits, at least on
Linux.  I'm not sure what it does on Windows, although presumably it
uses the "standard" Microsoft APIs.  I almost view wxWidgets as a C++
McCLIM from the standpoint of how it relates to other GUI libraries. 
My take on it is that bugs would be easier to track going from McCLIM
to QT or Gtk+ directly than McCLIM->wxWidgets->Gtk+ on Linux, although
that might not be true in practice.

gtk+ won't have a native look and feel on Windows, and I'm not sure
about its status on the Mac (anybody know?)  There are stability and
robustness concerns on Windows.  

Overall, (McCLIM+anything) or (Garnet+anything) is better than not
writing the UI in Lisp, IMO.  Having all user interface code in one of
these toolkits allows flexibility in toolkit choice, based on what
backends are available or are created in the future.  If available, one
could bypass the extra toolkit and do McCLIM+Win32GPI, or
McCLIM+Beagle, and get a totally native behavior without requiring QT. 
QT would essentially be written as a backend to be used until all
platforms of interest have solid McCLIM backends.  (On linux, of
course, in KDE you would want McCLIM+QT to fit with the desktop, and
McCLIM+Gtk for Gnome.)

But as always, proof is in the pudding.  I'll try playing around with
McCLIM when I get the chance and see if I can recreate the axiom
hypertex start page (I got it to run last night, and I had forgotten
how basic it is.  I'm going to be embarassed if I can't figure this out
eventually :-)

CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com