Re: [GUI] Re: Gtk and Object I/O

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