[GUI] CGA Proposal

[Krasimir Angelov]

   Hi Axel

In the GIO, wxHaskell and Yahu libraries doesn't have
distinction between readonly and read-write arguments.
I don't advocate the usage of different types for
readonly and read-write arguments. The usage of then
single Attribute type makes thing more simpler. In
order to make 'appClass' and 'appMDIHint' attributes
readonly the following functions should be changed:

newControlApp :: ApplicationName 
              -> ApplicationVersion
              -> DocumentInterface    -- mdi hint
              -> [Prop ControlApp] 
              -> IO ControlApp

newDocumentApp :: ApplicationName 
               -> ApplicationVersion
               -> DocumentInterface    -- mdi hint
               -> [Prop ControlApp] 
               -> IO ControlApp

The new definitions takes the application name and
version and the document interface mode as arguments. 
The following calls to 'appClass' and 'appMDIHint' 
attributes will return the corresponding values.
    In order to init/done the CGA library and to run
the main loop we need functions like:

initCGA  :: IO ()
startCGA :: Application a => a -> IO ()
doneCGA  :: IO ()

    The main function will like:

main = do
  initCGA
  app <- newControlApp "test" "1.0" SDI []
  ...
  ... create another widgets
  ...
  startCGA app
  doneCGA

    The disadvantage is that the application should
pass the 'app' value to all functions which need to
create windows, dialogs or utility windows. Why don't
use simple function like this:

main = start "test" "1.0" SDI [] $ do
  ...
  ... create widgets
  ...

In this proposal the application instance is created
implicitly. The access to the instance is possible
through the global function.

app :: Application

There isn't distinction between Document based and
Control based application. When the programmer defines
the first document template then the library will
automatically create and manage the required
predefined menus. If there isn't defined any document
template then the programmer is free to create its own
menus.

--- Axel Simon <A.Simon@kent.ac.uk> wrote:
> >    - The primary window is explicitly created.
> That
> > means that the application can have many primary
> > windows and each of them owns the menu bar. This
> is
> > possible under Windows and GNOME but is impossible
> > under MacOS where the menu bar owned from the
> > application. What will happen if the programmer
> > forgets to create the primary window and try to
> create
> > a menu bar? Under MacOS this is OK but under
> Windows
> > and GNOME this will cause runtime error. My
> proposal
> > is to have primary window only under Windows and
> > GNOME. The primary window is implicitly created
> and in
> > SDI and MDI mode it is owner of all windows (with
> > exception for dialogs and utility windows). In
> > controled SDI mode each window will be top level
> and
> > the primary window will own only the menu bar and
> the
> > utility windows. An example for application with
> > controled SDI interface under Windows is the
> Delphi
> > environment and the GIMP under Linux. The MacOS
> > application doesn't have a primary window because
> the
> > menu bar is owned from the application and all
> windows
> > there should be top level.
> 
> The user should either create one ControlApp or one
> DocumentApp and  
> nothing more.

Ok. But this leaves open the question for primary
window. Why the programmer need to explicitly create
it? The MacOS applications doesn't have primary
window. I think that the primary window should be
internal for the library implementation and should
exist only under Windows and GNOME. That means that
the 'newPrimaryWindow' function should be removed.

> A comment on your implementation:
> One thing which we discussed in spring is that the
> CGA should not  
> manage state whatsoever. As such having "Document a"
> where "a" is the  
> type variable taking on the state is not right. To
> be type safe you  
> need to thread this type variable through all CGA
> functions that might  
> handle the state, especially functions to register
> callbacks.

Why do you think that this is type unsafe? The
Document type is much like IORef type.

Best regards
Krasimir

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com