On Friday, Aug 15, 2003, at 00:06 Europe/Paris, Krasimir Angelov wrote:
- The attribute appClass must be read only. The GNOME library requires to know the application name and version before initialization. That means that the 'appClass' attribute in the proposal should be readonly and its value should be set at startup.
Yes, ok. I don't remember what we said about read-only attributes and how they should be implemented. If we have them, a lot of attributes need to become read-only. Maybe I should make that distinction right away. Do you differ between read-only and read-write attributes?
- The comments for 'appCreateToolbar' are: -- | Specify whether to create a toolbar for this window or not. -- -- A toolbar is by default created (True) for each document window (see -- 'newDocumentApp') and not created (False) for primary control windows -- (see 'newControlApp'). This seems like mistake. The function defines a property for application while in the same time it manages a window. Why not just leave the programmer to create a toolbar if he/she needs it?
Yes, that might be prudent. I thought it would be good if the user could get started with as few lines as possible. That's why I proposed to create an automatic toolbar by default. Maybe that should go.
- For the predefined menus there are defined newFileMenu, newEditMenu, newViewMenu, newInfoMenu and newWindowMenu functions. What they do? As I understand the newFileMenu function creates an empty menu which is named "File" and is placed at the appropriate place. The programmer is responsible for the menu content. Am I right? If this is true then why not leave the programmer to create the menus like other user defined menus? The creation of predefined menus is required only if the application is document based. If there aren't defined document types then the library will never mount the predefined menus and the programmer can create its own menus.
I could let the programmer create all menu with just one function. The special thing about the predefined standard menus is that only these will be changed by the application framework (e.g. the View menu will receive entries to show/hide and change the toolbar, even in Control-applications). But now as you mention it, maybe this can be simplified by just having special menu items which then create Open/Save/Close elements or Hide/Show Toolbar. The user then has to add them to the appropriately named menus. Good point.
- What is the meaning of the 'attrMenuName'?
That was to change the name of a predefined menu. But the predefined menus are probably too clumsy.
- 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.
- The newControlApp function should receive the application name and version as arguments. In the proposal doesn't have function for initialization. In the GNOME it is necessary to call gnome_program_init function before any call other call to GNOME. Under Windows the function for initialization registers the new window classes (RegisterClass from Win32 API). After initialization it is necessary to run the main event loop. Under GNOME the main loop is gtk_main() and under Windows this is GetMessage/DispathMessage loop. The application finishes after the main loop finish. As the final step the library should free all resources allocated from the operating system. All this is made from the 'start' function in HToolkit. The application itself is implicitly created from the start function. This prevents the programmer to call the newControlApp (or similar function twice).
Yes, I guess there needs to be a start up function taking an Application and displaying it on the screen. But the problem remains the same: You can't prevent the user from calling "start" twice. This is probably a run-time error.
- The appMDIHint attribute like the 'appClass' should be readonly. The reason is that after the application initialization it is hard or impossible to change the application type.
Yes, but I don't have read-only attributes yet.
- The information provided with the DocumentApp is not enough to manage the predefined File menu.
I intend to have special Open, Save,... menu items which can be added to the "File" menu. These will have all the machinery for handling documents attached. I don't understand your point. 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. Cheers, Axel.
PS: The prototype implementation for the Document and DocumentTemplate types, announced in the specification for HToolkit is available in CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/htoolkit/port/src/Port/ Document.hs?rev=1.4&content-type=text/vnd.viewcvs-markup
Best regards, Krasimir
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui