[GUI] Re: Gtk and Object I/O

[Glynn Clements]

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 <glynn.clements@virgin.net>