[mercury-users] GUI Toolkits and Mercury

[Jonathan Morgan]

Ralph Becket wrote:

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

I still think Tcl/Tk is probably your best bet (in terms of simplicity), as
it only requires a binding to a few Tcl functions.

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

I was under the understanding that Julien was saying that there were
problems complicating the writing of any binding, not just a declarative
binding (I would write them as two separate libraries).

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

So how would you improve that, since I think all modern GUIs are call-back
based?  Anything built on them would have to be call-back based at some
level.

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

Game design is not interested in multi-tasking - try running a make or two
at the same time as a demanding game.  This leads onto the point that
command line tools, if they can be used properly and effectively, are almost
always more efficient than GUI tools, as well as the fact that they can be
automated in a way GUI tools can't.

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

It depends on how long it takes to re-compute everything.  If every
application has to re-compute everything, it might drag terribly if you have
a lot of applications.

Jon

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