Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Does LablTk have a future?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-09-01 (14:09)
From: Chris Campbell <cyberdanx@g...>
Subject: Re: [Caml-list] Does LablTk have a future?
On 01/09/05, Matt Gushee <> wrote:
> Hmm, I'd like to think so. Jef Raskin[*] wrote something to the effect
> that we need better interfaces than what we have now, and something
> better will necessarily be different--with which I heartily agree.
> But in terms of "industry acceptance" in the near term ... I've been
> involved in a number of discussions of why Tk is awful (or not), and one
> point that always comes up is that users allegedly don't like Tk apps
> because they look different.

That's why I was concerned about the development of a gui with regards
to windows and osx.  If it doesn't look like Aqua, if it doesn't look
like Windows it's not going to work.

Once you factor in feel you might as well forget it, especially on
OSX.  People are less than enthusiastic about X apps on OSX.  They
don't behave like Aqua apps and don't follow Mac conventions. 
Similarly with GTk on windows without skinning.

I also don't see a point in reinventing the wheel.  For Linux someone
could probably do better than KDE/Gnome/Enlightenment given a couple
of years, and some might actually use it but no one is gonna like it
on OSX or Windows (which is used by most people).

The best option is to write a high level toolkit over a gui and make
it general enough to use the native gui.  Let's face it, most systems
have buttons, windows, etc and they serve the same purpose on all
systems even if they don't look or behave the same on all systems. 
It's only the api that's different from a programmers perspective and
as programmers that's where the problem is.  Don't turn a problem for
programmers into a problem for users, because they're the ones who
decides the popularity of your software in the end.

Paul Graham wrote about the problems programmers have seeing it from
the user perspective, but I'm not sure which article it is... might be
"Revenge of the nerds".