On Thu, Jan 23, 2003 at 08:26:57AM -0800, Krasimir Angelov wrote:

--- Axel Simon wrote:

...

Dialogs in Windows are specified in dialog units, i.e. they scale with the font size but cannot be resized by the user: scrap Gtk's dynamic sizing capability.

The Dialogs in Windows also can be resizeable. See: http://www.codeproject.com/dialog/cresizeablefiledialog.asp for example. The example is for MFC but the principle it is also usable with raw Win32 API.

But that is not the natvie look-and-feel of Windows, is it?

...

Buttons on Aqua cannot have icons in them, scrap icons in Gtk and Windows button.

The buttons in Windows has BS_OWNERDRAW style. Using this style the programmer can draw its own content inside the control. This allows to implement "Icon Button" and there are many examples how to make this. As above, you can make Windows do these things, but that means you're loosing the native look-and-feel. The existence of a native look-and-feel under Unix is definitely questionable, but even on Windows you have Win32 applications (most simple 3rd party stuff) and MFC applications. In the latter for example you have icons in buttons and menu items when these actions are present in the task bar. Furthermore, I think I've seen icons in Wizards' "Next ->" and "<- Previous" button. So it's already difficult to say what this native look-and-feel for Windows is.

...

Scrap Aquas hierarchical view in several columns (could be simulated if Windows supports adding columns on the fly, Gtk would), scrap additional columns next to a hierarchical tree since Windows doesn't support that.

There are two solutions: - The library can support two widget types: 1) ListView - multicolumn view without hirerarhical view 2) TreeView - single column hirerarhical view This reduces advantages of multicolumn GtkTreeView under GTK. I think that is not good idea.

- Development of custom multicolumn TreeView under Windows and using GtkTreeView under GTK. There are many already developed multicolumn TreeView controls for MFC. The best implementation which I know is a Stingray CTreeView control. Unfortunately the Stingray Objective Studio isn't freeware and also it requires MFC.

Scrap Window's concept of

...

groups in dialog and keyboard accelerators in general since Aqua doesn't know about hotkeys.

I haven't any experience with MAC platform and don't know any workaroud. Is it too important? How important is a native look-and-feel? It's on position 4 of my priority

But why making it so difficult? Installing Gtk on Windows for development is already quite time-consuming. Maintaining the binding to all these libraries (which might not be supported after a while) will be a nightmare. list as it is such an elusive concept.

...

AFAIK a lot of UI elements on Windows which are considered "standard" are implemented in the Microsoft Foundation Classes. Thus to actually use these, one has to use the MFC written in C++ (or .net).

The only real MFC control is CSplitterWnd control. All the rest MFC controls are just wrappers around standard "Common Controls" implemented in "comctl32.dll". Ok. I thought most of the newer UI elements were exclusivly available via MFC.

<snip>

I think that the reduction can be minimalized. <snip> I completely agree, support for single backend is easier than support of the three: GTK, Win32 and Aqua.

So I wonder: where is the advantage of writing a common-subset layer? Gtk applictaions look a lot like Windows and will disappoint any Aqua user. But its look-and-feel is closer to Windows than say Java Swing. A snapshot of a Gtk2hs program on Windows: http://www.cs.ukc.ac.uk/people/staff/as49/windows.png Cheers, Axel.

