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