Re: [Caml-list] Re: Tcl/Tk and RH 9

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Jason Gibson]

 >What about looking at Cairo (Ex Xr/Xc) and either bind to that, or
 >reimplement their protocol in ocaml. Cairo is early enough in its design
 >that it can still be influenced enough if someone looks at it, and
 >points them problems related to doing ocaml bindings.
 >
...
 >Basically it is a vector rendering framework, linked to SVG graphics,
 >and which should enable to have a vector rendering model (on top of the
 >X RENDER extension i think), but which can target various graphic
 >systems, including X, local image buffers and Postscript and PDF as
 >planned output support. I don't know about windows support, but MacOSX
 >support should not be all that difficult to add, and since they also
 >have an OpenGL rendering path, it should run on every OpenGL supported
 >plateform.
...
 >Friendly,
 >Sven Luther


I'm glad to see that I wasn't the only one who thought that xr\cairo\svg 
would make a
good base for windowing toolkits.  I was thinking that having the low level 
functionality
vector based would allow you to do lots of interesting things.  For 
example, you could
do what xml has done, ie allow people to separate out the different classes 
of data easily.
Like how html has presentation\data all bunched together, our vector gui 
could have the
layout\data\communications\etc all separated out, allowing for better 
functionality on
each level. One of the layers of xml-style data could be a communication 
path, allowing your
program to be less dependant on the gui model (like an event loop).  It 
would also let you
expose your gui program to other programs, available for use in a scripted 
environment.

One could build a gui application like one draws a picture.  Each shape 
could be made
separate, so doing things like floating toolbars would be trivial.  You 
just move that particular
shape, and all its children to a new location.  You could group 
programs  together easier by
joining shapes and doing transformations on them.  Maybe you could build 
gui components
as little programs that you connect together, like how you use pipes to 
link a chain of programs.

JG

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[skaller]

On Mon, 2003-08-11 at 19:17, Christoph Bauer wrote:

> > I do. First, it isn't threadable. 
> 
> That's neither true (configure your Tcl/Tk with --enable-threads) nor
> necessary for GUI stuff. I'm quite happy with after and fileevent
> mechanism.

It is true. Tcl is reentrant and threadable, Tk is not
and never will be .. and that's quoting its author.

If you happen, for example, to run GUI apps using
threads in Python you're in for a rude shock.

Of course most people don't run this model, even though
its by far the best way to handle certain GUI things.
Certainly better than the idiotic event loop/callback 
mechanism.

> > Second, whilst the widgets it supports are good, its widget set is
> 
> Text widget and canvas widget are great.

Agree. Tk has some superb widgets, text and canvas being
particularly excellent. But there is no tree widget,
which in todays world is untenable (yes, there is Tix).


> > not only small, it doesn't have certain crucial widgets.  There is
> > no tree widget, for example, you need Tix for that.
> >
> > The extension model is unusable. No one can write
> > Tk extensions. In the whole of its life, hardly any
> > have been written.
> >
> > OTOH, there is wide community support for Gtk.
> 
> With Tk it's much easier to create a GUI than with gtk (and even
> labtgtk). There is a project called Gnocl (gtk for Tcl)> It tries
> to combine the best of both toolkits: (loosly) modeled after the
> Tk API, but based on the better looking and more complete gtk.
> 
> regards,
> Christoph

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Christoph Bauer]

Eray Ozkural <exa@kablonet.com.tr> writes:

> It is now going to sound "bold" to you people, but I don't understand why you 
> can't write the ultimate portable GUI toolkit in ocaml itself. With a 
> language as generic as ocaml it should be a no-brainer to efficiently 
> abstract over peculiarities of windows systems.

It's just too boring to create another platform independent GUI toolkit.
What about to extend lablgtk through camlp4 quotations so that
something like the following line is possible:

let window = << Button ~label:"Quit" ~callback:GMain.Main.quit >>

(equivalent to Tcl/Tk code:
pack [button .b -text Quit -command quit])


