RFC: GUI Library Task Force

[Ashley Yakeley]

At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote:

> *** The GUI Library Task Force Strategy Proposal ***

It's worth pointing out that I'm covering much of the same ground with my 
bridge to the Java VM.

http://sourceforge.net/projects/jvm-bridge/

Of course there are differences:

>* Development of a GUI library API for Haskell that is
>  portable across Haskell systems and operating/windowing
>  systems

Same.

>* The library focuses on graphical *user interfaces* (ie,
>  buttons, menus, scrollbars, selection lists, etc) as
>  opposed to drawing and animation routines.

Java has APIs for both, I believe.

>* Verification of the design by at least one implementation
>  of a library that exports the GUI API

This has already been done for the Java APIs.

>* Minimal use of features that are not included in Haskell
>  98 (in fact, we currently believe that we can keep the API
>  completely free of any non-H98 features; however,
>  application programs that use the API will need some
>  non-H98 functionality)

I admit I am using some non-H98 features... in fact right now I'm working 
solely with GHC.

>* While we do not require support of concurrency by Haskell
>  systems implementing the API, the use and behaviour of the
>  API must be well-defined on systems that do support
>  concurrency

I will be using Java's threading. This means the Haskell system needs to 
support concurrency.

>* Core library:
>  - Due to the complexity of modern GUIs, we cannot hope to
>    cover a fully-fledged GUI library in reasonable time and
>    with reasonably effort; thus, we concentrate on a core
>    library (what exactly constitutes the core remains to be
>    defined)

Inasmuch as the AWT/JFC/Swing counts as 'fully-fledged', I will have it.

>* Openness for tools support; for example, it should be
>  possible to support graphical interface builders (such
>  tools are not part of the API, but we need to ensure that
>  we do not seriously complicate the construction of such
>  tools)

Same.

>Non-goals
>~~~~~~~~~
>* We will not design a fully-fledged GUI library from
>  scratch: 

Hopefully, I will be simply picking up a fully-fledged GUI library.

>* We will not design a "purely functional GUI":

Same.

>The Plan
>~~~~~~~~
>* Handling of state altered by both the application and by
>  GUI widgets:

I'm not sure what the issue is here.

>* Start from the API of GTK+ as a base line:
>  - This is an API that has a proven track record of being
>    suitable for small, medium, and large-scale applications

Same for Java. I think.

>  - The API does not overly rely on object-oriented language
>    features

This is the biggest sticking point for Java. The JVM-Bridge will allow 
you to create and load Java classes at run-time, even then, this may turn 
out to be complicated for the user.

>  - A large body of free documentation exists for the API,
>    which can be adapted to our purpose

Same for Java.
http://web2.java.sun.com/docs/books/tutorial/

>  - A working Haskell binding exists that can be extended to
>    provide a first implementation of the Haskell GUI API

I don't have anything usable yet. The JVM-Bridge will have to be 
code-complete before it is usable.

>  - GTK+ itself is already reasonably platform independent

Same or better for Java.

>* Ensure platform independence:

Same.

>* Haskell-ise the API:
>  - C-ish functionality will be cut out
>  - Full use will be made of Haskell's type system and, in
>    particular, type classes

Same.

>* Convenience libraries
>- The API will include a set of convenience libraries on top
>  of the basic API (eg, by providing layout combinators)

A straightforward addition, but not part of my core effort.


-- 
Ashley Yakeley, Seattle WA