[mercury-users] GUI Toolkits and Mercury

[Ian MacLarty]

On Wed, Nov 23, 2005 at 04:01:23PM +1100, Jonathan Morgan wrote:
> > 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?
> 

The point is that you map the state of your application to different UI
elements depending on the platform.  For example you might map a boolean
value to a tick box on windows, a radio button on Gtk and to a 
drop down list in html.
This gives you the freedom to make use of different platform specific
features (such as transparency on Mac OS, or the system tray on Windows)
without tying the application to one platform.
It also means you can make the application feel like a Windows app on
Windows and a Mac app on Mac, since it links with the native library
on each platform and is customised to each platforms conventions.

This is more work, but I'm sure most of the common code could be
factored out.  It depends on the application - if it's just a few
simple dialogs then a write once, run anywhere approach is probably
best, but if it's a more complex GUI application, then you'll want it to
look and behave differently on each platform.

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

That's a good point, though I would think native APIs like Win32, Carbon 
Xlib etc are pretty stable by now.  I'm not sure if we'd want to use
these directly or use other higher level, but still platform dependent,
toolkits.  I guess it depends on the 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
--------------------------------------------------------------------------