or

let editor_window = 
    << VBox 
        [Menu ["File" ["Open" ~callback:open; 
                       "Save" ~callback:save]; 
                        "Help" ["About" ~callback:about]];
         text = Text ~width:80 ~height:24;
         HBox [Button ~label:"Open" ~callback:open; 
               Button ~label:quit ~callback:Main.quit]] >>
                         
The Camlp4 had to 
  * create implizit the window widget
  * generate unused symbols (like the button name)
    but export the widget "text"
  * generate packing (vbox#add) 

Such code is better to maintain and it needs less time
to write. What do you think?

Regards,
Christoph


-- 
proc self {} {foreach c [split [info body self] ""] d {14 -7 0 0 4 -67 4 73 11
69 24 -83 -15 6 -4 -84 78 20 11 -78 -1 -1 79 19 -8 4} { binary scan $c c c
if {[catch {append r [format %c [expr $c+$d]]}]} {return $r};}};puts [self]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Christoph Bauer]

Hi,

>> 
>> RedHat is free to decide whatever they want, but Tk is still the
>> simplest way to develop some software. Tcl/Tk itself is in version
>> 8.4, it had unicode support earlier than Gtk, and is still under
>> active development, and I see no need to kill it.
>
> I do. First, it isn't threadable. 

That's neither true (configure your Tcl/Tk with --enable-threads) nor
necessary for GUI stuff. I'm quite happy with after and fileevent
mechanism.

> Second, whilst the widgets it supports are good, its widget set is

Text widget and canvas widget are great.

> not only small, it doesn't have certain crucial widgets.  There is
> no tree widget, for example, you need Tix for that.
>
> The extension model is unusable. No one can write
> Tk extensions. In the whole of its life, hardly any
> have been written.
>
> OTOH, there is wide community support for Gtk.

With Tk it's much easier to create a GUI than with gtk (and even
labtgtk). There is a project called Gnocl (gtk for Tcl)> It tries
to combine the best of both toolkits: (loosly) modeled after the
Tk API, but based on the better looking and more complete gtk.

regards,
Christoph

-- 
proc self {} {foreach c [split [info body self] ""] d {14 -7 0 0 4 -67 4 73 11
69 24 -83 -15 6 -4 -84 78 20 11 -78 -1 -1 79 19 -8 4} { binary scan $c c c
if {[catch {append r [format %c [expr $c+$d]]}]} {return $r};}};puts [self]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Sven Luther]

On Mon, Aug 11, 2003 at 12:02:06PM +1000, skaller wrote:
> On Mon, 2003-08-11 at 11:20, Eray Ozkural wrote:
> 
> > With GTK, I would worry about its object model, library design, hack-ability, 
> > platform-independence.... The design of gtk seems fairly "backwards" to me. 
> 
> Me too, though I can't claim great familiarity with it.
> 
> > It is now going to sound "bold" to you people, but I don't understand why you 
> > can't write the ultimate portable GUI toolkit in ocaml itself. With a 
> > language as generic as ocaml it should be a no-brainer to efficiently 
> > abstract over peculiarities of windows systems.
> 
> Yeah, that's a good question. The answer is probably: we could,
> but who is going to finance it? Building GUI toolkit is a rather
> large job (its difficult enough to *wrap* a toolkit).
> 
> > Besides, you will find that the limitations of those C/C++ based systems will 
> > be severe. I can make an educated guess because I was designing an ocaml 
> > binding for KDE... If you decide on some kind of binding to a "high level" 
> > toolkit like gtk it's going to be some abstraction layer over black boxes 
> > with a lot of quirks, it's not going to be pretty.
> 
> Sure, but where does one bind? To Xlib? To the X protocol directly?
> If you bind that deep, how do you handle a Windows port of the library?

What about looking at Cairo (Ex Xr/Xc) and either bind to that, or
reimplement their protocol in ocaml. Cairo is early enough in its design
that it can still be influenced enough if someone looks at it, and
points them problems related to doing ocaml bindings.

