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