I, too, would have concerns about this approach, for some of the same reasons and for a couple of others. First, there is a proxy available for X which cuts down on the amount of traffic. This ameliorates the problem of running on a slow network, but definitely does not eliminate it. In fact, X generates tons of clear text traffic (or gets slowed down even more by using an ssh tunnel, pick your poison). I would prefer that any substantial development effort would eliminate this deficiency, but without giving up the X model where displays are independent of code. Not trivial, but not impossible either. I agree with Glynn (I hope I'm paraphrasing accurately) that it is impractical to support look and feel modularity and also write primitive window management code. It isn't that it is technically impossible, it is just a massive effort and one would want to see convincing evidence that such an effort is worthwhile. I also share his concern about cloning a library; this is a moving target. Especially with reference to MFC whose guts follow no standard and whose intended behavior isn't even available in many cases (as Microsoft keeps it a secret). To me the key is defining the API to toolkit interface carefully and generally, not just so it can interface with currently available toolkits, but also so that there is reasonable confidence that it will interface with likely future toolkits in a reasonable way. Of course, the exact nature of future toolkits is unknown, but educated estimates can be made. Any time you talk about (for example) whether or not to support drag and drop, you are thinking at IMHO too low a level. On 24-Jan-2003 Glynn Clements wrote:

Adrian Hey wrote:

...

Native "Look and Feel" ---------------------- Others will disagree, personally I don't care much about this. Having a "quality look and feel" is important I think, but whether or not it looks like every other App on a particular platform seems unimportant to me.

I'm not particularly concerned about "look" either; but I *am* concerned about "feel". If every other program uses Ctrl-V for paste, but one program doesn't, then that's a bug. Similarly if every other program used the Motif drag-and-drop protocol but one used Xdnd.

The only way that you can reasonably achieve this is by using the native toolkit.

...

1- Forget about interfacing to Gtk,Qt,MFC,TK,WxWindows or whatever. Instead write the entire thing in Haskell (preferably), C (if necessary) and perhaps even the occasional bit of assembler for stuff that must really fly using MMX,Altivec.. 2- Keep the platform specific stuff primitive and relatively simple to implement on any platform. Just basic window management,mouse and keyboard event event handling and blitting pixels to windows.

With X, this approach usually sucks if the program isn't being run on the same system as the X server, and if the intervening connection is slower than ethernet, then the program normally becomes unusable (OTOH, programs which use a decent toolkit and don't have blatant deficiencies can be usable via 64Kbps ISDN).

Also, if you only create shell (top-level) windows, with the individual "widgets" simply being rectangular regions of the shell window, the only way that you can get enter/leave events is to select button-up motion events, which results in a continuous stream of events whenever the mouse moves. Under X, using subwindows is essential for performance.

...

Maybe we need to also consider desktop features like cut&paste and drag&drop here too.

Maybe? I consider that being able to interoperate with other applications is a high priority.

...

For those who like native look and feel, this approach would not prevent an MFC look-alike widget library from being used (if somebody feels inclined to write one:-)

If someone was prepared to write *massive* amounts of code, they might be able to implement an exact copy of a specific version of a standard widget. But if the relevant DLL was updated to a newer version, every program which actually used the native widget would change accordingly, while the clone wouldn't. This wouldn't necessarily be restricted to an appearance change.

The whole approach seems to reflect a lack of understanding of the nature of computer systems. Having shared libraries implement defined APIs isn't solely, or even primarily, about saving people the effort of writing code. More importantly, it's about providing consistency and interoperability.

So, what does an Athena-based program look like? Bear in mind that there are several "improved" versions (Xaw3d, Xaw95, XawXPM etc), that the user can select via e.g. LD_PRELOAD. How is the "coded in Haskell on top of drawing primitives" widget set going to honour this particular configuration setting?

