Remove gui/poll.tex
authorIan Lynagh <igloo@earth.li>
Tue, 28 May 2013 22:55:06 +0000 (22:55 +0000)
committerIan Lynagh <igloo@earth.li>
Tue, 28 May 2013 22:55:06 +0000 (22:55 +0000)
It's not part of the report, and hasn't been touched for 10 years.

gui/poll.tex [deleted file]

diff --git a/gui/poll.tex b/gui/poll.tex
deleted file mode 100644 (file)
index 6ca19a7..0000000
+++ /dev/null
@@ -1,764 +0,0 @@
-\documentclass{article}
-
-\newcommand{\Party}[1]{\stepcounter{enumi}\arabic{enumi} \bf #1}
-\newcommand{\rationale}[1]{{\footnotesize\bf #1}}
-\begin{document}
-
-\section{Opinions}
-
-This is a collections of opinions on the general nature of what should
-comprise a GUI library for Haskell. This document is the starting
-point of defining a common GUI API, CGA for short. The CGA will be
-published in a separate document. The source of this summary is the
-GUI mailing list from January 2003 onwards.
-
-The following opinions are ordered by the first contribution.
-\begin{enumerate}
-\item[\Party{Simon Peyton Jones}] Opinion:
-
-  \begin{enumerate}
-  \item \label{allspj} want GUI library which is available on major platforms
-  \item want confidence in its continuity
-  \item \label{interspj} compromise to gain portability
-  \item \label{hinderspj} having platform specific bits is OK
-  \item \label{highspj} no yet: high-level design
-  \item \label{scratchspj} want specification of mid-level API before
-    discussing implementation details
-  \end{enumerate}
-
-  Proposal:
-  \begin{enumerate}
-  \item use Clean's Object I/O back-end
-  \item write a common API specification which has implementations on
-    different platforms, providing as much functionality as possible
-  \end{enumerate}
-
-\item[\Party{David Sankel}] Opinion:
-  \begin{enumerate}
-  \item \label{allds} platform-independence is of primary importance
-  \end{enumerate}
-  Proposal:
-  \begin{enumerate}
-  \item use Qt as guideline for portable widget set
-  \end{enumerate}
-  
-\item[\Party{Keith Wansbrough}] Opinion:
-  \begin{enumerate}
-  \item \label{interkw} want minimal API which can be implemented by
-    each toolkit
-  \end{enumerate}
-
-\item[\Party{Wolfgang Jeltsch}] Opinion:
-  \begin{enumerate}
-  \item \label{lookwj} look and feel of the native platform is
-    important, also in terms of connecting to additional functionality
-  \item GTK violates native look and feel even on Windows %30 Jan 2003
-  \item \label{lowwj} to achieve a native look and feel across
-    platforms, the common API needs to be at a higher level than the
-    veneer (L) level
-  \end{enumerate}
-  Proposal:
-  \begin{enumerate}
-  \item \label{langwj} write the low-level (i.e. imperative) layer in
-    C so it can be used from other languages
-  \end{enumerate}
-
-
-\item[\Party{Vincenzo Ciancia}] Opinion:
-  \begin{enumerate}
-  \item \label{lowvnn} adopt a rather high-level approach and map
-    existing back-ends to it, Object I/O level would be OK
-  \item Haskell should have free GUI back-ends (i.e.~not Qt)
-  \item \label{scratchvnn} design the standard API from scratch and
-    implement it with what is already there (e.g. the Gtk bindings)
-  \item ...but independent of the specific GUI back-ends
-  \item create the interface between the back-ends and the common API
-    in Haskell
-  \item \label{lookwnn} native look and feel is important
-  \end{enumerate}
-  
-  Proposals:
-  \begin{enumerate}
-  \item \label{docvnn} adopt an existing XML model as API or for parts
-    of it
-  \end{enumerate}
-
-\item[\Party{Bryn Keller}] Opinion:
-  \begin{enumerate}
-  \item \label{feelbk} Gtk is no good on Windows (at least version 1)
-  \item Qt and wxWindows would be alright on Windows
-  \end{enumerate}
-
-\item[\Party{Sengan Baring-Gould}] Opinion:
-  \begin{enumerate}
-  \item \label{highsbg} no working high-level approach available
-  \item \label{lowsbg} it's painful to work with the low-level veneers
-  \item \label{midsbg}wants a medium level approach like Object I/O
-  \item SWT uses a C layer which emulates widgets which the native
-    platform does not support, but it is possible to write platform
-    specific bits. Adopt similar technique for the common API.
-  \item don't use the C SWT layer directly, it's too thin
-  \item \label{dirtysbg} don't be afraid to emulate widgets if the
-    platform does not provide them
-  \end{enumerate}
-
-\item[\Party{Krasimir Angelov}] Opinion:
-  \begin{enumerate}
-  \item \label{lookka} want native look and feel
-  \item \label{dirtyka} ...but states how features not found on a
-    specific platform can be emulated and that it's OK to do so
-  \item \label{portka} Haskell's Object I/O library is too Windows
-    specific as it is (example: Scrollbars), furthermore there are
-    open design decisions (creation of identifiers, legacy Clean
-    communication model)
-  \item Standard GUI library needs different back-ends
-  \item \label{lowka} want low-level common API
-  \end{enumerate}
-
-  
-\item[\Party{Axel Simon}] Opinion:
-  \begin{enumerate}
-  \item \label{hinderas} want full-featured GUI capabilities
-  \item \label{allas} want portability (run everywhere)
-  \item don't want to reinvent the wheel in Haskell
-  \item want a standard GUI API soon
-  \item \label{scratchas} look at all back-ends before starting to define
-    an API that interfaces to them
-  \end{enumerate}
-  Proposal:
-  \begin{enumerate}
-  \item \label{lowas} write a mid-level common API to which people can attach
-    back-ends (based on Object I/O or GIO)
-  \end{enumerate}
-  
-\item[\Party{Adrian Hey}] Opinion:
-  \begin{enumerate}
-  \item Qt and wxWindows are hard to bind due to their
-    implementation language (C++), especially memory management
-  \item \label{lookah} doubt the native look and feel claim of Qt and wxWindows
-  \item \label{allah} don't care about look and feel, portability (runs
-    everywhere) is important
-  \item implementing widget in Haskell gives a more stable
-    back-end than using toolkits
-  \item using an imperative toolkit shines through % 24 Jan 16:09
-  \item \label{highah}no high-level GUI library yet
-  \end{enumerate}
-  
-\item[\Party{Antony Courtney}] Opinion:
-  \begin{enumerate}
-  \item \label{highac} don't define a high-level GUI API
-  \end{enumerate}
-  
-\item[\Party{Glynn Clements}] Opinion:
-  \begin{enumerate}
-  \item \label{lookgc} feel is very important for users
-  \item opposes to write GUI code specific to the Haskell library
-    (emulate widgets)
-  \item using a native-widget library means less maintenance for the
-    Haskell API
-  \item a sole document-level API is too inflexible in practice
-  \item the common API has to model the menu bar issue of Aqua
-  \end{enumerate}
-  Proposal:
-  \begin{enumerate}
-  \item create a library using the native platforms while adhering to
-    the native look and feel
-  \end{enumerate}
-
-  
-\item[\Party{Seth Kurtzberg}] Opinion:
-  \begin{enumerate}
-  \item impractical to have native look and feel by
-    rewriting a GUI library
-  \item define a general API on top of existing toolkits
-  \item obeying the native look and feel is quite difficult to do in a
-    portable way
-  \item do a thorough discussion before implementing
-  \item \label{scratchsk} easier to define more abstract API from
-    simpler ones than matching back-ends to more abstract APIs % Jan 24 16:48
-  \item \label{hindersk} it is OK that the common API has reduced
-    functionality but then it must provide means to use the platform
-    specific back-ends
-  \end{enumerate}
-  
-\item[\Party{Peter Achten}] Opinion:
-  \begin{enumerate}
-  \item \label{lookpa} native look and feel is important
-  \item \label{portpa} Object I/O (either version) is portable by
-    design and it should be possible to attach any back-end
-  \item \label{highpa} non high-level GUI APIs in functional programming
-    languages are still better than writing in C
-  \end{enumerate}
-
-\item[\Party{John Meacham}] Opinion:
-  \begin{enumerate}
-  \item \label{midjm} wants mid-level common API on top of existing bindings
-  \item \label{feeljm} points to an article
-    \verb+http://www.t4p.com/xplat.htm+ stating that there is no cross
-    platform API which delivers native look and feel
-  \end{enumerate}
-\item[\Party{Wolfgang Thaller}] Opinion:
-  \begin{enumerate}
-  \item native look and feel is important (especially: Mac)
-  \item \label{feelwt} there is no cross platform GUI toolkit which
-    delivers native look and feel
-  \item \label{lookwt} there are special properties of Aqua (menu bar,
-    quit menu entry) that need to be enforced by the API
-  \item \label{interwt} have a subset API which gives the native look
-    and feel on all platforms
-  \end{enumerate}
-\item[\Party{Simon Marlow}] Opinion:
-  \begin{enumerate}
-  \item \label{hindersm} need platform specific APIs for native look and feel
-  \item \label{intersm} want reduced common API for all platforms
-  \end{enumerate}
-\item[\Party{Daan Leijen}] Opinion:
-  \begin{enumerate}
-  \item wants a layer L between a mid-level API (like Object I/O) and
-    the bare veneer, because would mean we could share the work for
-    the medium layer
-  \item \label{scratchdl} let an existing API evolve than define one
-    from scratch
-  \end{enumerate}
-  Proposal:
-  \begin{enumerate}
-  \item Ports as the low-level portable API
-  \end{enumerate}
-
-\item[\Party{Dylan Thurston}] Opinion:
-  \begin{enumerate}
-  \item \label{hinderdt} ensure that the common API is extensible to the
-    native, platform-dependent functionality
-  \end{enumerate}
-
-\end{enumerate}
-
-\section{Objectives for a Common GUI API}
-
-Having summarized this information I will now try to distill the
-essence from it. Note that the references mentioned do not always
-support the argument itself but rather the consequence.
-
-\begin{description}
-\item[Platform independence] The Common GUI API needs to run on all
-  platforms (\ref{allspj}, \ref{allds}, \ref{allas}, \ref{allah}).
-  \footnote{Let the word platform denote an operating system with a
-    specific native API or toolkit.}
-\item[Look-and-Feel] The Common GUI API shall enable the user to
-  create GUIs which adhere to the native look and feel of the platform
-  and its local style guide (\ref{lookwj}, \ref{lookwnn},
-  \ref{lookka}, \ref{lookah}, \ref{lookgc}, \ref{lookpa},
-  \ref{lookwt}). We cannot achieve native look-and-feel by using a
-  single cross-platform back-end (e.g. wxWindows) because adhering to
-  the local style guide has semantic implications that cannot be
-  abstracted away and which have to be addressed differently on each
-  platform (\ref{feelbk}, \ref{feeljm}, \ref{feelwt}). There is no
-  compromise between strictly adhering to native look-and-feel and
-  forcing a look-and-feel onto alien platforms.  We opt for the former
-  because it can subsume the second (portability-only) approach
-  (\ref{dirtysbg}, \ref{dirtyka}).
-\item[Extensibility] The common GUI library may not hinder the use of
-  native, non-portable functionality (\ref{hinderspj}, \ref{hinderas},
-  \ref{hindersk}, \ref{hindersm}, \ref{hinderdt}).
-\item[Abstraction level] The Common GUI API will have a
-  medium\footnote{The notion medium here is meant to be the definition
-    from the Haskell web page, thus it refers to the language level:
-    imperative versus functional.}  level API as its interface to the
-  user of the API (\ref{midsbg}, \ref{midjm}).  It is not clear how a
-  high-level layer shall look like, thus defining one is not our goal
-  (\ref{highspj}, \ref{highsbg}, \ref{highah}, \ref{highac},
-  \ref{highpa}). A common low level veneer is doomed to become
-  platform specific and thus difficult to find (\ref{lowwj},
-  \ref{lowvnn}, \ref{lowsbg}, \ref{lowas}, opposition: \ref{lowka}).
-\item[Intersection Approach] A portable API is a kind of intersection
-  of all its back-ends (\ref{interspj}, \ref{interkw}, \ref{interwt},
-  \ref{intersm}). Thus practical portability can only be achieved by
-  designing the API with all back-ends in mind (\ref{portka},
-  opposition: \ref{portpa}). We therefore have to restrict the set of
-  target platforms. The community has interest in bindings to these
-  platforms (and no more at this time):
-  \begin{itemize}
-  \item Win32
-  \item Aqua (Mac OS X environment)
-  \item Gtk (Gnome)
-  \item Qt (KDE)
-  \item wxWindows
-  \end{itemize}
-\item[Evolutionary vs. Agreement Approach] There has been a debate on
-  how to define the Common API. On the one hand we can take an
-  existing set of functions (from either GIO, Object I/O, Yahu) and
-  change them with each mismatch we find when we implement the
-  functions on other back-ends (\ref{scratchspj}, \ref{scratchsk},
-  \ref{scratchdl}). On the other hand, we could start with a blank
-  sheet and scrutinize all functions which we add to the specification
-  (\ref{scratchvnn}, \ref{scratchas}). There is no clear consensus
-  here, but at least the core infrastructure (e.g. whether to have
-  \verb+set+ and \verb+get+ functions) probably has to be agreed upon.
-  Maybe the distinction is more blurred in practice anyway so that we
-  don't need a clear vote.
-\item[non-goals] Due to the lack of enthusiasm, I assume these
-  proposals are overruled: Create a common API that can be used by
-  other languages as well (\ref{langwj}), use a document interface to
-  talk to the GUI (\ref{docvnn}).
-\end{description}
-
-\noindent I think this subsumes Simon Peyton-Jones summary from February 12th. 
-
-\section{Mission statement}
-
-\subsection{Terminology}
-The following terms are used throughout this document:
-\begin{description}
-\item[Common GUI API] The project name as well as the outcome of this
-  undertaking: A specification of an interface for GUI programming.
-\item[back-end] A collection of GUI functions with which the Common GUI
-  API is implemented. A back-end can be (but does not have to be) tied
-  to one platform. Synonym: toolkit
-\item[platform] One of Win32 (native back-end: Win32), Mac OS X
-  (native back-end: Aqua), Gnome (native back-end: Gtk), KDE (native
-  back-end: Qt).  A platform has a native look-and-feel.
-\item[look-and-feel] A set of layout conventions and semantics of a
-  GUI. The look-and-feel is tied to a particular platform. It is
-  usually defined in a Style Guide of that platform.
-\item[widget] A user interface element. A button is an example for this.
-\end{description}
-
-
-The GUI task force agrees to the following design choices:
-
-\subsection{Aim}
-The goal of this project is to define an application program interface
-(API) which enables a Haskell programmer to write applications with a
-GUI in a portable, native-looking way.
-
-\subsection{Subset approach}
-The API will expose as many GUI elements from the different back-ends
-as possible. GUIs expressed with the Common API shall have the native
-look-and-feel of the platform the application runs on.  Functionality
-that cannot be implemented this way on all platforms shall not be
-covered in this API. Specifically, platform dependent programs
-(e.g.~Control Panel applications under Windows) will not be covered by
-this API (but may well be possible to implement with the specific
-back-end).  Services that are not covered in the Style Guide of a
-particular platform (e.g.~internationalization, localization, sound,
-persistent configuration) shall use the native conventions only if
-feasible.
-
-\subsection{Extensibility}
-Additional functionality that cannot be expressed with the native
-look-and-feel can and should be provided by the different back-ends.
-The Common API may not hinder these extensions.
-
-\subsection{Structure}
-The Common GUI API shall be a pure specification. It provides the
-definition of a \emph{core} which describes an infrastructure to
-modify stateful object. The \emph{functionality} of the API will be
-accessible through this core. Different \emph{back-ends} will exhibit
-additional functionality through the same core.
-\subsection{The Core}
-The core comprises the infrastructure with which GUI applications are
-written. It will specify how attributes of objects are set and queried
-and how to associate different objects with each other. The core has
-to define how call-backs are handled.
-
-\subsection{Coverage}
-Within this project we will try to find common abstractions for
-different aspects of GUIs and interfaces to the user in general. The
-following list shall neither be exhaustive nor mandatory. More
-important topics are listed first.
-\begin{enumerate}
-\item An application framework with menus, possible with different
-  complexity levels (single document interface (SDI) and multiple
-  document interface (MDI)).
-\item A set of standard widgets.
-\item A layout mechanism which abstracts away static and dynamic
-  arrangement of widgets.
-\item A set of common dialogs.
-\item Primitive drawing functionality on a canvas.
-\item Configuration reading and writing, internationalization.
-\item OpenGL rendering.
-\item Invisible canvas and the ability to print it.
-\item Sound support.
-\end{enumerate}
-
-\subsection{Back-ends}
-The parties that are interested in providing an implementation to a
-specific back-end are expected to contribute in the finding of this
-specification. It is their duty to ensure that the agreed
-specification can be implemented with the platform's native
-look-and-feel on top of their particular back-end. The Common GUI API
-shall be implemented on top of the back-ends given in Table
-\ref{fig-backends}. The platform columns show on which platforms the
-back-end is expected to deliver the native look-and-feel. Note that
-this does not preclude other back-ends from running on platforms not
-listed (e.g.~Gtk and Qt both run on Windows). As long as we have not
-started to put forth any GUI functionality, we welcome people to
-propose other back-ends and even platforms. To ensure progress, we
-cannot alter functionality marked as stable for platforms added later
-in the process.
-
-\begin{table}
-  \begin{center}
-    \begin{tabular}{|l||c|c|c|c|c|}\hline
-      & \multicolumn{5}{c|}{Platforms}\\
-      Back-end & Win32 & Mac OS X & X11/Xt & KDE & Gnome \\ \hline
-      Win32 & X & & & &\\
-      Aqua  & & X & & &\\
-      Athena & & & X & &\\
-      Motif & & & X & & \\
-      Qt+KDE extensions   & & & & X & \\
-      Gtk+Gnome extensions  & & & & &  X \\
-      HToolkit & X & & & & X \\
-      wxWindows & X & X & & & X \\ \hline
-    \end{tabular}
-  \end{center}
-  \caption{\label{fig-backends} Targeted back-ends and their platforms}
-\end{table}
-
-\subsection{Target audience}
-The API shall be expressive enough to enable professionals to write
-GUI application. Although the Common API is restricted in the number
-of GUI components to what is available on all platforms, the
-functionality of the provided components shall be as exhaustive as
-achievable. Simpler layers on top of the Common API for educational
-purposes should not be hindered, but such a layer is not part of this
-project. A user should be comfortable writing larger applications using
-the Common GUI API without feeling the need to introduce new
-abstraction layers. However, we shall not hinder high-level
-abstractions if possible.
-
-\subsection{Implementation language}
-The definition of the Common API shall mainly be written in Haskell
-98. Language extensions shall only be used when they seem sensible. We
-will make use of hierarchical module names.
-
-\section{The user's perspective}
-A potential user who wants to write a GUI application might find
-our approach confusing. These are guidelines we will give:
-\begin{itemize}
-\item If the extend of the application is rather small, the user might
-  find all necessary functionality in the specification of the Common
-  GUI API. In this case, (s)he can use any back-end to compile her/his
-  application and expect the native look-and-feel of the
-  platform. Ideally, even different back-ends for a certain platform
-  will create the same look and behavior.
-\item Writing an application which cannot be expressed with the Common
-  GUI API alone will present the user with a set of choices which
-  imply different trade-offs between effort and professionality:
-  \begin{itemize}
-  \item If discrepancies in look-and-feel is not a big issue, the user
-    would choose a back-end like wxWindows which runs on all
-    platforms. This back-end might not give access to all functions
-    available on the different platforms and might introduce back-end
-    specific look-and-feel as a compromise between the platforms. The
-    big advantage is that no platform specific code has to be written.
-  \item If the user is only interested in the Gnome and Windows
-    platforms, HToolkit as back-end will give a native look-and-feel
-    for both of them without any code change. The expressiveness of
-    HToolkit is only slightly reduced since both platforms are quite
-    similar.
-  \item If the application is very demanding in terms of user
-    interface, a native back-end must be used. (Gtk and Qt have the
-    advantage that they run on other platforms which might be useful
-    for demonstrating.) In the long run, parts of the application
-    which are not implemented with the Common GUI API have to be
-    reimplemented for each native back-end. The result, however, will
-    be an application that feels native. All this is achieved with a
-    minimum of porting effort.
-  \end{itemize}
-\end{itemize}
-
-\section{Technical Discussion}
-\subsection{Core functionality}
-The term core functionality refers to the general problem of
-connecting to a concurrent library with bidirectional flow of
-control. The following orthogonal topics were discussed:
-
-\subsubsection{Creation of Objects}
-There are two techniques to create objects: One uses constructor functions as imperative object-oriented languages would do, the other one has a dedicated creation function which takes a description of the GUI as an algebraic data type.
-\begin{enumerate}
-\item Constructor Functions (e.g.: GIO, most low-level veneers)
-  \begin{enumerate}
-  \item (Daan) bad: not a first-class description
-  \item (Daan) bad: identification values only become available after creation
-  \item (Daan) good: only need actions to modify object's properties,
-  Object I/O needs constructors for all properties as well
-  \item (Daan) good: passing the parent to non-toplevel widgets during
-  construction is a way to prevent widgets from being inserted into
-  two hierarchies
-  \end{enumerate}
-\item Generation of GUI through data type (e.g.: Object I/O)
-  \begin{enumerate}
-  \item (Daan) bad: easy to forget to associate an id value with an object
-  \item (Peter) bad: more type safety make this approach very complex
-  (e.g.~typed identifiers)
-  \item (Peter) good: setup using IDs is symmetric (i.e.~create
-  objects and IDs separately)
-  \item (Axel) good: checking for invalid layout is easier due to the
-  centralized creation function, alleviation (Krasimir): make each
-  non-toplevel widget take its parent as a mandatory argument (see
-  Section \ref{secParentAsParameter}).
-  \end{enumerate}
-\end{enumerate}
-\subsubsection{Configuration of Objects}
-For convenience the user should be able to set properties of an object
-when it is created. It is obvious that properties must be changeable
-later on.  (It might be less obvious that some properties may
-only be specified at creation time and are to be considered constant.)
-
-An example of how this might look like was given by Daan:
-\begin{verbatim}
-data Attr w a  = Attr (w -> IO a) (w -> a -> IO ())  -- getter and setter
-
-data Prop w    = forall a. (:=) (Attr w a) a         -- := is a constructor
-
-set :: w -> [Prop w] -> IO ()
-set w props
-  = mapM_ setProp props
-  where
-    setProp ((Attr getter setter) := x)
-      = setter w x
-
-get :: w -> Attr w a -> IO a
-get w (Attr getter setter)
-  = getter w
-
--- example of an attribute, works for any kind of (wxWindows) Frame
-title :: Attr (Frame a) String
-title
-  = Attr (\w    -> w # frameGetTitle)
-         (\w x  -> w # frameSetTitle x)
-...
-gui = do ...
-         set frame [title := "hi there"]
-
-\end{verbatim}
-Note that this particular approach is unlikely to be taken as it
-involves existential types and a constructor which might become a
-keyword in future versions of Haskell.
-
-Another (slightly incomplete) example by Krasimir:
-\begin{verbatim}
-data Point = Point {x :: Int, y :: Int}
-
-attrX :: StateAttr Point Int
-attrX = StateAttr x (\v p -> p{x=v})
-
-attrY :: StateAttr Point Int
-attrY = StateAttr y (\v p -> p{y=v})
-
-move :: Int -> Int -> State Point Int
-move vx vy = do
-   x <- get attrX
-   attrX =: x+vx
-   y <- get attrY
-   attrY =: y+vy
-\end{verbatim}
-
-Sven suggested to define some more general set/get functionality,
-maybe adding it to MonadState. Was there actually any discussion on
-the library list?
-
-Glynn would like to have a single create function for all widgets. He
-admits that this leads to ambiguity when the result is not passed to a
-function which expects a specific widget type.
-
-Glynn: From Xt: Widgets should have names to change their attributes
-from outside (resource files).
-
-David votes to use a (the) GIO/Object IO style. I think we all agree
-that we would like to have something slightly more abstract than
-simple IO functions like gtk+hs, gtk2hs, wxhaskell, etc. offer (we all
-agreed that CGA should be on a medium abstraction level).
-
-Vincenzo welcomes comments on extending the GIO approach with standard
-IO functions that don't take the attribute list (in case default
-values apply for every attribute).
-
-Summing up the conversation about the set and get functions, I posted
-the following proposal.
-
-\begin{verbatim}
--- An attribute is a property of a widget. It knows how to set the
--- and how to read the value of this property.
-data WidgetClass w => Attr a w = <abstract>
-
--- The assignment operator joins an attribute with its value.
-(=:) :: a -> Attr a w -> Setter w
-
--- Set and get can be used on every widget.
-set :: WidgetClass w => w -> [Setter w] -> IO ()
-get :: WidgetClass w => w -> Attr a w -> IO a
-
--- An example for a Button widget: The constructor has one
--- mandatory argument.
-newButton :: Container -> [Setter Button] -> IO Button
-
--- The Button has at least this attribute.
-label :: Attr String Button
-
--- This is one callback the Button provides. Note that you cannot
--- attach any function at construction time or with the set
--- function. The returned action is the unregister function.
-onClicked :: ButtonClass b => b -> IO () -> IO (IO ())
-\end{verbatim}
-
-\subsubsection{\label{secParentAsParameter} Composition of Objects
-  (Layout)}
-
-This topic did not receive much attention yet. But Krasimir mentioned
-this and Glynn later wrote how layout is captured in Xt programming,
-which captures the same idea: Each non-top-level widget has to specify
-its parent at creation time. This seems to be the only approach that
-enforces one widget to have at most one parent (like Object I/O's
-widget tree description via an algebraic data type) and a unique
-identification (the value returned from the create-function like in
-GIO).
-
-\subsubsection{Events versus Callbacks}
-Quickly skimming the whole discussion about events and callbacks, it
-seems that
-\begin{itemize}
-\item callbacks are close to most GUI libraries
-\item events can be implemented on top of callbacks
-\end{itemize}
-As such, the essence of the discussion was that the event view may be
-implemented on top of callbacks (hopefully via an additional library).
-
-Vincenzo should interfere if something is added to the CGA which makes
-stream based models of data flow difficult.
-
-\subsection{Menu Bars}
-\begin{enumerate}
-\item Each application has exactly one menu bar.
-  
-  \rationale{ This constraint stems from Aqua. It is not as radical as
-    it might seem at first since it is required by the Windows Style
-    Guide as well. Allowing an application which consists of a single
-    dialog violates the Style Guide of Windows, it is impossible under
-    Aqua. As such it should not be a severe restriction. }
-  
-  Note that there are plug-in like applications which are part of a
-  bigger application (e.g. Control Panel under Windows, System
-  Preferences under Aqua, install wizards under Windows). These are
-  system dependent and thus not covered by the Common API.
-
-\item The following menus are automatically added to menu bar: File
-  (always), Edit (only on Windows and Unix if a Preferences dialog is
-  specified), Help (only on Windows and Unix if an About dialog is
-  specified)
-
-\rationale{ The reason for these requirements are the menu entries
-  Quit, Preferences and About which are located under the application
-  menu under Aqua. }
-
-\item Each application has an entry to terminate the program.
-  
-  \rationale{ Aqua automatically inserts a Quit menu item in what
-    corresponds to the System menu on other platforms. In contrast no
-    Quit or Exit entry are found in Aqua's File menu. Windows' Style
-    Guide assumes that there is a menu entry called Exit under a File
-    menu.}
-
-The CGA will insert the Quit/Exit menu entry on behalf of the
-programmer.  The CGA only provides means to customize the action taken
-on selecting this entry which by default is to close the application
-unconditionally. Closing the main window under Windows and Unix will
-trigger the same action as for the Quit/Exit menu entry. The keyboard
-shortcut for Aqua is Apple-Q and Alt-F4 on Windows and Gtk.
-
-\item An application may specify a Preference menu entry.
-  
-  An application can specify an action to change general settings of
-  an application (Preferences). If it does, an appropriate menu entry
-  will be inserted. Under Aqua, this will be placed under the
-  application menu. Under Windows and Unix an Edit menu entry is
-  created in the menu bar and the Preferences entry will be placed in
-  the Edit menu as the last entry. The keyboard shortcut is
-  application dependent and optional.
-
-\item An application may specify an About dialog.
-  
-  An application can specify a Copyright notice or a complete About
-  dialog. If it does, on Windows and Unix a Help menu will be added as
-  last menu in the menu bar with an About entry. If only the Copyright
-  notice is present then it is displayed in a dialog along with the
-  application's icon and an Ok button. If nothing is specified no
-  action is taken on Windows or Unix platforms. Under Aqua an About
-  dialog will be inserted which only shows the icon. This menu item
-  has no shortcut key.
-  
-\item Maybe more on Edit menu entries.
-\end{enumerate}
-
-\subsection{MDI, SDI and other application setups}
-Krasimir suggested MDI (multiple document interface), SDI (single
-document interface) and NDI (no document interface). The two former
-acronyms stem from the Windows world. The latter one is a creation of
-Clean's Object I/O library, if I am not mistaken. NDI violates Aqua's
-requirement of every application having a menu bar, therefore it is
-probably not an option.
-
-Wolfgang Thaller gives a list of possible windows (not application
-setups) which we might consider:
-\begin{itemize}
-\item document windows
-\item modeless dialog windows,
-\item application-modal dialog windows (and alert windows/message boxes)
-\item window-modal dialog boxes (do they exist on any non-Mac OS platform?)
-\item utility windows (for toolbars etc.)
-\item MDI frame windows (which don't exist on all platforms - an MDI
-  frame should be created automatically when appropriate for MDI
-  applications).
-\end{itemize}
-
-\subsection{Layout of Buttons in Dialogs}
-Aqua users expect the buttons in a dialog box with specific names and
-positions which are different from Windows conventions. Thoughts of
-Wolfgang Th.:
-
-\begin{enumerate}
-\item Have a ButtonBox widget that automatically places buttons. There
-  could be predefined classes like Ok, Cancel and others. The widget
-  would then arrange and rename buttons appropriately.
-\item Have some predefined buttons which have different labels on
-  different platforms (e.g. Save/Yes, DontSave/No). (This statement is
-  an interpretation of his message only.)
-\end{enumerate}
-
-\subsection{Configuration storage}
-Well known fact: layout in Gtk is relative and dynamically calculated
-at creation time, all dialogs are resizable. On Windows, all elements
-are placed at absolute coordinates (expressed in dialog units) within
-the dialog. Changing the font size in Windows changes the dialog
-units, but not the absolute coordinates.
-
-Glynn points out that under Xt each button label and its position with
-the dialog is looked up in a resource file.
-
-Does the layout belong into this section? Do we for a start rely on
-dynamic layout and but use resource files as an addition on platforms
-that provide static layout (Windows, Xt, probably Aqua)?
-
-
-\subsection{Internationalization}
-Glynn: Don't make localization and customization the
-programmer's problem. CGA should provide means to do this.
-
-\subsection{Concurrency}
-Three points here (which might be subject to revision if they are not implementable):
-\begin{enumerate}
-\item The CGA shall exhibit the same concurrency behavior both on
-platforms that run Haskell threads as separate OS threads and on those
-which use a non-preemptive multitasking approach.
-\item Calling an API function may not block Haskell threads.
-\item The CGA has to provide all the necessary synchronization to
-ensure proper operation in the presence of concurrency.
-\end{enumerate}
-
-\end{document}
-% LocalWords:  API Angelov Krasimir Daan Leijen Marlow Thaller Meacham Achten
-% LocalWords:  Kurtzberg wxWindows SWT Sengan Jeltsch Sankel Chakravaty's Gould
-% LocalWords:  Wansbrough APIs Thurston GUIs Yahu KDE OpenGL HToolkit SDI MDI
-% LocalWords:  Sven Callbacks callbacks CGA Aqua's Xt