Mission Statement
Hi, I tried to formulate a Mission Statement and I invite people to review it. It is Section 3 in the same document in which I gathered initial opinions: http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf It basically says what the Common GUI API is. In my opinion it would be beneficial for us to agree on something like this statement. Otherwise I fear people will restart discussions on topics for which we already reached a consensus. Section 4 contains some comments from the GUI programmer perspective. Comments on this are welcome as well. In the near future I will browse through the achieves and extract opinions on the technical topics in Section 5. Before we agree on anything there, I think it would be a good idea to agree on the core. Daan, is the last version of the GIO core you posted what you propose as core? If so, I will add it to the document for scrutinization. Thanks for comments, Axel.
Hi Axel
I tried to formulate a Mission Statement and I invite people to review it.
Great work! Thanks. There are a few errors regarding the back-ends: * Qt supports win32, bare X11, and MacOSX. However, none of these platforms is supported with native look-and-feel but via Qt themes. However, they are very good at achieving almost native look-and-feel and it takes an experienced user on windows to see the difference. On KDE, Qt is considered the native look-and-feel. (btw. you need to pay TrollTech for commercial win32 apps) * You forgot to add Tk, supports all platforms, albeit slowly and not always natively. * Same for Java AWT via JAPI. * wxWindows supports Win32, MacOS 9/X, GTK, OS2, Motif and X11 with native look-and-feel. Through GTK, it also supports KDE and Gnome rather well allthough the apps look different than Qt apps on KDE. * You write: "If discrepancies in look-and-feel is not a big issue, they would choose a back-end like wxWindows to run on all platforms" This is not true at all -- people tend to choose wxWindows over Qt *because* it offers native look-and-feel. Use Qt or Tk as your example. * "This backend [wxWindows] might not give access to all functions available on a platform" In contrast, wxWindows normally gives *more* functionality than is natively available by implementing that functionality on top the native interface. Examples are advanced tree and list controls, or MDI frames. Use, uhh, X11 as your example here :-) On the other hand, you are right, there is always functionality that is only available on a specific backend, GTK, win32 etc. but that will never be available as part of a portable library (things like a "control panel" application just don't make sense on other systems than win32). All the best and thanks for the writing up, -- Daan. ps. Just some thoughts about the KDE/Qt connection -- it seems that Qt is the preferred GUI API on KDE (allthough GTK is also supported). However, Qt is not just an API (like win32 for example) but also a object oriented framework to structure your application. This is nice for C++ or Python users, but rather bad news for Haskell users! (WxWindows suffers from the same problem although I was able to circumvent it by piggy backing on the work of the wxEiffel people. Same for Java AWT, but fortunately, JAPI exists now)
On Thursday, 2003-03-06, 12:23, CET, Daan Leijen wrote:
[...] * wxWindows supports Win32, MacOS 9/X, GTK, OS2, Motif and X11 with native look-and-feel. Through GTK, it also supports KDE and Gnome rather well allthough the apps look different than Qt apps on KDE.
As far as I know, wxWindows doesn't provide really native look-and-feel on the Mac. I'd like to add that using GTK is not sufficient to provide native GNOME look-and-feel. The same holds for Qt and KDE. So table 1 of the current mission statement is not correct at this point. Both, KDE and GNOME, add their own libraries to GTK or Qt respectively which you have to make use of in order to create real GNOME/KDE applications.
[...]
Wolfgang
On Fri, Mar 07, 2003 at 12:37:46PM +0100, Wolfgang Jeltsch wrote:
I'd like to add that using GTK is not sufficient to provide native GNOME look-and-feel. The same holds for Qt and KDE. So table 1 of the current mission statement is not correct at this point. Both, KDE and GNOME, add their own libraries to GTK or Qt respectively which you have to make use of in order to create real GNOME/KDE applications.
Hm, ok, added. On the contrary, everthing we can cover in the CGA will deal with the more basic stuff, so there probably is no need to conver those extensions. Axel.
On Thu, Mar 06, 2003 at 12:23:03PM +0100, Daan Leijen wrote:
Hi Axel
There are a few errors regarding the back-ends:
* Qt supports win32, bare X11, and MacOSX. However, none of these platforms is supported with native look-and-feel but via Qt themes.
However, they are very good at achieving almost native look-and-feel and it takes an experienced user on windows to see the difference. On KDE, Qt is considered the native look-and-feel. ...and as far as I understand Qt is defining the look for KDE as Gtk is defining the look of Gnome. The feel is probably highly underspecified under Unix (which means we are more flexible there).
* You forgot to add Tk, supports all platforms, albeit slowly and not always natively. Is there anybody willing to do a binding? Even if so, there is no
I think I need to make it clearer what the table is meant for. IMHO, we propose some functionality for the CGA, then go and (try to) implement it, revise and then mark the functionality as stable. Everything we specify in the CGA has to conform to the native look-and-feel of the particular platform. For every cross in the table, there is someone who takes care that there is a) a binding for the CGA functionality proposed and b) that this functionality complies with the native look-and-feel. In particular, a cross does not mean "it will run" but a cross means that there is somebody out there who takes care that the functionality in the CGA is implemented via this backend on this platform with the native look-and-feel. The means, if we put a cross down for wxWindows and Mac OS, you (or someone working on the wxWindows backend) has to make sure that the GUI components we propose has the native look-and-feel on the Mac OS platform. Ideally, a program written with the Common GUI spec, compiled with wxWindows or the native Aqua interface should be indistinguishable. platform where Tk delivers local look-and-feel, is there?
* Same for Java AWT via JAPI. Same thing here. It might of course be possible to write backends that exhibit the Common GUI API, but they will not achieve native look-and-feel which means we don't have to worry about those while we are trying to specify CGA.
[..]
* You write: "If discrepancies in look-and-feel is not a big issue, they would choose a back-end like wxWindows to run on all platforms" This is not true at all -- people tend to choose wxWindows over Qt *because* it offers native look-and-feel. Use Qt or Tk as your example. According to Wolfgang, there are things which do not look native and -more important- do not feel native. Most people said this is true for full fledged GUI libraries. That's why we don't try to build one but go for a subset ("Look-and-feel" in Section 2).
* "This backend [wxWindows] might not give access to all functions available on a platform" In contrast, wxWindows normally gives *more* functionality than is natively available by implementing that functionality on top the native interface. Examples are advanced tree and list controls, or MDI frames. Use, uhh, X11 as your example here :-) Providing widgets beyond those of the native platform is a violation of look-and-feel by definition.
As soon as the document is in GHC's CVS, editing will become easier and I'd like people to join in. For now, I just have to ask what to change and I am grateful for any input. I changed the table and the last two sentences of "3.2 Back-ends". Updated version at http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf Thanks, Axel.
Axel Simon wrote:
* "This backend [wxWindows] might not give access to all functions available on a platform" In contrast, wxWindows normally gives *more* functionality than is natively available by implementing that functionality on top the native interface. Examples are advanced tree and list controls, or MDI frames. Use, uhh, X11 as your example here :-)
Providing widgets beyond those of the native platform is a violation of look-and-feel by definition.
Not necessarily.
The standard Xt-based widget sets (Athena, Motif) are both fairly
basic, so it's common for non-trivial applications to create
additional widget classes as necessary.
When creating additional widgets, I think that the key is to "go with
the grain" of the native widgets. I.e. base the new widget class on an
existing one (e.g. Motif has XmPrimitive and XmManager widget classes,
which exist solely as a base for more specific classes), and honour
any established conventions.
--
Glynn Clements
On Fri, Mar 07, 2003 at 11:48:19AM +0000, Glynn Clements wrote:
Axel Simon wrote:
Providing widgets beyond those of the native platform is a violation of look-and-feel by definition.
Not necessarily.
The standard Xt-based widget sets (Athena, Motif) are both fairly basic, so it's common for non-trivial applications to create additional widget classes as necessary.
When creating additional widgets, I think that the key is to "go with the grain" of the native widgets. I.e. base the new widget class on an existing one (e.g. Motif has XmPrimitive and XmManager widget classes, which exist solely as a base for more specific classes), and honour any established conventions.
Ok, granted. But judgeing from the screenshots of wxWindows, they introduce their own TreeWidget which looks different from Aqua's. And that is to be avoided I think. Axel.
participants (4)
-
Axel Simon -
Daan Leijen -
Glynn Clements -
Wolfgang Jeltsch