Actually, the approach seems similar to the "web designer" mindset: all that matters is what appears on their screen (probably because that's the only aspect that the designer can actually comprehend).

...

Hmm..maybe that wasn't so short after all. Anyway, I'd be interested in collaborating with anybody else who thinks this is a reasonable approach.

Not me, certainly.

-- Glynn Clements _______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui

-- ---------------------------------- Seth Kurtzberg M. I. S. Corp. E-Mail: seth@cql.com Date: 23-Jan-2003 Time: 21:35:43 This message was sent by XFMail ----------------------------------

Wow! Thanks for your sharing negative opinions. I think you exagerate the difficulties. Sure, any approach to producing a decent "cross platform" gui library for Haskell from scratch is going to require a huge amount of work, but it's been done several times in C or C++ that I know (GTK,Qt,wxWindows,Fox) and I don't see any reason why it shouldn't be done again in Haskell with *far less* effort (well if we really do believe Haskell is a superior language). On Friday 24 January 2003 04:24, Glynn Clements wrote:

Adrian Hey wrote:

...

Native "Look and Feel" ---------------------- Others will disagree, personally I don't care much about this. Having a "quality look and feel" is important I think, but whether or not it looks like every other App on a particular platform seems unimportant to me.

I'm not particularly concerned about "look" either; but I *am* concerned about "feel". If every other program uses Ctrl-V for paste, but one program doesn't, then that's a bug.

Well, this surely isn't a serious problem. How hard can it be to read a configuration file listing appropriate default shortcuts for the appropriate environment?

Similarly if every other program used the Motif drag-and-drop protocol but one used Xdnd.

The only way that you can reasonably achieve this is by using the native toolkit.

...

1- Forget about interfacing to Gtk,Qt,MFC,TK,WxWindows or whatever. Instead write the entire thing in Haskell (preferably), C (if necessary) and perhaps even the occasional bit of assembler for stuff that must really fly using MMX,Altivec.. 2- Keep the platform specific stuff primitive and relatively simple to implement on any platform. Just basic window management,mouse and keyboard event event handling and blitting pixels to windows.

With X, this approach usually sucks if the program isn't being run on the same system as the X server, and if the intervening connection is slower than ethernet, then the program normally becomes unusable (OTOH, programs which use a decent toolkit and don't have blatant deficiencies can be usable via 64Kbps ISDN).

Yes, I'd forgotten about X's network transparency. It's been a long time since I used X over a network (about 10 years), but I seem to remember it sucked, and I guess nothing in my proposal will change that :-) Seriously though, you're right that blitting over a network is not a good idea. But since in what I was proposing the graphic content of windows would be described by something like SVG, maybe a solution for network use would be to translate this into X drawing primitives. This might place some constraints on what could be rendered efficiently, but non that aren't already inherent in X over network.

Also, if you only create shell (top-level) windows, with the individual "widgets" simply being rectangular regions of the shell window, the only way that you can get enter/leave events is to select button-up motion events, which results in a continuous stream of events whenever the mouse moves. Under X, using subwindows is essential for performance.

Well, there's limits to the detail I can go into regarding what I have in mind in a single email, but I don't think this is a problem because windowed graphic content is one of the features I was thinking of. Although I said a windows contents would be described by something like postscript or SVG, these aren't intended to just passive data structures describing a windows appeareance. It's rather more complex than that. But if one were to abandon direct blitting for X over a network, I think it would still map reasonably well to the X api.

...

Maybe we need to also consider desktop features like cut&paste and drag&drop here too.

Maybe? I consider that being able to interoperate with other applications is a high priority.

OK, let's make that "definitely". Is there a problem?

...

For those who like native look and feel, this approach would not prevent an MFC look-alike widget library from being used (if somebody feels inclined to write one:-)

If someone was prepared to write *massive* amounts of code, they might be able to implement an exact copy of a specific version of a standard widget.

But if the relevant DLL was updated to a newer version, every program which actually used the native widget would change accordingly, while the clone wouldn't. This wouldn't necessarily be restricted to an appearance change.

The whole approach seems to reflect a lack of understanding of the nature of computer systems. Having shared libraries implement defined APIs isn't solely, or even primarily, about saving people the effort of writing code. More importantly, it's about providing consistency and interoperability.

Both Qt and wxWindows make the native "look and feel" claim, though I doubt either of them are perfect. No doubt the same would be true of any attempt to do this in Haskell. I wasn't suggecting that anybody should do actually this. But if they did, I don't see why the results should be any worse than they would be with a Haskell binding to Qt or wxWindows.

