[mercury-users] GUI Toolkits and Mercury

[Ralph Becket]

Jonathan Morgan, Wednesday, 23 November 2005:
> Julien Fischer wrote:
> > >
> > > 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.
> 
> So you would not intend to move .NET based Mercury code to non .NET
> backends?  This would seem to militate against the portability provided, at
> least in theory, by Mercury.

Mercury is not tied to any platform, although certain libraries may be.
We would certainly be glad to have a portable GUI binding, but as
there's no research funding to be had for such an enterprise this would
have to be done either by a third party or outside work hours.

> > 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.
> 
> Wasn't the honours project for developing a more declarative GUI?

Yes: there's nothing particularly challenging about just adding a
wrapper to an existing GUI library.  And as researchers, we're
interested in exploring better ways of building GUIs: current methods
are really pretty awful.
 
> Which ones?  Gtk has about the largest number of bindings of any
> library, including ones to declarative languages like Haskell and
> Erlang.  Could they all be wrong, or are they problems unique to
> Mercury?

Just because a Haskell binding exists doesn't mean it's a declarative
binding!  (e.g., if everything is done in the IO monad.)

Some of the problems with existing GUIs are
- they are strongly imperative in nature;
- they do not enforce separation of application and user interface;
- they are invariably call-back based, which places control entirely
  with the GUI (not good);
- because everything is event driven and each event is potentially of
  interest to a large number of callbacks (about which the GUI engine
  knows nothing) a vast amount of time is wasted passing useless event
  messages back and forth and triggering callbacks that do nothing.

You only have to compare the often sluggish responsiveness of something
like MS Word or Excel or Mozilla etc. (i.e., apps that are not doing a
lot of processing) with the superb responsiveness of any first person
shooter game (i.e., something that is squeezing every last cycle out of
the machine) to see that current GUI design has got it wrong.

The starting point of our current thinking of how a high performance GUI
might be implemented takes inspiration from these 3D games: on each
event, recompute *everything*!  You can then optimise things by only
rendering things that have changed from before the event.  We expect
this approach could really simplify many aspects of user interface
implementation.

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