On Tue, Mar 04, 2003 at 12:57:48PM -0800, David Sankel wrote:
Hello,
I would like to clarify my opinion. I would strongly suggest to _not_ use Qt as a backend primarily to license issues. I suggested using the Qt feature-set as a goal feature-set. If there is somebody who wants to write a binding to Qt then that is not a problem. As far as I remember you were about the only one who endorsed Qt.
I think that sound api should be of low priority (aside from the simple windows asterix like sounds when a dialogue pops up). I put sound and printing at the very bottom of the list which should mean
As Simon said, we want to have a spec that is implementable. The only way to ensure this is to propose some functionality, implement it on all backends mentioned in the document and then mark it as stable when it worked out for all backends. That is the only reason I included the list of backends. If there is no one to write a binding to Qt right now, then Qt has to be removed from the list. That doesn't preclude writing a binding to backends not in the list. But such an effort will not influence the spec anymore. So if there are people out there who are willing to write backends for other platforms: now is the time to add them to the report. they have a low priority. I can remove them if other people think this is out of scope but I sense that this effort is nothing that has a definite end but can go on for quite a long time.
Regarding GIO, I am very interested and it seems like the way to go. I can't find it on the internet though. Can someone give me a link so I may review it? Search for GIO on sourceforge.net.
I would suggest putting aside the MDI SDI questions for now, and work on defining a widget set. But we need to know how to set up a main window before we put any widgets in it, don't we? I can imagine that once we are past this stage, adding widgets will be quick and simple.
I adjusted your comment on Qt. Thanks, Axel.
Axel Simon wrote:
That doesn't preclude writing a binding to backends not in the list. But such an effort will not influence the spec anymore. So if there are people out there who are willing to write backends for other platforms: now is the time to add them to the report.
Put me down for Xt/Motif and Xt/Athena. What do I have to write, and
by when?
Also, section 1 mis-states my position:
12 Glynn Clements Opinion:
[snip]
Proposal:
(a) use wxWindows since it uses the native platform and thus
adheres to the native look and feel
I wasn't suggesting using wxWindows itself. Rather, I was suggesting
using the same approach, i.e. a common "veneer" on top of native
widgets (as opposed to actually implementing the widgets in Haskell).
--
Glynn Clements
--- Axel Simon
As Simon said, we want to have a spec that is implementable. The only way to ensure this is to propose some functionality, implement it on all backends mentioned in the document and then mark it as stable when it worked out for all backends. That is the only reason I included the list of backends. If there is no one to write a binding to Qt right now, then Qt has to be removed from the list.
IMHO, there need not be a list of backends supported to make a feature stable. Simply one. Since we are working with Turing Machines here, we know that, in general, if it works for one backend it is possible to implement it for all backends. I suggest pushing our efforts toward creating the standard and a single working implementation. Once this is complete, independant organizations (msft/fsf/consulting companies) would be willing to put resources into supporting and implementing the standard in their own framework. This is what I mean by more bang for the buck.
That doesn't preclude writing a binding to backends not in the list. But such an effort will not influence the spec anymore. So if there are people out there who are willing to write backends for other platforms: now is the time to add them to the report.
In accordance with my opinion above, there would only need to be one platform on the spec.
I think that sound api should be of low priority (aside from the simple windows asterix like sounds when a dialogue pops up). I put sound and printing at the very bottom of the list which should mean they have a low priority. I can remove them if other people think this is out of scope but I sense that this effort is nothing that has a definite end but can go on for quite a long time.
I suggest removing sound and printing from the list. Once CGA 1.0 is released, they can be added in for a 1.1 release. I would like to have it specified exactly what is needed for a 1.0 release and date estimations. I'm going to be working full time on this.
I would suggest putting aside the MDI SDI questions for now, and work on defining a widget set. But we need to know how to set up a main window before we put any widgets in it, don't we? I can imagine that once we are past this stage, adding widgets will be quick and simple.
No, a MainWindow is different than a Window. One can add menus and various widgets to a Window. It can act as a simple SDI. A MainWindow is a window with special requirements such as a menu bar, MDI requirements for a mac and SDI reqirements for Windows/Linux. Since a MainWindow is built upon a Window, we ought to define window first and the widgets it may support, like the ones I mentioned. David J. Sankel
"David" == David Sankel
IMHO, there need not be a list of backends supported to make a feature stable. Simply one. Since we are working with Turing Machines here, we know that, in general, if it works for one backend it is possible to implement it for all backends.
I beg to differ. While there may be some Turing machines involved, they are largely irrelevant. The much more important constraints are those imposed by the designers of the platforms we wish the GUI to work on. These constraints are documented in the API, the design guidelines (i.e., those that specify what a 'native look and feel' is) and in various less formal forms such as existing applications, tutorials, etc. The sad news is that somewhat arbitrary decisions (as well as perfectly sensible decisions) by the GUI library designers can have an enormous impact on how easy it is to implement something and an even more significant impact on whether the result will have a native 'look and feel'. The sadder news is that people programming to these constraints or designing GUI APIs to these constraints often forget that there is another way. Only by implementing and testing the design on multiple GUI platforms can we really achieve a portable design. -- Alastair Reid
--- Alastair Reid
The sadder news is that people programming to these constraints or designing GUI APIs to these constraints often forget that there is another way. Only by implementing and testing the design on multiple GUI platforms can we really achieve a portable design.
I would tend to agree with you except for the enormous number of counter-examples: Qt/Mac was introduced after Qt version 3.0 came out. Qt was used for years before the mac port was even conceptualized. The API did not change drastically with the addition of the macintosh platform. (change from rightclick to contextmenu memberfunctions was about the only api change). The Win32 port of GTK+ and gnome was a complete afterthought of these libraries. In this case, the core library interface didn't change at all and was ported to windows quickly. (ref: http://216.239.57.100/search?q=cache:V3R1bwF33FEC:lists.ximian.com/archives/public/glade-users/2002-April/001535.html+announce+gtk%2B+windows&hl=en&start=7&ie=UTF-8) When Motif was designed, window's didn't even exist. Yet, we still have 4 commercial libraries that allow motif code to run on windows. (ref: http://www.rahul.net/kenton/GettingMotif.html) The list goes on and on: XFree86 and various X11 libraries for windows, OpenGL which came from IRIX and has been everywhere, OpenInventer which has commercial windows implementations, tcl/tk is perhaps one of the best examples, fltk (www.fltk.org), . . . David J. Sankel
The Win32 port of GTK+ and gnome was a complete afterthought of these libraries. In this case, the core library interface didn't change at all and was ported to windows quickly.
Gtk/win32 has NOT native look and feel. Mistakes like the one of gtk are what we are hoping to avoid. Suppose you want the feature "applications running in the bottom bar" (say systray). You implement it just for win32, and then... you have no way to implement the functionality in Xaw, at least not without adding a panel to the Xaw environment, thus forcing a look and feel that is not native. I guess this is what other people mean when they speak about native look and feel, and the necessity of having a good number of backends in mind when designing the interface. Vincenzo
David Sankel wrote:
IMHO, there need not be a list of backends supported to make a feature stable. Simply one. Since we are working with Turing Machines here, we know that, in general, if it works for one backend it is possible to implement it for all backends.
Alastair Reid wrote:
I beg to differ [...]
David Sankel wrote:
I would tend to agree with you except for the enormous number of counter-examples:
Qt/Mac was introduced after Qt version 3.0 came out. Qt was used for years before the mac port was even conceptualized. The API did not change drastically with the addition of the macintosh platform. (change from rightclick to contextmenu memberfunctions was about the only api change).
And applications that use Qt/Mac achieve native look, but not native feel. Qt programs use nested MDI windows on MacOS (which just shouldn't be...). If the API wasn't changed, programs _cannot_ manage the MacOS menu bar properly. The menu bar is not a property of a window, but of the application. I thought that the common agreement was to strive for a suitable abstraction that covers up the conceptual differences. In order to know if that works, we need to look at several platforms from the start. Cheers, Wolfgang
On Wed, Mar 05, 2003 at 10:47:27AM +0000, Axel Simon wrote:
I would suggest putting aside the MDI SDI questions for now, and work on defining a widget set. But we need to know how to set up a main window before we put any widgets in it, don't we? I can imagine that once we are past this stage, adding widgets will be quick and simple.
But we should realize that not all apps will be 'document-centric' apps. I imagine many projects will take the common form of a single drawing widget in a window and some pretty graphics for instance. In any case, MDI SDI is pretty orthogonal to many of our tasks. such as formalizing what the haskell interface will look like which should be one of our first goals. this doesnt mean a list of widget calls, but rather a precise proposal for the form all the widget creation and modification calls in the library will take. (which may evolve as our spec does, but we should have something concrete to write proposed widget interfaces in) John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (7)
-
Alastair Reid -
Axel Simon -
David Sankel -
Glynn Clements -
John Meacham -
Nick Name -
Wolfgang Thaller