For those who don't know what cairo is, cairo can be found at :

  http://xr.xwin.org/

And is a : Cross-device Rendering for Vector Graphics.

Basically it is a vector rendering framework, linked to SVG graphics,
and which should enable to have a vector rendering model (on top of the
X RENDER extension i think), but which can target various graphic
systems, including X, local image buffers and Postscript and PDF as
planned output support. I don't know about windows support, but MacOSX
support should not be all that difficult to add, and since they also
have an OpenGL rendering path, it should run on every OpenGL supported
plateform.

That said, it is not a windowing toolkit, just the rendering library,
so i guess writing a proper ocaml toolkit top of it would be nice, and
it would have vector graphics like MAcOSX toolkit. Also, there is
already some work that has been done on vector graphics and ocaml, like
the (non-free) MLGraph library, and the associated publications.

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[skaller]

On Mon, 2003-08-11 at 11:20, Eray Ozkural wrote:

> With GTK, I would worry about its object model, library design, hack-ability, 
> platform-independence.... The design of gtk seems fairly "backwards" to me. 

Me too, though I can't claim great familiarity with it.

> It is now going to sound "bold" to you people, but I don't understand why you 
> can't write the ultimate portable GUI toolkit in ocaml itself. With a 
> language as generic as ocaml it should be a no-brainer to efficiently 
> abstract over peculiarities of windows systems.

Yeah, that's a good question. The answer is probably: we could,
but who is going to finance it? Building GUI toolkit is a rather
large job (its difficult enough to *wrap* a toolkit).

> Besides, you will find that the limitations of those C/C++ based systems will 
> be severe. I can make an educated guess because I was designing an ocaml 
> binding for KDE... If you decide on some kind of binding to a "high level" 
> toolkit like gtk it's going to be some abstraction layer over black boxes 
> with a lot of quirks, it's not going to be pretty.

Sure, but where does one bind? To Xlib? To the X protocol directly?
If you bind that deep, how do you handle a Windows port of the library?

I personally think most widget kits are pretty bad, they're the wrong
idea altogether, especially the stupid callback/event loop paradigm.
I'd be happy to paint buttons myself, etc if the drawing and event
management tools existed in a standard form.

The problem, I think, is that they dont: its actually easier to
standardise widget functionality in the face of distinct underlying
drawing/event primitives/models. But I could be wrong, this isn't my
area of expertise.

OTOH: a portable clean standard Ocaml GUI would be a killer app..
it would make Ocaml the language of choice for deploying user
interfaces and GUI applications.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Eray Ozkural]

On Monday 11 August 2003 03:41, Matt Gushee wrote:
> > GTK on the other hand, isn't the top notch toolkit out there. The
> > technically superior toolkit is Qt *grin*
>
> Hmph. I suppose. I personally don't care for it because it's very slow
> on older machines, and causes XFree86 to lock up on some. Then there's
> the licensing issue on Windows. But better-designed? I guess it probably
> is.

With GTK, I would worry about its object model, library design, hack-ability, 
platform-independence.... The design of gtk seems fairly "backwards" to me. I 
remember how bad the C++ bindings were and I don't think the situation has 
changed much. This is not to say Qt would be a better "choice" for ocaml 
because that too is designed with an imperative PL with a not-very-cool type 
system: C++. However, it is more effective in that domain as evidenced by 
existing code...

It is now going to sound "bold" to you people, but I don't understand why you 
can't write the ultimate portable GUI toolkit in ocaml itself. With a 
language as generic as ocaml it should be a no-brainer to efficiently 
abstract over peculiarities of windows systems.

Besides, you will find that the limitations of those C/C++ based systems will 
be severe. I can make an educated guess because I was designing an ocaml 
binding for KDE... If you decide on some kind of binding to a "high level" 
toolkit like gtk it's going to be some abstraction layer over black boxes 
with a lot of quirks, it's not going to be pretty.

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Matt Gushee]

