[GUI] Re: Gtk and Object I/O

[seth@cql.com]

Adrian,

My intention was not to be negative about your proposal, just to bring up some
issues that should be discussed.  Also, as I note below, the network traffic
issue (with X) actually argues in favor of new code rather than reuse. 
Nevertheless I would not like to underestimate the complexity of the task.  As
with any large and complex undertaking, it is appropriate to ask "why do this
again?".  This is not to imply that the answer should always be no, just that
the question should be asked and carefully considered.  That is only prudent. 
It is equally foolish to assume the answer to be yes or no; the point is more
look before you leap, rather than don't leap.

Clearly, whether the look and feel issue is important is a judgment call.  (It
wasn't my email that brought up the look and feel question, but I do think it
is a valid consideration.)  I do think it is an important issue, and this is
based on input from many users at various levels of ability.  I realize your
proposal doesn't prohibit attention to look and feel, but it also does not
facilitate it.  Again, as I said, a judge Ment call about which there is no
clear "right" answer.

Some more comments:

On 24-Jan-2003 Adrian Hey wrote:
> 
> Wow! Thanks for your sharing negative opinions. I think you exaggerate
> 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?

Reading a configuration file is not terribly hard.  Conforming to look and feel
requirements based on the information contained in a configuration file is
indeed quite difficult.

> 
>> 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.

This is an area where a new GUI toolkit could make a big improvement, by moving
this traffic off the wire.

> 
>> 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.   

Yes, you are thinking in the same direction as my comment above.  An
alternative is to handle this with a proxy tunnel; such a tunnel already
exists.  Clearly the maximum improvement would be obtained with new code.

> 
>> >    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?

Again there is the judge Ment call.  What does "interoperate" mean?  Function? 
Then there is no problem.  Be able to use all programs if you can use one? 
(Obviously an exaggeration to make the point.)  Possibly 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.

There is no reason.  The point is that these other alternatives already exist,
so if we choose not to use any of them we should have a good reason that has
been carefully examined.

> 
>> 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.

This wasn't my comment but it isn't germane to the conversation so let's not
get off on a tangent here.

> 
>> > 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.

Again, this comment wasn't directed to me but I'll respond anyway; I don't have
a solution.  I'm not trying to discourage the development of a solution.  I'm
not saying not to make the effort.  I would merely like to encourage a thorough
technical discussion of all the important issues, because I believe that the
problem is more difficult than it first appears.

It is likely true, Adrian, that some of the responses have exaggerated the
difficulties.  I suspect that it is equally true that you have to some extent
minimized them.  Objections and negative comments (providing they remain in the
technical realm and do not descend into unprofessional comments such as the one
about web developers which was likely meant as a joke but should have been
omitted) are a good way of testing and examining the assumptions that underly a
technical proposal.

If it were 1905 and Albert Einstein asked me about the theory of relativity, no
doubt I would have raised a few hundred objections.  That is just my M.O.; what
is wrong with this idea?  It shouldn't be taken personally, rather as a
technique for exploring the design space and getting all issues on the table.

> 
> Regards
> --
> Adrian Hey
> _______________________________________________
> 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: 24-Jan-2003
Time: 08:54:07

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