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.