--- Axel Simon
Critics and comment appreciated,
The proposal is far from the real world. Here are my objections: - 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. - 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? - 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. - What is the meaning of the 'attrMenuName'? - 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 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). - 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. - The information provided with the DocumentApp is not enough to manage the predefined File menu. 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