On Sun, Feb 16, 2003 at 04:37:15PM +0100, Nick Name wrote:

On Sun, 16 Feb 2003 15:13:53 +0000 Axel Simon wrote:

...

I added a summary which I would like you to have a look at

I have read the summary, and there is one point I do not completely undestand: the one named "look and feel". Did you mean that we cannot achieve native look and feel *on all platforms* , and so we shall enable the user of the library to achieve native look and feel if he wants?

Oh no, the point should be: If you use the Common API you will (automatically) get applications which have a native look-and-feel. I think I confused you when I wrote: "We cannot achieve native look-and-feel by using a single cross-platform API ..." I meant back-end instead of API and wxWindows in an example. Thanks for pointing this out.

I think that by well-defining the in-famous high-level interface, one could solve the problem, but it will come later. This should be in the Common GUI API.

As a second point, we have to design the interface so that it's implementable for new backends that could come (but I cannot think of a way of NOT enabling this). I think this is the argument by Peter Aachten ("Object I/O is portable by design") which is later opposed by Krasimir ("Haskell's Object I/O library is too Windows specific as it is"). I added this pointer.

I update the document. Thanks for the early comments, Axel.

On Sun, Feb 16, 2003 at 06:41:55PM +0100, Nick Name wrote:

On Sun, 16 Feb 2003 17:12:54 +0000 Axel Simon wrote:

...

Oh no, the point should be: If you use the Common API you will (automatically) get applications which have a native look-and-feel.

I think there is a more tecnical aspect to discuss and that perhaps could be added to the summary if people agree. Yes, indeed. I am indeed lagging with my document since this technical discussion has already started. But before we define the details, we should probably define the core of the library (Yahu / Object I/O approaches) and then discuss:

Macos X has a notion of "application" and one of "document", and when one closes the last window of an application, the application is still running. On windows, OTOH, it's (at least it was) common pratice not to open a second instance of an application, but a new document instead, for every run of the program. On linux, there is the well known behaviour of creating a new unix process, and a new instance of the application, for every execution of the program. a) the SDI/MDI/NDI problem which Krasimir has raised on Jan 28

[..]

To get back on what I was talking about, if we want the common API to achieve real look and feel, we ought to have an "application" abstraction, wich is different from the "window" one. So an application could behave really different in any OS. On OSX, the menus of the documents of the same application will have to be in a submenu of the main menu for the application, and items like "exit" wich are not in the file menu (at least, I think I have heard so :)) need to be part of the "application" abstraction, as do the common items wich are found in the "help" menu. b) the application startup that enforces one menu bar and c) default menu entries (Exit on Windows, Quit on Mac - but the same thing in the Common GUI API)

I will try to keep up with the discussion! Axel.

On Sunday, 2003-02-16, 18:41, CET, Nick Name wrote:

[...]

The real problem is that linux does not have (if it ever has only two looks) a native feel, so one should be chosen before we start working.

I would prefer having the different desktop environments as look-and-feels under Linux as well as under other UNIX-like OSes. It would be ugly, for example, to force a KDE application onto a GNOME user.

[...]

Wolfgang

On Sun, Feb 16, 2003 at 06:37:10PM +0100, Wolfgang Jeltsch wrote:

Hello again,

some mails ago I already talked about the two interpretions of "level": (a) functional (high) vs. imperative (low) (b) high level GUI concepts (e.g., common dialogs) vs. low level GUI concepts (e.g., single widgets or even drawing primitives)

Opinion 4c currently says that the common API shall be at a higher level than the (L) interface. A problem is that it is not clear to which meaning of "level" this refers. I definitely meant that the common API shall be high-level with respect to (b). Another point is that I didn't want to talk about differences between the "common API" and the (L) interface. In fact, I wanted to say that already the (L) interface should be high-level in the (b) meaning. Otherwise it would be hard or impossible to implement a native-look-and-feel (A) interface on top of it. If, for example, (L) didn't support file open dialogs directly, (A) would have to build them itself which would probably lead to dialogs which are different from the platform specific ones.

So I would rephrase 4c as follows: to achieve native look-and-feel on each platform, the common API shall provide support for high-level GUI concepts like common dialogs or applications, not only for widget structures Ok, I added a comment to the footnote in the Abstraction Level paragraph. Since this is supposed to be only a summary of opinions, I put your

Furthermore, in section 2 (objectives) you talk about the platforms "the community is interested in". Does this mean that this covers all platforms someone from the community is interested in or that it covers only those platforms most people of the community are interested in. If the former is the case, I would like to see KDE added. But I thought Qt represents KDE in terms of the user interface?! Or is

Yes, I think the term level on the Haskell web-site refers to (a). To me it is not clear that we have to restrict ourselves in term of (b): Of course, we need to support the native Open File dialogs instead of building our own, but even elementary thing like drawing onto a canvas could be made common to all platforms since they all use an "redraw-this-part" event-driven scheme AFAIK. Perhaps I can add a list of topics we can potentially cover and then see if it is achievable. paragraph into the preliminary "Mission Statement" section. this relation like Gtk-GNOME where GNOME provides more advanced widgets? I'll change Gtk to Gtk(GNOME) and Qt to Qt (KDE) then. Thanks for the comments, document update, Axel.