[GUI] CGA Proposal

[Krasimir Angelov]

--- Axel Simon <A.Simon@kent.ac.uk> wrote:
> I think we should make another distinction between
> "mandatory" and "read-only" arguments. We said
> that mandatory elements have to be given as
> explicit argument as you do in the "newControlApp"
> function for the ApplicationVersion or
> DocumentInterface.
> Both are read-only, but I doubt that they should be
> mandatory. 

This is exactly what I do in HToolkit.

> > newControlApp :: ApplicationName
> >               -> ApplicationVersion
> >               -> DocumentInterface    -- mdi hint
> >               -> [Prop ControlApp]
> >               -> IO ControlApp
> Ops, no DocumentInterface parameter for ControlApp.
> The point is
> that ControlApp are not centered around documents
> and that there
> is only one main window.

The current HToolkit implementation still doesn't
support abstraction for documents, but the
DocumentInterface is necessary. Maybe the type should
be renamed to ApplicationInterface. The interface
specifies a way in which the windows are created. For
example the SDI permits only zero or one created
windows while the MDI permits many openned windows.
The application interface type is used from HToolkit
core to know how to create the primary window and
menus.

> >     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
> 
> One argument for the first approach is that it an
> application
> is treated similar to widgets. But since there is
> only one
> application, your solution is a way to simplify
> things. How
> do others think about this?

I hope that we can achieve agreement on that point.

> Wow, I haven't thought about making the distinction
> between control and document based application on
> the fly. Maybe that's the way to go. I wonder if it
> is
> more difficult to understand.

The advantage of this approach is that in that way the
programmer doesn't need to be responsible for the
creation of predefined menus.

> BTW, your "DocumentTemplate" shouldn't contain
> callbacks. Callbacks should be installed by
> calling functions "onBlah :: (data -> IO ret) ->
> GUIElement -> IO 
> CallbackId"
> so that they can be detached with the CallbackId if
> needs be.

I don't understand this.

> > --- Axel Simon <A.Simon@kent.ac.uk> wrote:

> > 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.
> 
> How is the CGA under Windows and GNOME supposed to
> know which window will take the menu bar in case the
> user uses the ControlApp variant?

In both ControlApp and DocumentApp the library is
responsible to create the primary window and only it
knows the primary window handle. The menus are always
placed in the primary window.

> Not quite. IORefs do not use existential types.
> I think it is possible and cleaner not to model any
> state. At least this will leave the organization of
> the application's state space up to the programmer.
> I don't feel too strongly about this.

I think that the documents model which I propose is
the most simple way to handle documents. The
programmer is always free to use other state
representations.

Krasimir

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