On Thursday, Aug 14, 2003, at 09:50 Europe/Paris, Wolfgang Jeltsch wrote:

On Thursday, 2003-08-14, 08:31, CEST, Axel Simon wrote:

...

[...]

...

Beyond that, for both setups there are Toolboxes (map to toolbars on Windows and to little windows on the other platforms)

Aren't toolbars supported by GNOME, too?

Yes. But a) GNOME have comparatively large icons and b) I don't know if individual toolbars can be detached (in Mozilla they can't). If this is possible, they can be treated like on Windows, i.e. toolboxes (= buttons with icons that do not correspond to menu items) can be in the toolbar area or in a separate window. The distinction between toolbars (buttons with icons that correspond to menu items, e.g. Open, Save, Cut, Paste) and toolboxes (buttons with icons that do not correspond to menu items and that are often modal, e.g. Eraser, Pencil, Paintbrush) might be too artificial. I just thought due to the size of icons on Gnome and Apple all these icons cannot be at the top of the application's window. Cheers, Axel.

On Thursday, Aug 14, 2003, at 12:18 Europe/Paris, Nick Name wrote:

Il 08:31, giovedì 14 agosto 2003, hai scritto:

...

It seems that the three platforms Windows, Gnome and Mac

The kde environment was written with macos and windows in mind, so it's highly probable that any specification that can look and feel native on gnome,mac and windows can also feel the same on kde. Perhaps it would be better to ask on the main haskell list or on the kde development list for a confirmation. If my english does not suck too much :) and there is consensus on also supporting kde I can take care of this job when in Pisa (after 24 aug.) so we will be sure to be able to support kde too. Or else we'll just trust our luck that kde and other GUI toolkits can be modeled if macos, windows and gnome can be modeled with a library

Sure, that would be great! Now is the time. Is there a document like "Human Interface Guidelines" for KDE? We should check such a document to make sure that we don't violate KDE's requirement. I omitted the Athena/Xt back-end for now as well, since I couldn't find any documentation about user interface guidelines (David?). We surely need to look at that, too. Axel.

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

Il 14:44, domenica 17 agosto 2003, hai scritto:

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.

I do advocate it instead, but we'll talk deeper about that next week; I would like to check if it remains simple to set many read-write and read-only attributes in the same function call within H98. Vincenzo

--- Axel Simon wrote:

I think we should make another distinction between "mandatory" and "read-only" arguments. We said that mandatory elements have to be given as explicit argument as you do in the "newControlApp" function for the ApplicationVersion or DocumentInterface. Both are read-only, but I doubt that they should be mandatory.

This is exactly what I do in HToolkit.

...

newControlApp :: ApplicationName -> ApplicationVersion -> DocumentInterface -- mdi hint -> [Prop ControlApp] -> IO ControlApp Ops, no DocumentInterface parameter for ControlApp. The point is that ControlApp are not centered around documents and that there is only one main window.

The current HToolkit implementation still doesn't support abstraction for documents, but the DocumentInterface is necessary. Maybe the type should be renamed to ApplicationInterface. The interface specifies a way in which the windows are created. For example the SDI permits only zero or one created windows while the MDI permits many openned windows. The application interface type is used from HToolkit core to know how to create the primary window and menus.

...

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

One argument for the first approach is that it an application is treated similar to widgets. But since there is only one application, your solution is a way to simplify things. How do others think about this?

I hope that we can achieve agreement on that point.

Wow, I haven't thought about making the distinction between control and document based application on the fly. Maybe that's the way to go. I wonder if it is more difficult to understand.

The advantage of this approach is that in that way the programmer doesn't need to be responsible for the creation of predefined menus.

BTW, your "DocumentTemplate" shouldn't contain callbacks. Callbacks should be installed by calling functions "onBlah :: (data -> IO ret) -> GUIElement -> IO CallbackId" so that they can be detached with the CallbackId if needs be.

I don't understand this.

...

--- Axel Simon wrote:

...

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.

How is the CGA under Windows and GNOME supposed to know which window will take the menu bar in case the user uses the ControlApp variant?

In both ControlApp and DocumentApp the library is responsible to create the primary window and only it knows the primary window handle. The menus are always placed in the primary window.

Not quite. IORefs do not use existential types. I think it is possible and cleaner not to model any state. At least this will leave the organization of the application's state space up to the programmer. I don't feel too strongly about this.

I think that the documents model which I propose is the most simple way to handle documents. The programmer is always free to use other state representations. Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com