Adrian Hey wrote:
Wow! Thanks for your sharing negative opinions. I think you exagerate the difficulties.
I'm not concerned with the "difficulties"; I'm concerned with the end result. It isn't that the lightweight approach requires work, it's that I consider it to be fundamentally flawed. For example: completely re-implementing Xlib in Haskell (after all, most of Xlib boils down to sending and receiving data via a socket) wouldn't be the same thing as providing bindings to the system's native Xlib. If a platform provides a specific function for a particular task, then the correct solution is to call that function. Providing exactly the same functionality through a parallel library *isn't* the same. You may be able to get asymptotically similar behaviour, but it will never be exactly the same thing. Whether or not the difference is significant depends upon the specific circumstances.
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).
The problem isn't the amount of effort, but the fact that the end result (of not using the OS' existing functionality) is fundamentally flawed. IMO, GTK and Qt both suck, because they are at some level incompatible with the existing UI mechanism (at least on platforms where they aren't themselves the existing UI mechanism; this doesn't apply to Gnome/KDE, but it definitely applies to using GTK/Qt in a Motif/CDE environment). wxWindows works, because it takes exactly the opposite approach to what you're proposing. A wxWindows widget is a wrapper around the platform's native widget, so you get native look and feel in all regards. This is the approach which I'm advocating.
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?
1. Having a separate config file is a nuisance, but 2. Reading the native configuration is potentially very complex (e.g. if the native environment is Xt, which obtains the configuration by merging several files plus the values of properties from the X server). 3. Keyboard shortcuts are only part of it; there's also issues such as different focus models, input methods for non-ASCII text etc.
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 :-)
X itself doesn't inherently suck. What sucks is when you're using a toolkit written by someone who either simply overlooked the issue, or looked into it then decided that everything would be simpler if they just pretended that X works like Windows. But it doesn't. Sucking over a 64Kbps ISDN is probably not too big a problem; a more realistic scenario is a university CS lab with 50 systems sharing a 10Mbps ethernet. In this kind of environment, the difference between a real toolkit and a "let's pretend it's Windows" toolkit matters.
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?
The problem is that interoperability may go a lot further than just cut-and-paste or drag-and-drop; e.g. DDE/OLE. My experience of "lightweight" toolkits suggests that their authors don't realise just how complex a push button can be.
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.
Qt implements native look and feel; if the native environment is KDE, that is. As I mentioned above, wxWindows actually uses the platform's native widgets; what I'm arguing is that this is what you *have* to do if you want native look and feel.
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?
Use native widgets.
How can we guarantee native look and feel across a large variety of platforms, with 1 standard Haskell api
Use native widgets.
without a massive effort in impedance matching code for each and every native library.
My view is that this is something that just has to be done. Bear in
mind that the effort of "impedance matching" is offset by not having
to actually implement any widgets.
--
Glynn Clements