Browse thread
Re: [Caml-list] labltk for tk 8.4 BETA release
- Jeffrey Loren Shaw
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jeffrey Loren Shaw <shawjef3@m...> |
| Subject: | Re: [Caml-list] labltk for tk 8.4 BETA release |
* ease of installation http://downloads.activestate.com/ActiveTcl/Windows/8.3.5/ or for the beta labltk... http://downloads.activestate.com/ActiveTcl/Windows/8.4.14/ Yup that link should be updated. I don't think it should be bundled with ocaml, however. The end-user might already have it installed, or might not need it. But this is a decision for the ocaml devs. * Documentation You're right, it's not very good. I used the ocamlbrowser extensively to learn how to use labltk. It took me a lot of experimenting, and I'm still terrible at getting widgets laid out the way I want. I'm not sure how to do the documentation in an automated way without changing the grammar for widgets.src to allow ocamldoc comments. That's beyond my abilities, but I suppose it's a worthy project for someone. On the other hand, widgets.src is already very cluttered. * Other libraries I don't know anything about these, but again these are questions for the ocaml devs. Anyway, my focus right now is getting this beta version of labltk working correctly... there's a lot of functions to test. Now here's an idea... Instead of documenting labltk, which is difficult for the beginner ocaml programmer anyway, make a wrapper to make it more ocaml-y. I'm not sure if this would be easy or possible, but coercing labltk into one style of programming (preferably functional) could go a long way towards making it easier to learn for the beginner. Also the wrapper would potentially be easier to document. As I recall, the most difficult aspects of labltk are those that are imperative, eg: event functions are unit -> unit, (maybe this can't be avoided) pack is difficult to deal with, the need to use optionmenu and Textvariable.handle together is not obvious Another huge but useful project would be a type-safe parser for the outputs given by the Widget.configure_get functions. Now back to testing.