So, what does an Athena-based program look like? Bear in mind that there are several "improved" versions (Xaw3d, Xaw95, XawXPM etc), that the user can select via e.g. LD_PRELOAD. How is the "coded in Haskell on top of drawing primitives" widget set going to honour this particular configuration setting?

With difficulty I suspect. But like I said, for me this isn't an issue.

Actually, the approach seems similar to the "web designer" mindset: all that matters is what appears on their screen (probably because that's the only aspect that the designer can actually comprehend).

So you don't like web designers. For the record, I'm an engineer.

...

Hmm..maybe that wasn't so short after all. Anyway, I'd be interested in collaborating with anybody else who thinks this is a reasonable approach.

Not me, certainly.

Fine, so how about making a positive contribution? Do you know a way we can have our cake and eat it? How can we guarantee native look and feel across a large variety of platforms, with 1 standard Haskell api without a massive effort in impedance matching code for each and every native library. If you have a solution please don't keep it to yourself. Regards -- Adrian Hey

Adrian, My intention was not to be negative about your proposal, just to bring up some issues that should be discussed. Also, as I note below, the network traffic issue (with X) actually argues in favor of new code rather than reuse. Nevertheless I would not like to underestimate the complexity of the task. As with any large and complex undertaking, it is appropriate to ask "why do this again?". This is not to imply that the answer should always be no, just that the question should be asked and carefully considered. That is only prudent. It is equally foolish to assume the answer to be yes or no; the point is more look before you leap, rather than don't leap. Clearly, whether the look and feel issue is important is a judgment call. (It wasn't my email that brought up the look and feel question, but I do think it is a valid consideration.) I do think it is an important issue, and this is based on input from many users at various levels of ability. I realize your proposal doesn't prohibit attention to look and feel, but it also does not facilitate it. Again, as I said, a judge Ment call about which there is no clear "right" answer. Some more comments: On 24-Jan-2003 Adrian Hey wrote:

Wow! Thanks for your sharing negative opinions. I think you exaggerate the difficulties. Sure, any approach to producing a decent "cross platform" gui library for Haskell from scratch is going to require a huge amount of work, but it's been done several times in C or C++ that I know (GTK,Qt,wxWindows,Fox) and I don't see any reason why it shouldn't be done again in Haskell with *far less* effort (well if we really do believe Haskell is a superior language).

On Friday 24 January 2003 04:24, Glynn Clements wrote:

...

Adrian Hey wrote:

...

Native "Look and Feel" ---------------------- Others will disagree, personally I don't care much about this. Having a "quality look and feel" is important I think, but whether or not it looks like every other App on a particular platform seems unimportant to me.

I'm not particularly concerned about "look" either; but I *am* concerned about "feel". If every other program uses Ctrl-V for paste, but one program doesn't, then that's a bug.

Well, this surely isn't a serious problem. How hard can it be to read a configuration file listing appropriate default shortcuts for the appropriate environment?

Reading a configuration file is not terribly hard. Conforming to look and feel requirements based on the information contained in a configuration file is indeed quite difficult.

...

Similarly if every other program used the Motif drag-and-drop protocol but one used Xdnd.

The only way that you can reasonably achieve this is by using the native toolkit.

...

1- Forget about interfacing to Gtk,Qt,MFC,TK,WxWindows or whatever. Instead write the entire thing in Haskell (preferably), C (if necessary) and perhaps even the occasional bit of assembler for stuff that must really fly using MMX,Altivec.. 2- Keep the platform specific stuff primitive and relatively simple to implement on any platform. Just basic window management,mouse and keyboard event event handling and blitting pixels to windows.

With X, this approach usually sucks if the program isn't being run on the same system as the X server, and if the intervening connection is slower than ethernet, then the program normally becomes unusable (OTOH, programs which use a decent toolkit and don't have blatant deficiencies can be usable via 64Kbps ISDN).

