Re: [GUI] CGA Proposal

On Sunday, Aug 17, 2003, at 14:44 Europe/Paris, Krasimir Angelov wrote:

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 Ops, no DocumentInterface parameter for ControlApp. The point is

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. The interface should be simple. A programmer shouldn't need to supply the appMDIHint attribute since it can default to something (say SDI). that ControlApp are not centered around documents and that there is only one main window.

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?

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.

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. 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.

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

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?

...

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.

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. Cheers, Axel.