[GUI] Re: Gtk and Object I/O

[Adrian Hey]

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