Re: [GUI] CGA Proposal

--- Axel Simon 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 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