[mercury-users] GUI Toolkits and Mercury

[Ian MacLarty]

On Wed, Nov 23, 2005 at 01:14:29AM +1100, Julien Fischer wrote:
> 
> On Tue, 22 Nov 2005, Jonathan Morgan wrote:
> 
> > What is the state of GUI toolkits under Mercury?  In the extras distribution
> > there is an X binding (not really portable to Win32/Mac OS X),
> 
> It certainly works on Mac OS X, assuming you have X installed on your
> machine.
> 
> > a binding to
> > OpenGL and GLUT and a binding to Tcl/Tk.  This last one is probably the only
> > widget-style set here that is cross-platform and commonly used.
> >
> > All these seem to be for C backends only.  What would be used for IL/Java?
> > Would you use C#/Winforms or Java/Swing?
> 
> Most probably.
> 
> > Is there any kind of Mercury
> > binding for these, or would you just use existing tools to generate pure
> > Java/C# files calling Mercury functionality?
> > Are there any plans to make a binding to a cross-platform toolkit apart from
> > Tk (eg. wxWidgets, Gtk+)?  Are there plans to make native Mercury GUIs
> > available for multiple platforms (eg. IL/Java/C)?
> >
> > My feeling is that mtk might be able to be ported to IL/Java with
> > comparative ease, as it is almost entirely pure Mercury, and you would only
> > need to bind mtcltk to a Tcl binding like tickle-sharp or Jacl.
> >
> > In terms of features, power, and native support for various platforms
> > wxWidgets would probably be best for Win32 and Mac OS X, while Gtk+ would be
> > best for X (wx binds to Gtk+, but I'm told that native Gtk applications
> > generally look better).
> 
> We were considering a binding to wxWidgets.  Indeed we even offered it as an
> honours project this year but there were no takers amongst the students.  As
> you point out below, the major disadvantage of wxWidgets is the necessity of
> writing Mercury-C-C++ "glue" code to join all the bits up.  In practice it
> would probably be possible to extend the foreign language interface to
> generate a lot of the glue code automatically so it wouldn't be that bad.
> 

wxWidgets is not yet mature enough on Mac OS X.  Even the supplied samples
exhibit bugs that make it a bad choice for any serious GUI
application.  I'm sure the Windows version is more stable, but for a
cross platform GUI I don't think it's quite up to scratch yet.

I think the idea of having one GUI library for all platforms is a
mistake, at least for developing non-trivial GUI application.  Each
platform has its own unique culture and way of doing things.  If you
want to make a serious cross platform GUI application then it should
respect the conventions of each platform -- this means more than
simply making the widgets look different on each platform.  For
example on Windows there is usually a menu bar per window, while on
Mac OS there is one menu bar per application (which might consist of
several windows).  Another example is that on Windows it is customary to
have an Apply button on dialog boxes which causes any changes to be
applied.  On Mac OS any changes to a dialog normally have an immediate
effect.  There are many other differences which would be difficult to
automatically port.

Julien and I have been working on a GUI framework which would
clearly separate out the logic of the program and its presentation.
In our model the programmer defines a mapping from the state of the
program to a presentation.  Different mappings can be defined
for different platforms.  The mapping could be to a traditional GUI,
html representation or even a text-based terminal representation.
Programmers could port their applications to different platforms by
defining different state-to-presentation mappings that would take
account of all the idiosyncrasies of each platform.

We hope to implement this framework as soon as we get constructor
classes.

Of course we'd still have to define bindings to each GUI we want to
support, though I think the APIs we bind to should be platform specific
so we can take advantage of all the features of each platform.

Ian.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------