Yes, I'd forgotten about X's network transparency. It's been a long time since I used X over a network (about 10 years), but I seem to remember it sucked, and I guess nothing in my proposal will change that :-) Seriously though, you're right that blitting over a network is not a good idea. But since in what I was proposing the graphic content of windows would be described by something like SVG, maybe a solution for network use would be to translate this into X drawing primitives. This might place some constraints on what could be rendered efficiently, but non that aren't already inherent in X over network.

This is an area where a new GUI toolkit could make a big improvement, by moving this traffic off the wire.

...

Also, if you only create shell (top-level) windows, with the individual "widgets" simply being rectangular regions of the shell window, the only way that you can get enter/leave events is to select button-up motion events, which results in a continuous stream of events whenever the mouse moves. Under X, using subwindows is essential for performance.

Well, there's limits to the detail I can go into regarding what I have in mind in a single email, but I don't think this is a problem because windowed graphic content is one of the features I was thinking of. Although I said a windows contents would be described by something like postscript or SVG, these aren't intended to just passive data structures describing a windows appeareance. It's rather more complex than that. But if one were to abandon direct blitting for X over a network, I think it would still map reasonably well to the X api.

Yes, you are thinking in the same direction as my comment above. An alternative is to handle this with a proxy tunnel; such a tunnel already exists. Clearly the maximum improvement would be obtained with new code.

...

...

Maybe we need to also consider desktop features like cut&paste and drag&drop here too.

Maybe? I consider that being able to interoperate with other applications is a high priority.

OK, let's make that "definitely". Is there a problem?

Again there is the judge Ment call. What does "interoperate" mean? Function? Then there is no problem. Be able to use all programs if you can use one? (Obviously an exaggeration to make the point.) Possibly a problem.

...

...

For those who like native look and feel, this approach would not prevent an MFC look-alike widget library from being used (if somebody feels inclined to write one:-)

If someone was prepared to write *massive* amounts of code, they might be able to implement an exact copy of a specific version of a standard widget.

But if the relevant DLL was updated to a newer version, every program which actually used the native widget would change accordingly, while the clone wouldn't. This wouldn't necessarily be restricted to an appearance change.

The whole approach seems to reflect a lack of understanding of the nature of computer systems. Having shared libraries implement defined APIs isn't solely, or even primarily, about saving people the effort of writing code. More importantly, it's about providing consistency and interoperability.

Both Qt and wxWindows make the native "look and feel" claim, though I doubt either of them are perfect. No doubt the same would be true of any attempt to do this in Haskell. I wasn't suggecting that anybody should do actually this. But if they did, I don't see why the results should be any worse than they would be with a Haskell binding to Qt or wxWindows.

There is no reason. The point is that these other alternatives already exist, so if we choose not to use any of them we should have a good reason that has been carefully examined.

...

So, what does an Athena-based program look like? Bear in mind that there are several "improved" versions (Xaw3d, Xaw95, XawXPM etc), that the user can select via e.g. LD_PRELOAD. How is the "coded in Haskell on top of drawing primitives" widget set going to honour this particular configuration setting?

With difficulty I suspect. But like I said, for me this isn't an issue.

...

Actually, the approach seems similar to the "web designer" mindset: all that matters is what appears on their screen (probably because that's the only aspect that the designer can actually comprehend).

So you don't like web designers. For the record, I'm an engineer.

This wasn't my comment but it isn't germane to the conversation so let's not get off on a tangent here.

...

...

Hmm..maybe that wasn't so short after all. Anyway, I'd be interested in collaborating with anybody else who thinks this is a reasonable approach.

Not me, certainly.

Fine, so how about making a positive contribution? Do you know a way we can have our cake and eat it?

How can we guarantee native look and feel across a large variety of platforms, with 1 standard Haskell api without a massive effort in impedance matching code for each and every native library. If you have a solution please don't keep it to yourself.

Again, this comment wasn't directed to me but I'll respond anyway; I don't have a solution. I'm not trying to discourage the development of a solution. I'm not saying not to make the effort. I would merely like to encourage a thorough technical discussion of all the important issues, because I believe that the problem is more difficult than it first appears. It is likely true, Adrian, that some of the responses have exaggerated the difficulties. I suspect that it is equally true that you have to some extent minimized them. Objections and negative comments (providing they remain in the technical realm and do not descend into unprofessional comments such as the one about web developers which was likely meant as a joke but should have been omitted) are a good way of testing and examining the assumptions that underly a technical proposal. If it were 1905 and Albert Einstein asked me about the theory of relativity, no doubt I would have raised a few hundred objections. That is just my M.O.; what is wrong with this idea? It shouldn't be taken personally, rather as a technique for exploring the design space and getting all issues on the table.

Regards -- Adrian Hey _______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui

-- ---------------------------------- Seth Kurtzberg M. I. S. Corp. E-Mail: seth@cql.com Date: 24-Jan-2003 Time: 08:54:07 This message was sent by XFMail ----------------------------------

On 24-Jan-2003 Nick Name wrote:

On Fri, 24 Jan 2003 04:24:52 +0000 Glynn Clements wrote:

...

If every other program uses Ctrl-V for paste, but one program doesn't

Or, the worse, if every other program can cut and paste attributed text, and my program pastes something like

hi all</color>

or if every other program uses a clipboard manager, and my program uses another (like it happened in the old days trying to mix kde and gtk apps).

Specifically in the area of cut and paste X is an unrecoverable mess. No way to fix this without hacking X itself, so this is a dead end as far as this discussion thread is concerned. Not that the point is not completely valid, just that we'll be stuck with inconsistent use of cut and paste until the end of time, or the end of X, whichever comes first.

Vincenzo

-- Fedeli alla linea, anche quando non c'� Quando l'imperatore � malato, quando muore,o � dubbioso, o � perplesso. Fedeli alla linea la linea non c'�. [CCCP]

_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui

-- ---------------------------------- Seth Kurtzberg M. I. S. Corp. E-Mail: seth@cql.com Date: 24-Jan-2003 Time: 09:31:02 This message was sent by XFMail ----------------------------------

On Friday 24 January 2003 10:06, Axel Simon wrote:

This "let's do it all ourself" sounds very much like the "not-invented-here" syndrome. Please realize that there are libraries out there which are free, portable, well maintained and accomplish all that what you would like to do from scratch. Gtk is one such example.

Sorry Axel, I didn't mean to deprecate your efforts regarding binding to Gtk (or Manuels or Krasimir's ObjectIO binding). I recognise that from a pragmatic viewpoint these are fine libraries which meet the immediate needs of most programmers. But I don't think it's true that they accomplish all that what *I* would like to do, in an ideal world. I'm still of the opinion that whilst expedient, writing a Haskell binding to any complex C (or C++ or Java..) library will prove inconvenient for FP'ers in the end. Of course there's no avoiding this problem entirely, the library has to bind to something at the end of the day unless it's going to talk directly to hardware. I think the more primitive and fewer our primitives are the better, because doing this invloves fewer implicit assumptions about how gui's should work, and IMHO makes porting simpler too. Of course this flexibility comes at the price having to write a useable library on top of these primitives ourselves in Haskell. Something I'm happy to try. But I'm the only one it seems :-) Regards -- Adrian Hey

please please please no. not as a 'standard' GUI interface for haskell. this same thing you propose has been done by everyone and their brother as a pet project and there is no need for us to do it again in haskell. this is what GTK IS! gtk is a portable widget set, gdk is just raw drawing primitives which need to be ported to a platform and gtk is built on top of them. there is no reason to think we will do a better job, if we are willing to go with a common implementation, we might as well use a mature one that already works and takes pains to be efficient and practical across platforms. gtk2hs ALREADY works across windows and unix without hackery. if people havnt already seen it: http://www.t4p.com/xplat.htm describes some of the issues relating to any endevour such as ours. I am strongly in favor of just formalizing a mid-level library as an INTERFACE and leaving the implementation open-ended (with a sample one in gtk2hs since that is the most mature/featurful low-level GUI toolkit for haskell right now) there is no reason the project you describe couldnt be worked on, it sounds useful and fun, but it should not be a 'standard interface'. that said, a low level display PDF/SVG esque layer would be a nice thing to be standardized, but is orthoganol to the widget set GUI concerns. you will find most of the work done for you in drawing libraries built on top of OpenGL which are several. John On Fri, Jan 24, 2003 at 12:41:17AM +0000, Adrian Hey wrote:

