[mercury-users] GUI Toolkits and Mercury

[Jonathan Morgan]

Ian Maclarty wrote:

> On Wed, Nov 23, 2005 at 01:14:29AM +1100, Julien Fischer wrote:

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

The Windows version looks good.  The Gtk version looks fine, but I'm told it
doesn't look "native" enough - and it certainly doesn't have GNOME
integration.  I don't Mac OS.
> 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.

Agreed, with the caveat that many users will not notice the difference (it
depends on how marked it is).  Also, if they really like the application,
they might prefer to have a "semi-native" wxWidgets/Gtk/Tk port than writing
their own GUI for the program.  As well as that, programmers are often not
particularly good at designing their own UIs to be consistent anyway.

There is a semi-standard for developing cross-platform applications
(especially targeted at wxWidgets) at http://wyoguide.sourceforge.net/ -
I've never read it myself, but applications that follow it might be better.

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

Sounds good, but it could end up a lot of work (especially if you also want
to provide support for the .NET and Java backends).  It also raises the
question that cross-platform toolkits raise - are all items in different
OSes mappable onto each other?  Can you write an application, even with such
an abstract library, that will look good both on text, HTML (which in .NET
becomes more like WinForms), and GUI?  If you can, will it be lowest common
denominator, and thus non-competitive with other "native" solutions?

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

One reason why the various toolkits mentioned are around is because it is
often harder to use the native API, and trying to maintain multiple copies
for different OSes is even worse.

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