On Thursday, Aug 21, 2003, at 10:35 Europe/Paris, Krasimir Angelov wrote:

...

...

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.

I think this is a misconception. SDI and MDI are just ways to present multiple documents. If you open another document in an SDI application, you get a new window. An example of this is the Internet Explorer where each web document is displayed in a separate window. I consider the SDI/MDI distinction to be about presentation, nothing else.

...

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.

How is this different from the setup where the programmer specifies the type of application in the beginning?

...

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.

We discussed on this list that the programmer needs to be able to disconnect callbacks. Thus giving the callback functions as attributes set [onClicked := putStrLn "I'm clicked", onCllicked := putStrLn "Here, too"] doesn't work since there is no way to disconnect just the second callback. The same holds for supplying callbacks in your DocumentTemplate data structure.

...

...

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

Well, then I guess you have some magic function by which the user can actually access the primary window and fill it with content. It seems that you tend to automate a lot. IMHO the programmer should be in charge of what happens and how it happens. If too much happens by magic, it will be hard to learn how to use the GUI API and where to change things if they don't fit the programmer's idea of presentation. I think the programmer should initiate everything. If (s)he wishes to apply magic and create everything in one step, (s)he should call a function for that. Otherwise (s)he should call functions to create the individual user items bit by bit.

...

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.

Hm, maybe, maybe not. I will raise the state issue next week. Cheers, Axel.