On Mon, Aug 11, 2003 at 02:15:42AM +0300, Eray Ozkural wrote:
> I must point out that skaller's claims are factually wrong in his post that I 
> replying to. tkinter is the python bindings to tk. It's normal that it isn't 
> included in that standard lousy 1 CD red hat installation.
> 
> Debian package:
> python2.3-tk - Tkinter - Writing Tk applications with Python (v2.3)
> 
> tcl/tk is *not* the same thing as tkinter.

Ah, yes ... being a Python programmer, and a former Tcl programmer, I
should have noticed that myself.

> Besides, Red Hat is *not* the de facto linux distro. There are maybe 100 
> distros right now.

Quite true, but he was referring spefically to the enterprise market.
Red Hat is arguably the de facto standard for large organizations in the
Anglo world (which I am well aware is not the whole world, but it's
where Monsieur Skaller and I both live).

> GTK on the other hand, isn't the top notch toolkit out there. The technically 
> superior toolkit is Qt *grin*

Hmph. I suppose. I personally don't care for it because it's very slow
on older machines, and causes XFree86 to lock up on some. Then there's
the licensing issue on Windows. But better-designed? I guess it probably
is.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Eray Ozkural]

On Monday 11 August 2003 02:15, Eray Ozkural wrote:
> I must point out that skaller's claims are factually wrong in his post that
> I replying to. tkinter is the python bindings to tk. It's normal that it

I am replying to...

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Eray Ozkural]

I must point out that skaller's claims are factually wrong in his post that I 
replying to. tkinter is the python bindings to tk. It's normal that it isn't 
included in that standard lousy 1 CD red hat installation.

Debian package:
python2.3-tk - Tkinter - Writing Tk applications with Python (v2.3)

tcl/tk is *not* the same thing as tkinter.

In fact, tcl/tk is pretty standard in all linux distros. The "deep" GUI to gdb 
insight developed at Red Hat exclusively uses tcl/tk/itcl/itk. tcl/tk is also 
perfect for cross-platform applications. It runs solidly on both windows and 
unix families on OSs incredibly well.

Besides, Red Hat is *not* the de facto linux distro. There are maybe 100 
distros right now.

GTK on the other hand, isn't the top notch toolkit out there. The technically 
superior toolkit is Qt *grin*

On Monday 11 August 2003 00:26, skaller wrote:
> This is a standard, out of the box install of RH9.
> If, for example, Government departments buy a heap
> of Linux boxes and install RH9, they won't get Tk
> as part of the deal.
>
> So it would be foolish to continue development of
> products that use it if you want to be part of the
> growing market of vendors of enterprise level packages
> for Linux.
>
> Redhat has swung soldily behind Gtk. To the point
> Tk is no longer considered worth installing by default.
> Enterprise software such as Open Office doesn't use it.
> It is no longer part of the enterprise level users
> software base.
>
>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/ Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[skaller]

On Sun, 2003-08-10 at 11:53, Alexander V. Voinov wrote:

> I do not mean that this would turn me to like 
> Tcl/Tk, but this is the reality we face.

This is the reality we face:
-----------------------------------------------
[skaller@localhost] ~>python
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named Tkinter
>>>
--------------------------------------------
This is a standard, out of the box install of RH9.
If, for example, Government departments buy a heap
of Linux boxes and install RH9, they won't get Tk
as part of the deal.

So it would be foolish to continue development of
products that use it if you want to be part of the
growing market of vendors of enterprise level packages
for Linux.

Redhat has swung soldily behind Gtk. To the point
Tk is no longer considered worth installing by default.
Enterprise software such as Open Office doesn't use it.
It is no longer part of the enterprise level users
software base.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Tcl/Tk and RH 9

[skaller]

