[GUI] Re: Gtk and Object I/O

[seth@cql.com]

I, too, would have concerns about this approach, for some of the same reasons
and for a couple of others.

First, there is a proxy available for X which cuts down on the amount of
traffic.  This ameliorates the problem of running on a slow network, but
definitely does not eliminate it.

In fact, X generates tons of clear text traffic (or gets slowed down even more
by using an ssh tunnel, pick your poison).  I would prefer that any substantial
development effort would eliminate this deficiency, but without giving up the X
model where displays are independent of code.  Not trivial, but not impossible
either.

I agree with Glynn (I hope I'm paraphrasing accurately) that it is impractical
to support look and feel modularity and also write primitive window management
code.  It isn't that it is technically impossible, it is just a massive effort
and one would want to see convincing evidence that such an effort is worthwhile.

I also share his concern about cloning a library; this is a moving target. 
Especially with reference to MFC whose guts follow no standard and whose
intended behavior isn't even available in many cases (as Microsoft keeps it a
secret).

To me the key is defining the API to toolkit interface carefully and generally,
not just so it can interface with currently available toolkits, but also so
that there is reasonable confidence that it will interface with likely future
toolkits in a reasonable way.  Of course, the exact nature of future toolkits
is unknown, but educated estimates can be made.

Any time you talk about (for example) whether or not to support drag and drop,
you are thinking at IMHO too low a level.

On 24-Jan-2003 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. 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>
> _______________________________________________
> GUI mailing list
> GUI@haskell.org
> http://www.haskell.org/mailman/listinfo/gui

-- 
----------------------------------
Seth Kurtzberg
M. I. S. Corp.
E-Mail: seth@cql.com
Date: 23-Jan-2003
Time: 21:35:43

This message was sent by XFMail
----------------------------------