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.