[GUI] Re: Gtk and Object I/O

[Glynn Clements]

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