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

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Actually, I just gave in to temptation again and installed the latest
> Windows GDK; Glade is a bit of a mess.  Background windows pop up when the
> mouse moves in other windows, menus are left hanging etc. My suspicion is
> that this is caused by trying to map the GTK signal structure onto the
> Windows event loop system.
> 

OK, so glade on windows is only part there, I take it.  What is really
central is whether libglade can open up a glade-output xml interface
on windows, which might be somewhat less onerous.

Did a little searching for the opinions of others.  Thought this ruby
user's summary was perhaps most relevant for us:

http://www.wonko.com/content.php?id=301

wxwidgets has the native 'look and feel', but glade is 'By far the
easiest to use'...  To me, we are far from being able to design high
quality gui's, let alone contribute to the cross-platform gui
development model.  All we can hope for is passable, serviceable, and
cross-platform, I'd think.  With these resources, ease of use appears
paramount. 

There is also wxglade, but this appears in its infancy, and it is
unclear if there is xml/libglade support:

http://wxglade.sourceforge.net/

Needess to say, if it proves to be as functional as glade, this is
definitely the way to go, at least in the long term.  Don't have time
to investigate right now, alas. 


> | Amen.  KDE users on Linux have been making fun of GTK's file selection
> | for a very long time - it's improving in the most recent versions but I
> | still find it a tad iffy at times.
> 
> Even on Linux running on a really fast box X always feels slow to me after
> Windows.
> 

Fair enough, but in the absense of some well-polished, very easy to
use, open source, massively exercised, cross-platform alternative,
this would appear the least of our concerns at this juncture. 

Whatever we choose will be less than desirable -- what we need is to
select wisely given a carefully chosen set of priorities.  

> | > The only major GTK applications I'm aware of on Windows are Glade
> | > and the GIMP which means that a large segment of GTK is presumably
> | > largely untested on Windows.
> |
> | This is my sense too - I know a few other GTK applications have been
> | ported but I do not have the sense it is a major movement.  Hence my
> | excitement at GPL QT4, which up until version 4 was commercial ONLY on
> | Windows - indicating it must work reasonably well.  With any luck an
> | McCLIM backend to that could be made to work well and reliably on both
> | platforms.
> 
> 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.

Here are my summary opinions at this point -- feedback most
appreciated!  (Just a note of clarification -- tcl/tk, which exists in
GCL now and is a portable scripting language, is *not the same* as
GTK+, an extremely widely used C library with multi-language bindings
running 'in-process')

=============================================================================
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)

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

=============================================================================
Goal: generic GCL gui  -- long term
=============================================================================

   Choose an in-process gui option according to the following ranked
   priorities:

        1) open source

        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

        3) universally portable

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

        5) native 'look and feel'

        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. 

        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.

    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.  

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

=============================================================================

Goal: portable axiom hypertex

=============================================================================

This would appear best served by Bill Page's browser idea with GCL
server sockets.  For now, I will work on providing
fork()/CreateProcess() options, and select/stdio multiplexing options,
to the si::socket function call.  We will postpone threads unless
someone wants to volunteer some work here.  The windows fork() analog
of CreateProcess() will require some work in this context, as
basically the code will have to save the server function in a .lsp or
.o file, and restart gcl or axiom with a command line instruction to
load and execute the file (or do same with pipes).  I suggest we don't
bother working on this again unless we have a confirmed user -- axiom
might be serviced by the user invocation and/or stdio multiplexing
options.  But fork() is a great option to have on Linux, so we should
put it in, IMHO.

=============================================================================

Goal: portable axiom graphics

=============================================================================

This is unlikely to be well serviced by a web browser, and only
modestly well-serviced by a standard gui, as axiom's demands on plot
manipulation are likely to require such detail as canned 'widgets' are
unlikely to be available.  I really feel gnuplot is the best tool here
in the medium term, which can be fully accessed cross-platform under
GCL at the present time via run-process.  Please check out the maxima
webpages for soem very pretty pictures (aka dazzling eye candy :-))!

=============================================================================

These are just my thoughts, of course.  Feedback always most welcome!

Take care,

> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah