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