On Sun, 2003-08-10 at 11:43, Jacques Garrigue wrote:
> From: skaller <skaller@ozemail.com.au>
> 
> > Just a comment: I have just installed RedHat 9 on my box.
> > Tcl/Tk is no longer a standard package, which is as it should be,
> > its an old, archaic system which no longer deserves any support.
> 
> RedHat is free to decide whatever they want, but Tk is still the
> simplest way to develop some software. Tcl/Tk itself is in version
> 8.4, it had unicode support earlier than Gtk, and is still under
> active development, and I see no need to kill it.

I do. First, it isn't threadable. Second, whilst the
widgets it supports are good, its widget set is not only
small, it doesn't have certain crucial widgets.
There is no tree widget, for example, you need Tix for that.

The extension model is unusable. No one can write
Tk extensions. In the whole of its life, hardly any
have been written.

OTOH, there is wide community support for Gtk.

> I suppose a move to Gtk will eventually take place.
> For this Gtk2 is a requirement (Gtk lacks some essential widgets
> present in Tk).

Yeah, Gtk 1 was pretty bad. Some widgets didn't work
properly. That's the case in 2 as well :(
The edit widget is not good, compared to Tk's.
Morons are trying to copy Windows :(
It still doesn't edit correctly.

The tree widget doesn't work properly in your demo
by the way: when you delete an item it just clears
the line, doesn't redraw the tree properly.

>  But LablGtk2 is now usable enough we can start to
> think about it.

The whole of my desktop uses Gnome/Gtk.

> So yes, I see a change ahead, but certainly not in 3.07!
> And of course labltk/camltk support will not be dropped.

That was my question: whether there will be a move to Gtk.
Whilst labltk doesn't need to have support dropped,
I can't see it being worth doing continued work in it:
it becomes a deprecated tool.

Lots of nice things could be done with OcamlBrowser,
for example. You can't do that work twice. You have to pick
which model to extend. That's Tk now, until Gtk version
is up to scratch, and Gtk itself is up to scratch.

Some of the work is just too hard in Tk. For example
it doesn't reparent correctly. Gtk does. There is a 
workaround in Tk, but it only works 'to some extent'
and that workaround defeats some of its functionality.
[Basically all Tk widgets have to be top level names
or they can't be reparented: HWM is all about reparenting :-]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Tcl/Tk and RH 9

[Alexander V. Voinov]

Hi All,

Jacques Garrigue wrote:

> From: skaller <skaller@ozemail.com.au>
> 
>>Just a comment: I have just installed RedHat 9 on my box.
>>Tcl/Tk is no longer a standard package, which is as it should be,
>>its an old, archaic system which no longer deserves any support.
> 
> 
> RedHat is free to decide whatever they want, but Tk is still the
> simplest way to develop some software. 

If a biotech witness means anything, I have just two commercial examples 
recently: Partek is using Tcl for internal (user-available) scripting and just 
yesterday we had a demo in-house, by the author, of the PyMOL package, which is 
written using Tkinter and OpenGL. I do not mean that this would turn me to like 
Tcl/Tk, but this is the reality we face.

Alexander



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Tcl/Tk and RH 9

[Jacques Garrigue]

From: skaller <skaller@ozemail.com.au>

> Just a comment: I have just installed RedHat 9 on my box.
> Tcl/Tk is no longer a standard package, which is as it should be,
> its an old, archaic system which no longer deserves any support.

RedHat is free to decide whatever they want, but Tk is still the
simplest way to develop some software. Tcl/Tk itself is in version
8.4, it had unicode support earlier than Gtk, and is still under
active development, and I see no need to kill it.

> Unfortunately LablTk needs it, and some Caml tools use it.
> OCamlBrowser being one.
> 
> Time to move to Gtk? Alternatively, a simple GUI which can 
> use either? Or even Windows or Mac style Guis?

I suppose a move to Gtk will eventually take place.
For this Gtk2 is a requirement (Gtk lacks some essential widgets
present in Tk). But LablGtk2 is now usable enough we can start to
think about it.

So yes, I see a change ahead, but certainly not in 3.07!

And of course labltk/camltk support will not be dropped.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners