[GUI] CGA Proposal

Axel Simon A.Simon@kent.ac.uk
Sun, 17 Aug 2003 09:20:32 +0200 

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
>