So this is what I'm thinking now..

1- Forget about interfacing to Gtk,Qt,MFC,TK,WxWindows or whatever. Instead write the entire thing in Haskell (preferably), C (if necessary) and perhaps even the occasional bit of assembler for stuff that must really fly using MMX,Altivec.. 2- Keep the platform specific stuff primitive and relatively simple to implement on any platform. Just basic window management,mouse and keyboard event event handling and blitting pixels to windows. Maybe we need to also consider desktop features like cut&paste and drag&drop here too.

IMHO these primitives are the only things that would need to be standardised across all platforms. I'm not sure I see any benefit in standardising higher level gui libraries & apis (which should be completely portable anyway if written in Haskell/C). --

John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------

On Fri, Jan 24, 2003 at 03:26:35AM -0800, John Meacham wrote:

if people havnt already seen it: http://www.t4p.com/xplat.htm describes some of the issues relating to any endevour such as ours.

I have read the article. And although I do the gtk2hs binding and think it's the right way to go, I know it's not perfect: - Gtk will inevitably impose its view of UIs on Windows users. But these differences are small since Gtk applications look quite similar to Windows applications. - Gtk will not be ported to Aqua since Aqua is so different. There is only one menu bar, dialogs pop up within main windows, etc. but it will feel ok under XonX (XWindows on Macs) Maybe you can define a GUI library that looks and feels native on every platform without compromising the native style guide (look and feel). But the lack of *any* commercial or free toolkit that fulfills these requirements makes me wonder why a small number of people with a nice language can do it (Wolfgang said that even Java doesn't get it right). Maybe we can, but on what time scale? I do not want another "it's already usable" prototype. Peter, Krasimir, Andrey - when would we be able to go to a company and say "Use Haskell to program your applications!" and would feel comfortable about our (GUI) libraries? 5 years? 10 years? The Gtk library has been under development for over 6 years and they only took an average of all GUIs available and didn't try to combine three huge, constantly changing APIs. I'd rather have a GUI library which runs on all platforms, sacrifices some look-and-feel but is available in a couple of month. I would be more than happy to provide an Object I/O like view of my library, but I know it will look different from the one you implemented in the IFL paper, simply it's geared towards Gtk not Win32. If you think you can give me a specification *today* how a portable Object I/O layer would look like when you finished your approach, I would be more than happy to implement it. Axel.

Adrian Hey wrote:

Native "Look and Feel" ---------------------- Others will disagree, personally I don't care much about this. Having a "quality look and feel" is important I think, but whether or not it looks like every other App on a particular platform seems unimportant to me.

That's what (almost) all X11 users and most Windows users think. They may be right, but on the Mac, the User Interface Laws are considered holy... If I want to write a GUI program for my Mac, native look-and-feel is essentially a precondition. If a toolkit doesn't support a native Mac look and feel, it simply solves the wrong problem for me. Duplicating the Mac look and feel exactly has never worked with cross-platform toolkits. Yes, I maintain that Java Swing is still a failure for Mac OS, although it looks and feels much better than it used to. I happily use Java-based programs on Linux or on Windows, but when I have to use them on the Mac, they just feel out-of-place (even if they already look _almost_ right). It's just no joy using them. Sorry for being negative, I just had to provide a MacOS-centric point of view here. Cheers, Wolfgang