[Caml-list] OCaml vs Ada and/or GUI options

[Caml-list] OCaml vs Ada and/or GUI options

[Gour]

Hello,

TL;DR: Which type-safe language (I'm considering OCaml & Ada)
would you recommend me for writing multi-platform open-source GUI app
using some GUI (except GTK) bindings and why?

Long version...
Some years ago I was considering which language to use for
writing multi-platform open-source GUI application. Considering it's
meant to be done as hobby project, I wanted to avoid C(++), fiddling
with pointers, memory allocation and other low-level stuff and hoped to
use some more type-safe language to eliminate certain kind of bugs nad
have more fun when programming.

The idea of FP seemed interesting and I did start learning Haskell which
was fun, but few potential contributors who showed up for the project,
found Haskell's learning curve too steep and I admit that reading too
many papers about category theory, monads everywhere was not too
appealing to me as well.

Contributors run away and I had to postpone the project.

Later, when considering to revive idea of doing the project I did
consider D, but found out it still too unstable and GTK bindings are
practically the only choice.

Some further exploration has brought me to Ada which seems to be very
mature language, has performant compiler GNAT and even Qt bindings.

Moreover, Ada's 2012 features with contracts & multi-core support look
nice.

For a short time I did considered OCaml, but although pleased with the
language itself (although, based on my familiarity with both, I consider
Haskell's syntax a bit cleaner), only GTK bindings were not satisfying.
I know the bindings are mature, but GTK itself has poor support on
Windows & Mac OS, small team of core devs, does not look good on
non-Linux etc. and the recent steps with GTK3 & roadmap for GTK4 (where
the  GTK devs say that the toolkit is meant for 'small apps only' does
not look promising). On top of that, I only see projects moving from GTK
to Qt...

For a short time I explored some exotic languages like Nimrod
(interesting, but small community, only GTK bindings), then Cobra & F# -
despite getting encouraging input: "I'd recommend F# hands down. OCaml
is still a 1990s language."
(http://stackoverflow.com/questions/12437792/converting-ocaml-to-f-is-there-an-ocaml-ide-with-gui-debugging-like-visual-stu/13076028#13076028),
somehow I do not like idea of embracing NET/Mono considering that even
do not have Mono installed on my (Debian) machine.

Go lang is not interested for me, do not like Java stuff, Rust is not
finished... which led me to Ada (or Python+Cython+PyQt as last resort).
Actually, I was thinking to write backend stuff in Ada and then possibly
use PyQt as GUI front-end.

However, in a recent time when visiting OCaml's web site I could see
that lot of things are going on...compiler is getting improved with
multi-core support, lablQt, wxOCaml bindings, OPAM, editor tools...

It looks as there is some kind of OCaml revival or am I completely
wrong?

Whatever it is, now I'm again looking closely to OCaml and although I am
aware that the two languages are meant for programming in quite
different styles/paradigms, I'd be grateful if someone can shed some
comment and/or enhance my observations:

a) both Ada and OCaml seems to have mature & robust compiler generating
native code and although language-shootout's benchmarks are in favour of
Ada, I believe that in practice OCaml compiler can generate quick-enough
code for 'general GUI app' which is not too behind C(++) code

b) both Ada & OCaml languages seems to be suitable languages for good
engineering practice writing type-safe code discovering lot of bugs
duing the development/compile phase albeit using different paradigms
(e.g. imperative vs FP)

c) both languages seems to have decent tools support - I am mostly
satisfied using Vim -  Ada has GNAT IDE and gprbuild system, but OCaml
OPAM seems to improve situation a lot.

d) Ada has mature GTK bindings and two projects with Qt bindings, but
the more mature ones are not certain about Qt5 support. Otoh, OCaml's
GTK bindings seems to be mature, but that does not influence me much
considering general status of GTK's multi-platform support.

I see that there is labltk project, some work on lablqt as well as
wxOCcaml...Tk could be interesting 'cause I heard that it looks nice in
newer releases and it is not so bloated.

Lablqt initiative is inspiring, but does not, afaict, enjoy much support
withing community, while wxOCaml project is tempting due to the reason
that for long time (even while playing with Haskell) I was looking at wx
bindings 'cause those are the only ones using native toolkits and
looking good everywhere, although *today* I might be more please if
OCamlPro would be behind lablqt for the simple reason of the state of Qt
project vs wxWidgets.

Another concern is whether wxOCaml is just a testing prototype or
something one can count on?

e) both Ada & OCaml are suited for open-source projects, but my
impression is that OCaml's community is larger with much more projects
and things going on while the Ada's open-source community is pretty
limited and/or closed withing proprietary projects only.

In #ocaml I was told that neither Ada nor OCaml are very suitable for
writing GUI apps, but I still believe there is use-case for classical
desktop apps and that it's not true that everything has to run within
browser. :-)

Can anyone provide some comments about my (imperfect) analysis and
correct and misunderstanding I might have as well as providing some
points which might be relevant to properly decide which
language/ecosytem might be more suitable for my need of writing
multi-platform open-source app using some GUI bindings?

Besides that, I also have need for using Sqlite3 as well as 3rd party C
lib providing some calculation functions. Any tool helping generating
bindings for C libs?


Sincerely,
Gour

-- 
The spirit soul bewildered by the influence of false ego thinks 
himself the doer of activities that are in actuality carried out 
by the three modes of material nature.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Paolo Donadeo]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

TL;DR: being an OCaml programmer now, and having worked with Ada
(avionics/military sector) for a few years, my reply is: none of the two :-)

Long version: I should copy&paste your long version, I agree with your
analysis. In my opinion the best for good-looking GUI is Python+PyQT, which
is a really mature and stable environment. Avoid C++ + QT, it's stable of
course, but using C++ in 2013 is a *real* PITA. Python is totally unsafe,
but in tandem with PyQT takes you to a very fast and productive environment.

GTK: my personal opinion is that it's an awful toolkit, from each and every
point of view. Bad software design, horrible widgets, etc... The OCaml
binding is probably (from the programmer point of view) *better* than the
original C API, but it's still a pain.

Just my 2 ¢ of course.


-- 
*Paolo*

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Francois Berenger]

You could also clearly decouple the "engine" of your software
from its GUI.

As was done in MLDonkey and plan9's sam test editor:
http://plan9.bell-labs.com/sys/doc/sam/sam.html

On 09/11/2013 06:09 AM, Gour wrote:
> Hello,
>
> TL;DR: Which type-safe language (I'm considering OCaml & Ada)
> would you recommend me for writing multi-platform open-source GUI app
> using some GUI (except GTK) bindings and why?
>
> Long version...
> Some years ago I was considering which language to use for
> writing multi-platform open-source GUI application. Considering it's
> meant to be done as hobby project, I wanted to avoid C(++), fiddling
> with pointers, memory allocation and other low-level stuff and hoped to
> use some more type-safe language to eliminate certain kind of bugs nad
> have more fun when programming.
>
> The idea of FP seemed interesting and I did start learning Haskell which
> was fun, but few potential contributors who showed up for the project,
> found Haskell's learning curve too steep and I admit that reading too
> many papers about category theory, monads everywhere was not too
> appealing to me as well.
>
> Contributors run away and I had to postpone the project.
>
> Later, when considering to revive idea of doing the project I did
> consider D, but found out it still too unstable and GTK bindings are
> practically the only choice.
>
> Some further exploration has brought me to Ada which seems to be very
> mature language, has performant compiler GNAT and even Qt bindings.
>
> Moreover, Ada's 2012 features with contracts & multi-core support look
> nice.
>
> For a short time I did considered OCaml, but although pleased with the
> language itself (although, based on my familiarity with both, I consider
> Haskell's syntax a bit cleaner), only GTK bindings were not satisfying.
> I know the bindings are mature, but GTK itself has poor support on
> Windows & Mac OS, small team of core devs, does not look good on
> non-Linux etc. and the recent steps with GTK3 & roadmap for GTK4 (where
> the  GTK devs say that the toolkit is meant for 'small apps only' does
> not look promising). On top of that, I only see projects moving from GTK
> to Qt...
>
> For a short time I explored some exotic languages like Nimrod
> (interesting, but small community, only GTK bindings), then Cobra & F# -
> despite getting encouraging input: "I'd recommend F# hands down. OCaml
> is still a 1990s language."
> (http://stackoverflow.com/questions/12437792/converting-ocaml-to-f-is-there-an-ocaml-ide-with-gui-debugging-like-visual-stu/13076028#13076028),
> somehow I do not like idea of embracing NET/Mono considering that even
> do not have Mono installed on my (Debian) machine.
>
> Go lang is not interested for me, do not like Java stuff, Rust is not
> finished... which led me to Ada (or Python+Cython+PyQt as last resort).
> Actually, I was thinking to write backend stuff in Ada and then possibly
> use PyQt as GUI front-end.
>
> However, in a recent time when visiting OCaml's web site I could see
> that lot of things are going on...compiler is getting improved with
> multi-core support, lablQt, wxOCaml bindings, OPAM, editor tools...
>
> It looks as there is some kind of OCaml revival or am I completely
> wrong?
>
> Whatever it is, now I'm again looking closely to OCaml and although I am
> aware that the two languages are meant for programming in quite
> different styles/paradigms, I'd be grateful if someone can shed some
> comment and/or enhance my observations:
>
> a) both Ada and OCaml seems to have mature & robust compiler generating
> native code and although language-shootout's benchmarks are in favour of
> Ada, I believe that in practice OCaml compiler can generate quick-enough
> code for 'general GUI app' which is not too behind C(++) code
>
> b) both Ada & OCaml languages seems to be suitable languages for good
> engineering practice writing type-safe code discovering lot of bugs
> duing the development/compile phase albeit using different paradigms
> (e.g. imperative vs FP)
>
> c) both languages seems to have decent tools support - I am mostly
> satisfied using Vim -  Ada has GNAT IDE and gprbuild system, but OCaml
> OPAM seems to improve situation a lot.
>
> d) Ada has mature GTK bindings and two projects with Qt bindings, but
> the more mature ones are not certain about Qt5 support. Otoh, OCaml's
> GTK bindings seems to be mature, but that does not influence me much
> considering general status of GTK's multi-platform support.
>
> I see that there is labltk project, some work on lablqt as well as
> wxOCcaml...Tk could be interesting 'cause I heard that it looks nice in
> newer releases and it is not so bloated.
>
> Lablqt initiative is inspiring, but does not, afaict, enjoy much support
> withing community, while wxOCaml project is tempting due to the reason
> that for long time (even while playing with Haskell) I was looking at wx
> bindings 'cause those are the only ones using native toolkits and
> looking good everywhere, although *today* I might be more please if
> OCamlPro would be behind lablqt for the simple reason of the state of Qt
> project vs wxWidgets.
>
> Another concern is whether wxOCaml is just a testing prototype or
> something one can count on?
>
> e) both Ada & OCaml are suited for open-source projects, but my
> impression is that OCaml's community is larger with much more projects
> and things going on while the Ada's open-source community is pretty
> limited and/or closed withing proprietary projects only.
>
> In #ocaml I was told that neither Ada nor OCaml are very suitable for
> writing GUI apps, but I still believe there is use-case for classical
> desktop apps and that it's not true that everything has to run within
> browser. :-)
>
> Can anyone provide some comments about my (imperfect) analysis and
> correct and misunderstanding I might have as well as providing some
> points which might be relevant to properly decide which
> language/ecosytem might be more suitable for my need of writing
> multi-platform open-source app using some GUI bindings?
>
> Besides that, I also have need for using Sqlite3 as well as 3rd party C
> lib providing some calculation functions. Any tool helping generating
> bindings for C libs?
>
>
> Sincerely,
> Gour
>

Re: [Caml-list] OCaml vs Ada and/or GUI options

[rixed]

-[ Wed, Sep 11, 2013 at 10:00:50AM +0900, Francois Berenger ]----
> You could also clearly decouple the "engine" of your software
> from its GUI.

Is there something like gtk-server for qt?

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

Hi,

On Tue, Sep 10, 2013, Paolo Donadeo wrote:
> GTK: my personal opinion is that it's an awful toolkit, from each and every
> point of view. Bad software design, horrible widgets, etc... The OCaml
> binding is probably (from the programmer point of view) *better* than the
> original C API, but it's still a pain.

I'm trying to get a list of things that people find bad in (labl)gtk.
Would you be able to put clear words on what you dislike?

I'm looking for input from anyone and you can mail me directly if you
don't want to flood the list (or send a message on IRC).

Thanks,
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Kakadu]

The idea behind lablqt it to generated some C++ code while programmer
will not be needed to look inside it. Also, lablqt is more oriented on
using QtQuick instead QtWidgets, so your argument about developing in
C++ is not so strong in case lablqt.


Kakadu

On Wed, Sep 11, 2013 at 9:24 AM, Adrien Nader <adrien@notk.org> wrote:
> Hi,
>
> On Tue, Sep 10, 2013, Paolo Donadeo wrote:
>> GTK: my personal opinion is that it's an awful toolkit, from each and every
>> point of view. Bad software design, horrible widgets, etc... The OCaml
>> binding is probably (from the programmer point of view) *better* than the
>> original C API, but it's still a pain.
>
> I'm trying to get a list of things that people find bad in (labl)gtk.
> Would you be able to put clear words on what you dislike?
>
> I'm looking for input from anyone and you can mail me directly if you
> don't want to flood the list (or send a message on IRC).
>
> Thanks,
> Adrien Nader
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gabriel Kerneis]

On Tue, Sep 10, 2013 at 11:09:28PM +0200, Gour wrote:
> I still believe there is use-case for classical desktop apps and that
> it's not true that everything has to run within browser. :-)

Note that "desktop app" and "run within browser" are not necessarily
exclusive: Light Table [1] is an example of an application that runs a
tiny webserver (written in Clojure) locally on your desktop, and uses
node-webkit [2] for its GUI. Node-webkit requires HTML+javascript for
the UI of course, but the latter can be compiled from Clojure by
ClojureScript [3] or, in the case of OCaml, Js_of_ocaml [4]. And you can
embed node-webkit in your distribution, which means that you do not need
to test a gazillion browsers in the wild.

-- Gabriel

[1] http://www.chris-granger.com/lighttable/
[2] https://github.com/rogerwang/node-webkit
[3] https://github.com/clojure/clojurescript
[4] http://ocsigen.org/js_of_ocaml/

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Tue, 10 Sep 2013 23:38:56 +0200
Paolo Donadeo <p.donadeo@gmail.com> wrote:

> TL;DR: being an OCaml programmer now, and having worked with Ada
> (avionics/military sector) for a few years, my reply is: none of the
> two :-)

That's just the answer I was afraid to get. :-)

> Avoid C++ + QT, it's stable of course, but using C++ in 2013 is a
> *real* PITA. 

C(++) is certainly not on my radar. :-)

> Python is totally unsafe, but in tandem with PyQT takes you to a very
> fast and productive environment.

That's true, but I wonder whether I should trade type-safety for fast
and productive environment?

It is supposed to be open-source project and we do not have any
deadlines to meet, so I consider that less bugs/debugging is better.

> GTK: my personal opinion is that it's an awful toolkit, from each and
> every point of view. Bad software design, horrible widgets, etc...

I consider that GTK lost its course and it's not even attractive to
LInux users, what to say about Windows/Mac platforms.

> The OCaml binding is probably (from the programmer point of view)
> *better* than the original C API, but it's still a pain.

That I cannot comment, but I believe it's the best what OCaml has, but
having e.g. Qt bindings would probably change the picture of OCaml &
GUI, right?

> Just my 2 ¢ of course.

Thanks a lot.


Sincerely,
Gour

-- 
As the embodied soul continuously passes, in this body, 
from boyhood to youth to old age, the soul similarly passes 
into another body at death. A sober person is not bewildered 
by such a change.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 07:24:37 +0200
Adrien Nader <adrien@notk.org> wrote:

> I'm trying to get a list of things that people find bad in (labl)gtk.
> Would you be able to put clear words on what you dislike?

I can't say much about lablgtk, but as far as gtk is concerned, I
believe there is no future for it multi-platform wise.

Have you read/seen:

http://lwn.net/Articles/562856/ 
http://www.superlectures.com/guadec2013/gtk-to-infinity-and-beyond 


Otoh, Qt project is strongly positioned with many devs, actively
developed, no problem with the license etc. and my humble suggestion is
to put lablgtk into maint. mode and focus, as community, on providing
lablqt to attract new users to write GUI apps in such a fine language as
OCaml.


Sincerely,
Gour

-- 
One who is not disturbed in mind even amidst the threefold 
miseries or elated when there is happiness, and who is free 
from attachment, fear and anger, is called a sage of steady mind.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 10:00:50 +0900
Francois Berenger <berenger@riken.jp> wrote:

> You could also clearly decouple the "engine" of your software
> from its GUI.

And what to use for GUI?

> As was done in MLDonkey and plan9's sam test editor:
> http://plan9.bell-labs.com/sys/doc/sam/sam.html

Thank you, I'll take a look.


Sincerely,
Gour

-- 
He is a perfect yogī who, by comparison to his own self, 
sees the true equality of all beings, in both their 
happiness and their distress, O Arjuna!

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

On Wed, 11 Sep 2013 08:38:54 +0100
Gabriel Kerneis <gabriel@kerneis.info> wrote:

> Note that "desktop app" and "run within browser" are not necessarily
> exclusive: 

That's true, but that involves JS-stuff which I'm not so fond of. :-)

It's certainly good multi-platform solution, but I'm afraid that JS
spoils the party.


Sincerely,
Gour

-- 
In the material world, one who is unaffected by whatever good 
or evil he may obtain, neither praising it nor despising it, 
is firmly fixed in perfect knowledge.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 11:21:58 +0400
Kakadu <kakadu.hafanana@gmail.com> wrote:

> The idea behind lablqt it to generated some C++ code while programmer
> will not be needed to look inside it. Also, lablqt is more oriented on
> using QtQuick instead QtWidgets, so your argument about developing in
> C++ is not so strong in case lablqt.

I like idea of using QtQuick, but would also like that C++ code is
absent or hidden for the user trying to use Qt5 with OCaml.


Sincerely,
Gour

-- 
Whenever and wherever there is a decline in religious practice, 
O descendant of Bharata, and a predominant rise of irreligion — 
at that time I descend Myself.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 07:07:53 +0200
rixed@happyleptic.org wrote:

> Is there something like gtk-server for qt?

Q: I want the GTK-server to work with Qt, FLTK, wxWidgets!  

A: That is not possible, because these toolkits were implemented with
C++. With a C++ shared object or DLL it is impossible to lookup a
functionname, because the functionnames have been mangled to a unique
name during compiletime. The reason for this is to make sure that
overloaded functions will have a unique name. There is no way to know in
advance how the name of a function is called. More details on this
matter here.  However, the GTK- and XForms toolkits were implemented
with plain C, so the GTK-server concept works in these cases.

(http://www.gtk-server.org/faq.html)

I'm also curious what would hypothetical qt-server bring to OCaml users?


Sincerely,
Gour

-- 
One who restrains his senses, keeping them under full control, 
and fixes his consciousness upon Me, is known as a man of 
steady intelligence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Francois Berenger]

On 09/11/2013 05:16 PM, Gour wrote:
> On Wed, 11 Sep 2013 10:00:50 +0900
> Francois Berenger <berenger@riken.jp> wrote:
>
>> You could also clearly decouple the "engine" of your software
>> from its GUI.
>
> And what to use for GUI?

You are free to use whatever language you want for the GUI
(and the engine) with such a design.

As you are looking into OCaml, maybe the MLdonkey paper
will be of use to you:
http://hal.inria.fr/docs/00/07/17/89/PDF/RR-4797.pdf

>> As was done in MLDonkey and plan9's sam test editor:
>> http://plan9.bell-labs.com/sys/doc/sam/sam.html
>
> Thank you, I'll take a look.

My 2 cents: a productive researcher in my field is
quite interested in GUIs and portability of his software.
He uses Python.

> Sincerely,
> Gour

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[rixed]

-[ Wed, Sep 11, 2013 at 10:26:16AM +0200, Gour ]----
> On Wed, 11 Sep 2013 07:07:53 +0200
> I'm also curious what would hypothetical qt-server bring to OCaml users?

I used Qt a long time ago, and all I remember is the complex build system
with custom preprocessors pilled on top of C++. No wonder there is not
many bindings to Qt.

Something like Qt-server, ie. a C++ program linked with Qt, controlled by
stdin and obeying widget-related commands, would brings Qt bindings to many
other languages. I was unaware that what made gtk-server easy to write
was how easy it is to dynamically lookup function names.

Re: [Caml-list] OCaml vs Ada and/or GUI options

[David MENTRE]

Hello Adrien,

2013/9/11 Adrien Nader <adrien@notk.org>:
> I'm trying to get a list of things that people find bad in (labl)gtk.
> Would you be able to put clear words on what you dislike?

From past experiment, GUI of demexp OCaml application
(http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.8.2.pdf
, look at part IV p. 90), about 5-8 years ago:

  1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
the lablgtk binding changes things compared to the C API, so this not
a one-to-one mapping neither. And the "obvious" changes weren't so
obvious to me. A tutorial made by a Korean guy IIRC helped a lot;

  2. Verbosity of GTK: it takes a lot of code to put 2 buttons
together (probably not GTK specific). At one point I used the GTK
graphical tool (can't remember its name) to design the GUI graphically
and load it into OCaml as XML file. It improved a lot my productivity;

  3. As other said, GTK is dead end: bad support of non-Linux
platforms, not a lot of developers, etc.  It was very difficult to get
my labgtk application working on Windows. A windows developer helped
me a lot: picking the good versions of libraries, solve Windows
specific issues, etc. I couldn't have compiled my OCaml GTK GUI on
Windows without him.

  4. The use of callbacks everywhere looks to me like writing
spaghetti code. I still hope somebody will write an
API/Framework/whatever were one writes declaratively how the GUI
should react and interact with application code, and all the needed
code is generated automatically. Adobe had such a tool at one point
for its internal use (i.e. for its applications). I don't know if
reactive approaches would help in that regard.


To answer original Gour question: I don't think anything in the OCaml
world fits the bill (safe, available at long term, documented, big
user community, ...). Should I do the same thing, I would write the
GUI as an external process (probably in C++ Qt) and use a
communication protocol to control it from my OCaml program. Or maybe
use the binding with Tk, if the graphical aspect has improved.

I still hope that somebody will propose a sane environment to write
GUI apps. :-)

Best regards,
david

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Kakadu]

Hi!

I think that QtQuick team have solved problems with decalrativity and
business-logic. For example, you can declare _states_ which your
application can have and declaratively specify how properties of your
elements change after switching to every state.

You can also declare some action for your menu items and toolbar
buttons declaratively. You can declaratively join actions in exclusive
groups to be sure that only one is enabled on every moment.

And, of course, you can do some simple things like element borders and
gradient filling declaratively.

Kind regards,
Kakadu

On Wed, Sep 11, 2013 at 1:49 PM, David MENTRE <dmentre@linux-france.org> wrote:
> Hello Adrien,
>
> 2013/9/11 Adrien Nader <adrien@notk.org>:
>> I'm trying to get a list of things that people find bad in (labl)gtk.
>> Would you be able to put clear words on what you dislike?
>
> From past experiment, GUI of demexp OCaml application
> (http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.8.2.pdf
> , look at part IV p. 90), about 5-8 years ago:
>
>   1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
> the lablgtk binding changes things compared to the C API, so this not
> a one-to-one mapping neither. And the "obvious" changes weren't so
> obvious to me. A tutorial made by a Korean guy IIRC helped a lot;
>
>   2. Verbosity of GTK: it takes a lot of code to put 2 buttons
> together (probably not GTK specific). At one point I used the GTK
> graphical tool (can't remember its name) to design the GUI graphically
> and load it into OCaml as XML file. It improved a lot my productivity;
>
>   3. As other said, GTK is dead end: bad support of non-Linux
> platforms, not a lot of developers, etc.  It was very difficult to get
> my labgtk application working on Windows. A windows developer helped
> me a lot: picking the good versions of libraries, solve Windows
> specific issues, etc. I couldn't have compiled my OCaml GTK GUI on
> Windows without him.
>
>   4. The use of callbacks everywhere looks to me like writing
> spaghetti code. I still hope somebody will write an
> API/Framework/whatever were one writes declaratively how the GUI
> should react and interact with application code, and all the needed
> code is generated automatically. Adobe had such a tool at one point
> for its internal use (i.e. for its applications). I don't know if
> reactive approaches would help in that regard.
>
>
> To answer original Gour question: I don't think anything in the OCaml
> world fits the bill (safe, available at long term, documented, big
> user community, ...). Should I do the same thing, I would write the
> GUI as an external process (probably in C++ Qt) and use a
> communication protocol to control it from my OCaml program. Or maybe
> use the binding with Tk, if the graphical aspect has improved.
>
> I still hope that somebody will propose a sane environment to write
> GUI apps. :-)
>
> Best regards,
> david
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Am Mittwoch, den 11.09.2013, 10:20 +0200 schrieb Gour:
> On Wed, 11 Sep 2013 08:38:54 +0100
> Gabriel Kerneis <gabriel@kerneis.info> wrote:
> 
> > Note that "desktop app" and "run within browser" are not necessarily
> > exclusive: 
> 
> That's true, but that involves JS-stuff which I'm not so fond of. :-)
> 
> It's certainly good multi-platform solution, but I'm afraid that JS
> spoils the party.

We would need an HTML5 binding so the programmer wouldn't see the
Javascript part.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

Lack of Intellisense to explore the API is the main problem for me. After that, availability of samples to learn from.

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Adrien Nader
Sent: 11 September 2013 06:25
To: Paolo Donadeo
Cc: OCaml mailing list
Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options

Hi,

On Tue, Sep 10, 2013, Paolo Donadeo wrote:
> GTK: my personal opinion is that it's an awful toolkit, from each and 
> every point of view. Bad software design, horrible widgets, etc... The 
> OCaml binding is probably (from the programmer point of view) *better* 
> than the original C API, but it's still a pain.

I'm trying to get a list of things that people find bad in (labl)gtk.
Would you be able to put clear words on what you dislike?

I'm looking for input from anyone and you can mail me directly if you don't want to flood the list (or send a message on IRC).

Thanks,
Adrien Nader

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Leo White]

rixed@happyleptic.org writes:

> -[ Wed, Sep 11, 2013 at 10:26:16AM +0200, Gour ]----
>> On Wed, 11 Sep 2013 07:07:53 +0200
>> I'm also curious what would hypothetical qt-server bring to OCaml users?
>
> I used Qt a long time ago, and all I remember is the complex build system
> with custom preprocessors pilled on top of C++. No wonder there is not
> many bindings to Qt.
>
> Something like Qt-server, ie. a C++ program linked with Qt, controlled by
> stdin and obeying widget-related commands, would brings Qt bindings to many
> other languages. I was unaware that what made gtk-server easy to write
> was how easy it is to dynamically lookup function names.

Perhaps Smoke (http://techbase.kde.org/Development/Languages/Smoke) is
similar.

Regards,

Leo

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 13:54:51 +0100
Leo White <lpw25@cam.ac.uk> wrote:

> Perhaps Smoke (http://techbase.kde.org/Development/Languages/Smoke) is
> similar.

When I was considering F# and Kyoto (Qt bindings), the main developer
was complaining a lot about SMOKE (see
http://article.gmane.org/gmane.comp.kde.devel.bindings/7852 thread) and
was considering to use SWIG for next generation of Qt bindings for F#.


Sincerely,
Gour

-- 
One who sees inaction in action, and action in inaction, 
is intelligent among men, and he is in the transcendental position, 
although engaged in all sorts of activities.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Paolo Donadeo]

On Wed, Sep 11, 2013 at 7:24 AM, Adrien Nader <adrien@notk.org> wrote:
> I'm trying to get a list of things that people find bad in (labl)gtk.
> Would you be able to put clear words on what you dislike?

Very simple. Each and every time I open the GTK API reference [1] I
feel like being catapulted in a distopian world, where nothing is
clear. Compare with the documentation of QT.

Second, I notice that there isn't a single GTK program with a decent
GUI, from the look and feel point of view. I use GTK programs everyday
(as a Linux user) but this doesn't mean I don't consider it
essentially... ugly. Compare with the average GUIs of an average OSX
application, but even Windows is probably better and more refined.

It's *NOT* a problem with LablGTK, but with GTK itself.

And of course this is a personal opinion, with no intention to be the "truth".


[1] for example: http://www.gtk.org/api/2.6/gtk/gtk-General.html

-- 
Paolo

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Kakadu]

> this doesn't mean I don't consider it essentially... ugly

When we have discussed it in IRC, Adrien usually says "GTK doesn't
look like ugly, your theme do" :)

Kind regards,
Kakadu



On Wed, Sep 11, 2013 at 5:22 PM, Paolo Donadeo <p.donadeo@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 7:24 AM, Adrien Nader <adrien@notk.org> wrote:
>> I'm trying to get a list of things that people find bad in (labl)gtk.
>> Would you be able to put clear words on what you dislike?
>
> Very simple. Each and every time I open the GTK API reference [1] I
> feel like being catapulted in a distopian world, where nothing is
> clear. Compare with the documentation of QT.
>
> Second, I notice that there isn't a single GTK program with a decent
> GUI, from the look and feel point of view. I use GTK programs everyday
> (as a Linux user) but this doesn't mean I don't consider it
> essentially... ugly. Compare with the average GUIs of an average OSX
> application, but even Windows is probably better and more refined.
>
> It's *NOT* a problem with LablGTK, but with GTK itself.
>
> And of course this is a personal opinion, with no intention to be the "truth".
>
>
> [1] for example: http://www.gtk.org/api/2.6/gtk/gtk-General.html
>
> --
> Paolo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Paolo Donadeo]

On Wed, Sep 11, 2013 at 3:33 PM, Kakadu <kakadu.hafanana@gmail.com> wrote:
> When we have discussed it in IRC, Adrien usually says "GTK doesn't
> look like ugly, your theme do" :)

Yes, maybe this is the real reason but... my theme is the Ubuntu
default theme, and I use Ubuntu... I'm a bit ashamed to say this... I
use Ubuntu mainly because the default look and feel of Debian would be
great if we were in the '80s... but in 2013...

So, maybe it's a matter of bad themes, but if nobody can design a
decent theme, there should be a good reason :)


-- 
Paolo

Re: [Caml-list] OCaml vs Ada and/or GUI options

[David MENTRE]

Hello,

2013/9/11 Kakadu <kakadu.hafanana@gmail.com>:
> I think that QtQuick team have solved problems with decalrativity and
> business-logic.

Thanks for the pointer, I definitely need to look at it.

Best regards,
david

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Gour wrote:
> On Wed, 11 Sep 2013 07:24:37 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > I'm trying to get a list of things that people find bad in (labl)gtk.
> > Would you be able to put clear words on what you dislike?
> 
> I can't say much about lablgtk, but as far as gtk is concerned, I
> believe there is no future for it multi-platform wise.
> 
> Have you read/seen:
> 
> http://lwn.net/Articles/562856/ 
> http://www.superlectures.com/guadec2013/gtk-to-infinity-and-beyond 

I hadn't, thanks for the link. I skipped the video and went a bit
quickly through the lwn article (hopefully, lwn articles are
well-written and you only need to read a few words of a paragraph to
kwow whether you want to skip it or not).


I'm going to quote or paraphrase 3 paragraphs of the lwn.net article and
comment them. I think it's the ones that matter the most for the current
topic.

> People often ask why they should port an application from GTK2 to GTK3,
> Otte said. His answer historically was that GTK3 is awesome and everyone
> should port, but he said he has begun to doubt that. The truth is that
> GTK2 is stable and unchanging, even boring—but that is what some
> projects need. [...]. The real reason someone should port to GTK3
> today, he concluded, is to take advantage of the new features that
> integrate the application with GNOME 3—but doing so means committing to
> keeping up with GNOME 3's pace of change, which is intentionally bold in
> introducing new features.

I've been meaning to work on GTK+3 support lablgtk for a while but each
time I look at it, it's a lot of work. A lot has changed many things are
better, even if only under the hood. However that means work to get
lablgtk3 and the more the changes are under-the-hood, the less their
counterpart in lablgtk can be automatically generated (binding a new
widget function or a new signal in lablgtk is trivial).

> Eventually, he said, he hopes that GTK+ will reach a point where the
> bold experiments are done. This will be after the scene graph and
> gesture support, but it is hard to say when it will be. Afterward,
> however, Otte hopes to make a GTK4 major release, removing all of the
> deprecated APIs, and settling on a GTK2-like stable and unchanging
> platform. The project is not there yet, he said, and notably it will
> keep trying to be bold and add new things until application developers
> "throw enough rocks" to convince them to stop. The rapidly-changing
> nature of GTK3 is a headache for many developers, he said, but it has to
> be balanced with those same developers' requests for new features like
> gesture recognition and Clutter integration.

I don't think many people will disagree with the above. Benjamin Otte is
one of the leading devs of the GTK+ ecosystem and I usually agree with
him: his opinions are well-thought and his decisions are balanced.

It's fairly reassuring that they plan to make something stable after
that. I hope for everyone that this holds. By the time they reach the
end of GTK3, they should notice that it's necessary; again, I hope.

> Otte's statements that GTK+ was a "GNOME first" project were frequently
> a topic for debate at the rest of GUADEC. One audience member even asked
> him during his talk whether this stance left out other major GTK+-based
> projects like LXDE and Xfce. Otte replied that he was not trying to keep
> those projects out; rather, since GNOME developers do the majority of
> the GTK+ coding, their decisions push GTK+ in their direction. If other
> projects want to influence GTK+, he said, they need to "participate in
> GTK+ somehow," at the very least by engaging with the development team
> to communicate what the projects want. 

I've had troubles engaging with the GTK+ community. Maybe I should have
tried the mailing-lists instead of only IRC but they are active on IRC
and I'd expect to get at least some reaction but I had lots of troubles
getting any. If I'm trying to work for free, don't make me work more in
order to do the work.

I left with the strong impression that they all know each other and that
if you're not already part of the circle, you're going to have troubles
communicating with them.

(note that the same can apply to Qt even though it seems to be a bit
better)

On Wed, Sep 11, 2013, Gour wrote:
> Otoh, Qt project is strongly positioned with many devs, actively
> developed, no problem with the license etc. and my humble suggestion is
> to put lablgtk into maint. mode and focus, as community, on providing
> lablqt to attract new users to write GUI apps in such a fine language as
> OCaml.

Well, no.
I'm going to mostly repeat what I wrote on IRC (I was at work; I leave
my laptop along with my SSH keys and passwords at home).

I think you can easily understand that not many people would drop a
project they're working on (even infrequently) and switch to some kind
of "competitor".

But apart from that, I dislike Qt.

- I don't want to use moc or anything similar
- I dislike their deep class hierarchy
- their deep class hierarchy is a difficulty for bindings (how do you
  make it possible to implement from OCaml the virtual protected method
  in super^5? see the timers for example)
- I dislike their API
- I dislike the "automatic" widget placement and (re)sizing; GTK+'s
  hbox/vbox are much easier to use, with a result that I prefer
- I dislike qmake
- I feel like I'm using a framework when I use Qt

I'll skip the part where I'm tempted to mention being gagged with a
smurfette while using several of the things mentionned above (I'm sure
you can look it up if you want).

I'm much more interested in bindings to the EFLs[1]. It's C and the
direct result is that you already have bindings even though fairly
little time has been spent on them. It's much smaller, it's fast, the
API is fairly small and, at least for the EFLs 1.7, the typing used on
the C side is so inexistant that I'm sure it will be easy to provide an
awesome high-level layer bindings on top of it.
Oh and the community is welcoming, with many French people, i.e. that
you can actually threaten with a baseball bat. :) 

[1] https://forge.ocamlcore.org/projects/ocaml-efl/
(there's also GraphicsPP, an implementation of the Graphics module but
with the Evas library instead)

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, David MENTRE wrote:
> Hello Adrien,
> 
> 2013/9/11 Adrien Nader <adrien@notk.org>:
> > I'm trying to get a list of things that people find bad in (labl)gtk.
> > Would you be able to put clear words on what you dislike?
> 
> From past experiment, GUI of demexp OCaml application
> (http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.8.2.pdf
> , look at part IV p. 90), about 5-8 years ago:

Some of your code from MiscUI overlaps with GUtil afaict. However, GUtil
(along with some others) is not advertised as well as it should. I've
started working on that by switching the lablgtk README to asciidoc
which can be used to create browsable documents (with a TOC; webpages
for instance) while still being readable with "cat" but it's not
completed.

>   1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
> the lablgtk binding changes things compared to the C API, so this not
> a one-to-one mapping neither. And the "obvious" changes weren't so
> obvious to me. A tutorial made by a Korean guy IIRC helped a lot;

I'd like to make another tutorial; a much shorter one that matches
lablgtk's high-level API (and therefore conciness). Something like a
10-minutes tutorial; I'll try to get a list of topics for it.

>   2. Verbosity of GTK: it takes a lot of code to put 2 buttons
> together (probably not GTK specific). At one point I used the GTK
> graphical tool (can't remember its name) to design the GUI graphically
> and load it into OCaml as XML file. It improved a lot my productivity;

To put two buttons next to each other, something like this should be
enough (fully untested):
  let hbox = GPack.vbox () in
  let btn1 = GButton.button ~packing:(hbox#pack ~text:"OK" () in
  let btn2 = GButton.button ~packing:(hbox#pack ~text:"NEIN!" () in
  ...

Is it much more concise than what you had done?

>   3. As other said, GTK is dead end: bad support of non-Linux
> platforms, not a lot of developers, etc.  It was very difficult to get
> my labgtk application working on Windows. A windows developer helped
> me a lot: picking the good versions of libraries, solve Windows
> specific issues, etc. I couldn't have compiled my OCaml GTK GUI on
> Windows without him.

I don't need to add anything except maybe mention my yypkg project with
packages for Windows:
  http://yypkg.org/mingw-builds/

>   4. The use of callbacks everywhere looks to me like writing
> spaghetti code. I still hope somebody will write an
> API/Framework/whatever were one writes declaratively how the GUI
> should react and interact with application code, and all the needed
> code is generated automatically. Adobe had such a tool at one point
> for its internal use (i.e. for its applications). I don't know if
> reactive approaches would help in that regard.

I'm afraid you'll find the same issues everywhere. One way or another
it'll boil down to the same thing.

I found that FRP can actually help. It can allow you to write your
application logic in a functional style even though the GUI toolkit is
imperative (and it should be since it deals with I/Os).

I'm preparing a quick presentation for the next OUPS and I'll show some
of this. I'm not ready yet though and I still need to finish writing,
have it proof-read and, oh, ask for a slot (that might help).

> To answer original Gour question: I don't think anything in the OCaml
> world fits the bill (safe, available at long term, documented, big
> user community, ...). Should I do the same thing, I would write the
> GUI as an external process (probably in C++ Qt) and use a
> communication protocol to control it from my OCaml program. Or maybe
> use the binding with Tk, if the graphical aspect has improved.

There are screenshots on the tk website. The aspect has improved through
new themes (including ones for Windows and MacOS X, something that GTK+
really needs to do; yes, only a theme...)

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Kakadu wrote:
> Hi!
> 
> I think that QtQuick team have solved problems with decalrativity and
> business-logic. For example, you can declare _states_ which your
> application can have and declaratively specify how properties of your
> elements change after switching to every state.
>
> You can also declare some action for your menu items and toolbar
> buttons declaratively. You can declaratively join actions in exclusive
> groups to be sure that only one is enabled on every moment.
> 
> And, of course, you can do some simple things like element borders and
> gradient filling declaratively.
> 

They copied that from the EFLs. :) 

Anyway, there's something important to keep in mind. If you have states
and build an application with some bells and whistles, you'll have
transitions between the states and you'll need to synchronize them and
synchronize the logic too.
This can create many many switches between themes and logic code,
spaning several files.

That's one new issues.
I believe it can be improved a lot (if not solved completely) by
providing type-safety (i.e. state identifiers are variants, not strings)
and putting all the transition and synchronization logic in a single
place.
That's something for which OCaml would be a good language.

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Jon Harrop wrote:
> 
> Lack of Intellisense to explore the API is the main problem for me. After that, availability of samples to learn from.

Have you had a look at Merlin[1]?

I don't expect it to have the same level of refinement as Intellisense
but it should provide a strong improvement.
It's definitely recent though.

[1] https://github.com/def-lkb/merlin

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Paolo Donadeo wrote:
> On Wed, Sep 11, 2013 at 7:24 AM, Adrien Nader <adrien@notk.org> wrote:
> > I'm trying to get a list of things that people find bad in (labl)gtk.
> > Would you be able to put clear words on what you dislike?
> 
> Very simple. Each and every time I open the GTK API reference [1] I
> feel like being catapulted in a distopian world, where nothing is
> clear. Compare with the documentation of QT.

It's a bit strange. Each and every time I've been feeling the same but
with Qt and GTK swapped. Only proves that people are different though.
(and makes me wonder what is the fundamental difference)

> Second, I notice that there isn't a single GTK program with a decent
> GUI, from the look and feel point of view. I use GTK programs everyday
> (as a Linux user) but this doesn't mean I don't consider it
> essentially... ugly. Compare with the average GUIs of an average OSX
> application, but even Windows is probably better and more refined.
> 
> It's *NOT* a problem with LablGTK, but with GTK itself.

As Kakadu mentionned, I believe it's mostly a matter of themes.
Unfortunately they tend to not evolve much.

That said, visually appealing themes are much easier to write with a DSL
and that's pretty much Edje (EFL) and QtQuick. It's both simpler and
more powerful.
Hopefully, these are getting more widespread (yay, people discover DSLs
again!).

> [1] for example: http://www.gtk.org/api/2.6/gtk/gtk-General.html
(I found that it mostly matched what I'd like for a fairly low-level
documentation =/ )

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Rudi Grinberg]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Also, it doesn't help that the GTK devs don't mind breaking themes every
release.

http://www.linuxuser.co.uk/news/a-linux-conspiracy-theory

(Apologies in advance for the slightly inflammatory nature of that article)


On Wed, Sep 11, 2013 at 2:57 PM, Adrien Nader <adrien@notk.org> wrote:

> On Wed, Sep 11, 2013, Paolo Donadeo wrote:
> > On Wed, Sep 11, 2013 at 7:24 AM, Adrien Nader <adrien@notk.org> wrote:
> > > I'm trying to get a list of things that people find bad in (labl)gtk.
> > > Would you be able to put clear words on what you dislike?
> >
> > Very simple. Each and every time I open the GTK API reference [1] I
> > feel like being catapulted in a distopian world, where nothing is
> > clear. Compare with the documentation of QT.
>
> It's a bit strange. Each and every time I've been feeling the same but
> with Qt and GTK swapped. Only proves that people are different though.
> (and makes me wonder what is the fundamental difference)
>
> > Second, I notice that there isn't a single GTK program with a decent
> > GUI, from the look and feel point of view. I use GTK programs everyday
> > (as a Linux user) but this doesn't mean I don't consider it
> > essentially... ugly. Compare with the average GUIs of an average OSX
> > application, but even Windows is probably better and more refined.
> >
> > It's *NOT* a problem with LablGTK, but with GTK itself.
>
> As Kakadu mentionned, I believe it's mostly a matter of themes.
> Unfortunately they tend to not evolve much.
>
> That said, visually appealing themes are much easier to write with a DSL
> and that's pretty much Edje (EFL) and QtQuick. It's both simpler and
> more powerful.
> Hopefully, these are getting more widespread (yay, people discover DSLs
> again!).
>
> > [1] for example: http://www.gtk.org/api/2.6/gtk/gtk-General.html
> (I found that it mostly matched what I'd like for a fairly low-level
> documentation =/ )
>
> --
> Adrien Nader
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3326 bytes --]

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Gour wrote:
> On Wed, 11 Sep 2013 13:54:51 +0100
> Leo White <lpw25@cam.ac.uk> wrote:
> 
> > Perhaps Smoke (http://techbase.kde.org/Development/Languages/Smoke) is
> > similar.
> 
> When I was considering F# and Kyoto (Qt bindings), the main developer
> was complaining a lot about SMOKE (see
> http://article.gmane.org/gmane.comp.kde.devel.bindings/7852 thread) and
> was considering to use SWIG for next generation of Qt bindings for F#.

I hope he didn't go that way.
The original SWIG developper ended up stating that he had made something
to mix python and C++ and that it had turned really awful. I can't find
the message again unfortunately (not enough keywords).

Summary: if you ever wonder why the swig-generated files take so long to
compile, stop at once, go get yourself a coffee or go do something,
anything, else.

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Rudi Grinberg wrote:
> Also, it doesn't help that the GTK devs don't mind breaking themes every
> release.
> 
> http://www.linuxuser.co.uk/news/a-linux-conspiracy-theory
> 
> (Apologies in advance for the slightly inflammatory nature of that article)

Well, this matches pretty well what I said about the community being
fairly closed; it's difficult to be listened to when you're from quite
deeply involved with it.

-- 
Adrien Nader

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 11:49:25 +0200
David MENTRE <dmentre@linux-france.org> wrote:

> Should I do the same thing, I would write the GUI as an external
> process (probably in C++ Qt) and use a communication protocol to
> control it from my OCaml program. Or maybe use the binding with Tk, if
> the graphical aspect has improved.

I got similar advices in Ada community and considered that writing
back-end in Ada and GUI front-end in PyQt as last resort. :-)


Sincerely,
Gour

-- 
For him who has conquered the mind, the mind is the best of 
friends; but for one who has failed to do so, his mind will 
remain the greatest enemy.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 18:00:07 +0900
Francois Berenger <berenger@riken.jp> wrote:

> You are free to use whatever language you want for the GUI
> (and the engine) with such a design.

Yep.

> As you are looking into OCaml, maybe the MLdonkey paper
> will be of use to you:

Interesting one.

> My 2 cents: a productive researcher in my field is
> quite interested in GUIs and portability of his software.
> He uses Python.

Yeah, if everything fails, Python is always there ready to serve. ;)


Sincerely,
Gour

-- 
When your intelligence has passed out of the dense forest 
of delusion, you shall become indifferent to all that has 
been heard and all that is to be heard.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

On Wed, 11 Sep 2013 20:17:37 +0200
Adrien Nader <adrien@notk.org> wrote:

> I hadn't, thanks for the link. I skipped the video and went a bit
> quickly through the lwn article (hopefully, lwn articles are
> well-written and you only need to read a few words of a paragraph to
> kwow whether you want to skip it or not).

Let's see...

> It's fairly reassuring that they plan to make something stable after
> that. I hope for everyone that this holds. By the time they reach the
> end of GTK3, they should notice that it's necessary; again, I hope.

Maybe they will achieve something stable after GTK3, but nobody knows
when it will happen and it seems that GNOME will remain the only
customer at that time.

> I've had troubles engaging with the GTK+ community. Maybe I should
> have tried the mailing-lists instead of only IRC but they are active
> on IRC and I'd expect to get at least some reaction but I had lots of
> troubles getting any. If I'm trying to work for free, don't make me
> work more in order to do the work.

Have you seen this one: "Finally, he said, people ask whether GTK+ is
focused on creating "small apps" or "large applications," and his answer
is "small apps." In other words, GTK+ widgets are designed to make it
easy and fast to write small apps for GNOME: apps like Clocks, rather
than GIMP or Inkscape."

Frankly speaking I'm not interested to use GUI toolkit which is designed
for writing "apps like Clocks". No wonder that more & more projects
(even DEs like LXDE) are moving towards Qt.

Sure, Qt is not perfect, but the state of GTK is sad.

> Well, no.
> I'm going to mostly repeat what I wrote on IRC (I was at work; I leave
> my laptop along with my SSH keys and passwords at home).
> 
> I think you can easily understand that not many people would drop a
> project they're working on (even infrequently) and switch to some kind
> of "competitor".

Here I am trying to just be practical...for only short period of time I
was running KDE desktop (~0.9.x) and the rest of the time GTK-ones (now
I use only i3). Moreover, my preferred apps were also GTK-based, but
when I see direction where it goes, it is wise to be prepare for the
future. (/me was die-hard OS2 user, but jumped onto Linux train inn
'99)

> But apart from that, I dislike Qt.

OK -- fair-enough.

> I'm much more interested in bindings to the EFLs[1]. It's C and the
> direct result is that you already have bindings even though fairly
> little time has been spent on them. It's much smaller, it's fast, the
> API is fairly small and, at least for the EFLs 1.7, the typing used on
> the C side is so inexistant that I'm sure it will be easy to provide
> an awesome high-level layer bindings on top of it.

I wish you all success. EFL is surely better option than GTK.

> Oh and the community is welcoming, with many French people, i.e. that
> you can actually threaten with a baseball bat. :) 

:-)

What about Tk which seems to not look bad in 8.6.x ?


Sincerely,
Gour

-- 
In the material world, one who is unaffected by whatever good 
or evil he may obtain, neither praising it nor despising it, 
is firmly fixed in perfect knowledge.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 20:36:29 +0200
Adrien Nader <adrien@notk.org> wrote:

> There are screenshots on the tk website. The aspect has improved
> through new themes (including ones for Windows and MacOS X, something
> that GTK+ really needs to do; yes, only a theme...)

What about OCaml's bindings? Up-to-date with tk-8.6?


Sincerely,
Gour

-- 
A person is considered still further advanced when he regards honest 
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

FWIW, I recently installed a dual boot to Ubuntu and found it very clunky compared to Windows. The GUI libraries available for Linux are just awful. When I used OCaml and Linux I used to write GUIs using OpenGL but that's just the best of a bad job...

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Paolo Donadeo
Sent: 11 September 2013 15:10
To: OCaml mailing list
Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options

On Wed, Sep 11, 2013 at 3:33 PM, Kakadu <kakadu.hafanana@gmail.com> wrote:
> When we have discussed it in IRC, Adrien usually says "GTK doesn't 
> look like ugly, your theme do" :)

Yes, maybe this is the real reason but... my theme is the Ubuntu default theme, and I use Ubuntu... I'm a bit ashamed to say this... I use Ubuntu mainly because the default look and feel of Debian would be great if we were in the '80s... but in 2013...

So, maybe it's a matter of bad themes, but if nobody can design a decent theme, there should be a good reason :)


--
Paolo

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 20:36:50 +0100
"Jon Harrop" <jon@ffconsultancy.com> wrote:

> FWIW, I recently installed a dual boot to Ubuntu and found it very
> clunky compared to Windows. The GUI libraries available for Linux are
> just awful. 

But what is available for writing GUI app using F# on Mac OS?

Isn't it GTK# only?


Sincerely,
Gour

-- 
Whatever action a great man performs, common men follow. And 
whatever standards he sets by exemplary acts, all the world pursues.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Gour wrote:
> On Wed, 11 Sep 2013 20:36:29 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > There are screenshots on the tk website. The aspect has improved
> > through new themes (including ones for Windows and MacOS X, something
> > that GTK+ really needs to do; yes, only a theme...)
> 
> What about OCaml's bindings? Up-to-date with tk-8.6?

I don't use them but they build.

Note that they've been moved out of trunk on yesterday; I'm not sure
where they are now.

Btw, I'm fairly happy with such a change because it should help it
evolve (with releases not bound to the compiler releases for one).

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Gour wrote:
> On Wed, 11 Sep 2013 20:17:37 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > I hadn't, thanks for the link. I skipped the video and went a bit
> > quickly through the lwn article (hopefully, lwn articles are
> > well-written and you only need to read a few words of a paragraph to
> > kwow whether you want to skip it or not).
> 
> Let's see...
> 
> > It's fairly reassuring that they plan to make something stable after
> > that. I hope for everyone that this holds. By the time they reach the
> > end of GTK3, they should notice that it's necessary; again, I hope.
> 
> Maybe they will achieve something stable after GTK3, but nobody knows
> when it will happen and it seems that GNOME will remain the only
> customer at that time.
> 

While I hope this happens, I'm not holding my breath.

> > I've had troubles engaging with the GTK+ community. Maybe I should
> > have tried the mailing-lists instead of only IRC but they are active
> > on IRC and I'd expect to get at least some reaction but I had lots of
> > troubles getting any. If I'm trying to work for free, don't make me
> > work more in order to do the work.
> 
> Have you seen this one: "Finally, he said, people ask whether GTK+ is
> focused on creating "small apps" or "large applications," and his answer
> is "small apps." In other words, GTK+ widgets are designed to make it
> easy and fast to write small apps for GNOME: apps like Clocks, rather
> than GIMP or Inkscape."
> 
> Frankly speaking I'm not interested to use GUI toolkit which is designed
> for writing "apps like Clocks". No wonder that more & more projects
> (even DEs like LXDE) are moving towards Qt.

That's something I disagree with, or at least don't understand.

All I ask from a GUI library is a set of widget. If that is properly
provided, I don't see which influence the library has on the scale of
the application you can do.

> Sure, Qt is not perfect, but the state of GTK is sad.

Pretty much agreed.

> > Oh and the community is welcoming, with many French people, i.e. that
> > you can actually threaten with a baseball bat. :) 
> 
> :-)
> 
> What about Tk which seems to not look bad in 8.6.x ?

It's one tooolkit I haven't tried. Part of the reason was the lack of a
working WebKit binding (to tk, not to ocaml) last time I started a
project.

That said, gitk does a few weird things from time to time but I'm not
sure if it's by design or if it's because of tk.

-- 
Adrien Nader

RE: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Jon Harrop]

Adrien Nader:
> I've been meaning to work on GTK+3 support lablgtk for a while but each time I look at it, it's a lot of work.

My advice would be to forget about using OCaml's FFI to interop with Linux' GUI libraries and focus instead on writing a new GUI library from scratch in OCaml using OpenGL.

Objectively, OCaml is extremely good for GUI programming. You've already got libraries to load TrueType fonts and tessellate/rasterize them. OpenGL makes it easy to render anything with excellent performance. LablGL even makes picking (i.e. mouse clicks) easy. The result would be cross platform.

Cheers,
Jon.

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 21:53:20 +0200
Adrien Nader <adrien@notk.org> wrote:

> While I hope this happens, I'm not holding my breath.

Go to http://www.gtk.org/download/index.php and visit link for Linux, Windows
and Mac OS X...you'll see that the last stable releases are:

a) 3.8 for Linux

b) 2.24.10 for Win32 and 2.22.1 for Win64 with the note: "Note that
these 64-bit packages are experimental."

c) no packages for Mac OS X

which is clear indication that GTK is no longer multi-platform toolkit
and is becoming GNOME-only.

> That's something I disagree with, or at least don't understand.
> 
> All I ask from a GUI library is a set of widget. If that is properly
> provided, I don't see which influence the library has on the scale of
> the application you can do.

Check the video link - the guy is explaining that GTK is no longer
suitable for apps which need many custom widgets, but is appropriate for
'small apps' using "default widgets" only.


Sincerely,
Gour

-- 
He who is satisfied with gain which comes of its own accord, who 
is free from duality and does not envy, who is steady in both 
success and failure, is never entangled, although performing actions.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Wed, Sep 11, 2013 at 2:06 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

>
> My advice would be to forget about using OCaml's FFI to interop with
> Linux' GUI libraries and focus instead on writing a new GUI library from
> scratch in OCaml using OpenGL.
>

I agree. Game-devs do this all the time -- making their own GUIs -- and
they're often slicker and faster. It's not as hard making something
app-specific. The difficulty is making a library that supports every
edge-case that every developer needs (and still falling short).

An argument against this would be uniformity or playing nice with standards
(not sure how many standards straddle the OS/Desktop spectrum though). I'm
not a fan of uniformity -- it tends to constrain applications.
Communication-standards are good, where we have them. But I mean
look-and-feel... user-interaction should be as suited to the application.
But this might be a minority opinion. I'm not a fan of stunted Apple-esque
UIs, and hate Gnome's march to ever more compliance and uniformity to their
own guidelines. I typically use four major applications -- what advantage
does uniformity bring?

[-- Attachment #2: Type: text/html, Size: 1581 bytes --]

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Gour wrote:
> On Wed, 11 Sep 2013 21:53:20 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > While I hope this happens, I'm not holding my breath.
> 
> Go to http://www.gtk.org/download/index.php and visit link for Linux, Windows
> and Mac OS X...you'll see that the last stable releases are:
> 
> a) 3.8 for Linux
> 
> b) 2.24.10 for Win32 and 2.22.1 for Win64 with the note: "Note that
> these 64-bit packages are experimental."
> 
> c) no packages for Mac OS X

I quite strongly disagree. That developers have to become packagers for
Windows and Mac OS X has been an unfortunate fact. It doesn't prove
anything about the stability of a software.

I actually hate that. On Windows this leads to "zlib.dll" or
"zlib1.dll". You'll find hundreds of zlib libraries with these names.
Which version, which options, which compatibility?
Binaries should be built as a whole. They need to be compatible between
them and they need to be consistent. Having software developers provide
binaries guarantees that this doesn't happen.

> > That's something I disagree with, or at least don't understand.
> > 
> > All I ask from a GUI library is a set of widget. If that is properly
> > provided, I don't see which influence the library has on the scale of
> > the application you can do.
> 
> Check the video link - the guy is explaining that GTK is no longer
> suitable for apps which need many custom widgets, but is appropriate for
> 'small apps' using "default widgets" only.

Hmm, that explains it: I don't want to roll my own widgets. I avoid it
like the plague.

-- 
Adrien Nader

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Anthony Tavener wrote:
> On Wed, Sep 11, 2013 at 2:06 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> 
> >
> > My advice would be to forget about using OCaml's FFI to interop with
> > Linux' GUI libraries and focus instead on writing a new GUI library from
> > scratch in OCaml using OpenGL.
> >
> 
> I agree. Game-devs do this all the time -- making their own GUIs -- and
> they're often slicker and faster. It's not as hard making something
> app-specific. The difficulty is making a library that supports every
> edge-case that every developer needs (and still falling short).

I've found the game menus to be the worst thing on Earth.
They are (*) consistently slow to load, cpu-hungry, memory-hungry, and
often crashy. You typically need as much power to display the menu than
you need to run the game itself.

(*) I've stopped playing during the past few years; maybe that has
improved but I doubt it.

PS: a11y (accessibility) is not to be forgotten btw.

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Jacques Garrigue]

Hi David,

I know you just wrote this list as a kind answer, but I cannot resist giving my view :-)

On 2013/09/11, at 18:49, David MENTRE <dmentre@linux-france.org> wrote:
> 2013/9/11 Adrien Nader <adrien@notk.org>:
>> I'm trying to get a list of things that people find bad in (labl)gtk.
>> Would you be able to put clear words on what you dislike?
> 
> From past experiment, GUI of demexp OCaml application
> (http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.8.2.pdf
> , look at part IV p. 90), about 5-8 years ago:
> 
>  1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
> the lablgtk binding changes things compared to the C API, so this not
> a one-to-one mapping neither. And the "obvious" changes weren't so
> obvious to me. A tutorial made by a Korean guy IIRC helped a lot;

I'm certainly the one to blame for that. If Adrien can improve that, big thanks
to him.

Still, the concept for LablGTK was: provide access to the GTK+ API, but reduce
the cruft. So, it is type safe with (almost) no need for coercions, and packing
can be done on the same line. Ideally this should have been close to LablTk,
but GTK is much more complex than Tk.

>  2. Verbosity of GTK: it takes a lot of code to put 2 buttons
> together (probably not GTK specific). At one point I used the GTK
> graphical tool (can't remember its name) to design the GUI graphically
> and load it into OCaml as XML file. It improved a lot my productivity;

Cannot blame you for that. Actually this is the right way to go if you have little time.
Unfortunately, this makes code harder to maintain.

As Adrien pointed, even written by hand LablGTK is much shorter than its C equivalent.
A ratio of 1/3 at least.

>  3. As other said, GTK is dead end: bad support of non-Linux
> platforms, not a lot of developers, etc.  It was very difficult to get
> my labgtk application working on Windows. A windows developer helped
> me a lot: picking the good versions of libraries, solve Windows
> specific issues, etc. I couldn't have compiled my OCaml GTK GUI on
> Windows without him.

I'm a bit surprised, as I never had problems on windows.
More honestly, there is one problem: where to find the packages.
But once you got them, it works just fine.

On the other hand OSX support seems to be never completed. A pity.

>  4. The use of callbacks everywhere looks to me like writing
> spaghetti code. I still hope somebody will write an
> API/Framework/whatever were one writes declaratively how the GUI
> should react and interact with application code, and all the needed
> code is generated automatically. Adobe had such a tool at one point
> for its internal use (i.e. for its applications). I don't know if
> reactive approaches would help in that regard.

I would rather say that this looks like OO code :-)
I have no allergy to that, and OCaml allows you to write in a much
cleaner way than C. However, this is clearly not declarative.
There are lots of experiments about declarative GUI in the Haskell
community, but I have no experience on how it fares in practice.

BTW, lexifi has also some internal system to build GUIs automatically.
I don't know if there is a blog post on that.

> To answer original Gour question: I don't think anything in the OCaml
> world fits the bill (safe, available at long term, documented, big
> user community, ...). Should I do the same thing, I would write the
> GUI as an external process (probably in C++ Qt) and use a
> communication protocol to control it from my OCaml program. Or maybe
> use the binding with Tk, if the graphical aspect has improved.

For Tk, I wouldn't say that the graphics have improved much.
And LablTk may not support the latest features.
Still, of course we can improve it, and comments are welcome.
But don't expect anything professional.

I agree that support for Qt would be ideal, and I actual first worked
on a LablQt before starting LablGTK, but writing bindings is much
harder. With all its defaults, GTK was designed with other languages
in mind, and this makes a huge difference. In theory, with the latest
versions one should be able to generate the bindings completely
automatically (but this is still experimental in LablGTK).

Also, every time I talked about improving LablGTK, I have gotten
comments about GUIs being web-based these days, so that generating
JavaScript would be the way to go. Are there good solutions for that?

Jacques Garrigue

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Jacques Garrigue]

On 2013/09/12, at 4:45, Adrien Nader <adrien@notk.org> wrote:

> On Wed, Sep 11, 2013, Gour wrote:
>> On Wed, 11 Sep 2013 20:36:29 +0200
>> Adrien Nader <adrien@notk.org> wrote:
>> 
>>> There are screenshots on the tk website. The aspect has improved
>>> through new themes (including ones for Windows and MacOS X, something
>>> that GTK+ really needs to do; yes, only a theme...)
>> 
>> What about OCaml's bindings? Up-to-date with tk-8.6?
> 
> I don't use them but they build.
> 
> Note that they've been moved out of trunk on yesterday; I'm not sure
> where they are now.

Here is their new home:

https://forge.ocamlcore.org/projects/labltk/

No home page yet, but it compiles out of the box.

> Btw, I'm fairly happy with such a change because it should help it
> evolve (with releases not bound to the compiler releases for one).


Contributions are welcome.
But personally I'm in maintenance mode :-)

	Jacques

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Richard W.M. Jones]

On Wed, Sep 11, 2013 at 09:06:05PM +0100, Jon Harrop wrote:
> My advice would be to forget about using OCaml's FFI to interop with
> Linux' GUI libraries and focus instead on writing a new GUI library
> from scratch in OCaml using OpenGL.
>
> Objectively, OCaml is extremely good for GUI programming. You've
> already got libraries to load TrueType fonts and tessellate/rasterize
> them. OpenGL makes it easy to render anything with excellent
> performance. LablGL even makes picking (i.e. mouse clicks) easy. The
> result would be cross platform.

Hmm.  Then someone wants to enter text in Chinese, and someone else
needs to use their speech reader, and so on.  Good luck reimplementing
the whole of Gtk.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Francois Berenger]

I didn't see mentioned in this thread:
kommander a KDE tool (maybe moribund).

And, maybe more related to OCaml:
http://www.lexifi.com/csml

On 09/12/2013 12:21 AM, David MENTRE wrote:
> Hello,
>
> 2013/9/11 Kakadu <kakadu.hafanana@gmail.com>:
>> I think that QtQuick team have solved problems with decalrativity and
>> business-logic.
>
> Thanks for the pointer, I definitely need to look at it.
>
> Best regards,
> david
>

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Ivan Gotovchits]

Adrien Nader <adrien@notk.org> writes:

>>   4. The use of callbacks everywhere looks to me like writing
>> spaghetti code. I still hope somebody will write an
>> API/Framework/whatever were one writes declaratively how the GUI
>> should react and interact with application code, and all the needed
>> code is generated automatically. Adobe had such a tool at one point
>> for its internal use (i.e. for its applications). I don't know if
>> reactive approaches would help in that regard.
>
> I'm afraid you'll find the same issues everywhere. One way or another
> it'll boil down to the same thing.

Consider using lwt-glib integration. You can transform any callback to a
function returning lwt. You even go futher and use Lwt_react to
transform glib events to declarative events and signals of (Lwt)React.

-- 
         (__) 
         (oo) 
   /------\/ 
  / |    ||   
 *  /\---/\ 
    ~~   ~~   
...."Have you mooed today?"...

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 21:53:20 +0200
Adrien Nader <adrien@notk.org> wrote:

> It's one tooolkit I haven't tried. Part of the reason was the lack of
> a working WebKit binding (to tk, not to ocaml) last time I started a
> project.
> 
> That said, gitk does a few weird things from time to time but I'm not
> sure if it's by design or if it's because of tk.

While we're here, I forgot to ask you what do you think about wxOCaml?


Sincerely,
Gour

-- 
The senses are so strong and impetuous, O Arjuna, 
that they forcibly carry away the mind even of a man 
of discrimination who is endeavoring to control them.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Wed, 11 Sep 2013 23:01:03 +0200
Adrien Nader <adrien@notk.org> wrote:

> I quite strongly disagree. That developers have to become packagers
> for Windows and Mac OS X has been an unfortunate fact. It doesn't
> prove anything about the stability of a software.

I also strongly disagree...

GTK is mostly installed by default on Linux OS, but not on Windows and
Mac OS X, so if Windows is supposed to be counted as supported platform,
whose duty is to prepare package for?

As far as Mac OS is concerned, port is even not finished, so no need to
discuss support for that platform.

Otoh, you can visit http://qt-project.org/downloads and the page speaks
for itself about the level of supported platforms between GTK & Qt.


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though 
faultily, than another's duties perfectly. Destruction in the course 
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Thu, Sep 12, 2013, Gour wrote:
> On Wed, 11 Sep 2013 23:01:03 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > I quite strongly disagree. That developers have to become packagers
> > for Windows and Mac OS X has been an unfortunate fact. It doesn't
> > prove anything about the stability of a software.
> 
> I also strongly disagree...
> 
> GTK is mostly installed by default on Linux OS, but not on Windows and
> Mac OS X, so if Windows is supposed to be counted as supported platform,
> whose duty is to prepare package for?
> 
> As far as Mac OS is concerned, port is even not finished, so no need to
> discuss support for that platform.
> 
> Otoh, you can visit http://qt-project.org/downloads and the page speaks
> for itself about the level of supported platforms between GTK & Qt.

I consider distributing binaries a failure: the failure to have source
code than can be easily and properly built on or for the corresponding
platform.

For C++ (and OCaml) you have ABI-compatibility issues because of
toolchain changes. Incompatibilities are only waiting to happen.

That said, I fully get your point but talking about prebuilt binaries is
not the right way to measure portability imho. :) 

-- 
Adrien Nader

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Adrien Nader]

On Wed, Sep 11, 2013, Adrien Nader wrote:
> >   1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
> > the lablgtk binding changes things compared to the C API, so this not
> > a one-to-one mapping neither. And the "obvious" changes weren't so
> > obvious to me. A tutorial made by a Korean guy IIRC helped a lot;
> 
> I'd like to make another tutorial; a much shorter one that matches
> lablgtk's high-level API (and therefore conciness). Something like a
> 10-minutes tutorial; I'll try to get a list of topics for it.

Oh, btw, forgot to mention that I've used ocamlbrowser quite a lot.
It has a couple issues but it's actually very nice to browse the API of
lablgtk and other libs.

Nowadays you can run it through:
  ocamlbrowser -I $(ocamlfind query lablgtk2)
(or maybe -I +lablgtk2 but that's not as portable)

I think that it has really helped me. You select GWindow, then window
then whatever you want and you have the API for that, in a small window
that doesn't eat screen space. It doesn't do anything special but I
found it efficient.

Using Merlin too is on my TODO list.

-- 
Adrien Nader

Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

[Adrien Nader]

On Thu, Sep 12, 2013, Gour wrote:
> On Wed, 11 Sep 2013 21:53:20 +0200
> Adrien Nader <adrien@notk.org> wrote:
> 
> > It's one tooolkit I haven't tried. Part of the reason was the lack of
> > a working WebKit binding (to tk, not to ocaml) last time I started a
> > project.
> > 
> > That said, gitk does a few weird things from time to time but I'm not
> > sure if it's by design or if it's because of tk.
> 
> While we're here, I forgot to ask you what do you think about wxOCaml?

Well, as far as I'm concerned, I haven't really looked at it.

I've come to like the higher-level constructs in lablgtk and how things
are organized. I believe they take some time to find but once you've
found them, everything seems easier and simpler.
That or Stockholm syndrom.

As far as I know, wxOCaml only has a thin layer to wx currently (it
takes time to do an API that actually looks like typical OCaml).

Apart from that, I can't say much. I'll try to get a deeper look at it.

-- 
Adrien Nader

[Caml-list] Re: OCaml vs Ada and/or GUI options

[Gour]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On Thu, 12 Sep 2013 08:48:49 +0200
Adrien Nader <adrien@notk.org> wrote:

> I've come to like the higher-level constructs in lablgtk and how
> things are organized. I believe they take some time to find but once
> you've found them, everything seems easier and simpler.

That's what I expect from GUI bindings in any higher-level language.

> That or Stockholm syndrom.

:-)

> As far as I know, wxOCaml only has a thin layer to wx currently (it
> takes time to do an API that actually looks like typical OCaml).

Yeah, it's just a beginning...

> Apart from that, I can't say much. I'll try to get a deeper look at
> it.

...but I meant what do you think about the idea in general?


Sincerely,
Gour

-- 
Whatever action a great man performs, common men follow. And 
whatever standards he sets by exemplary acts, all the world pursues.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Alain Frisch]

On 09/12/2013 12:03 AM, Jacques Garrigue wrote:
> BTW, lexifi has also some internal system to build GUIs automatically.
> I don't know if there is a blog post on that.

Indeed, we build GUIs automatically, mapping type definitions to entry 
screens (e.g. a sum type will produce a combobox, a list of record of 
simple types will produce a data grid, etc).  This is based on our 
runtime type extension, and we use attributes on type definitions to 
tweak the GUI layout/behavior (e.g. displaying some float field as a 
percentage, or adding a groupbox around several fields).  Some 
customizations (such as adding buttons) can be added through "patches" 
on the GUI. To specify these patches, we rely on a notion of "type path" 
(strongly typed values describing a path in a data type seen as a tree).

All in all, this is very useful to generate large numbers of entry 
screens without writing any GUI code while ensuring a great level of 
uniformity across the application.  This also makes it possible to 
switch from one underlying GUI technology to another one quite easily 
(our Windows desktop applications currently relies on .NET Windows 
Forms, but we have other GUI backends in place -- including a web based 
one).

Of course, the entire application is not only made of those "uniform" 
entry screens, there are menus, toolbars, interactive charts, pages 
using ad hoc widgets, etc, which are written in a more standard manual 
style.  For these parts, we found it quite convenient to use a 
programming style allowing recursive definitions of controls and 
associated callbacks.  This is described in the "lazy let binding" 
section of this blog post:

  https://www.lexifi.com/blog/ocaml-extensions-lexifi-semi-implicit-laziness

This allows for a more functional style of building GUIs, while keeping 
the standard underlying paradigm (as opposed to FRP GUI frameworks). 
Here is the example from the blog post:

=============================================================
lazy let rec button1 =
   button ~click:(fun () -> button2 # disable) "Button1"
and button2 =
   button ~click:(fun () -> button1 # disable) "Button2"
and my_form =
   form ~title:"Dialog example"
    (hbox
      [
        button1;
        button2;
        button ~click:(fun () -> my_form # close) "Close";
      ]
    )
in
my_form # run_modal
=============================================================

The typical equivalent of this code would require creating the form 
object, the hbox panel, adding widgets to the hbox, adding the hbox to 
the form, setting some text properties, and then registering a callback 
on the buttons.

I guess it would be feasible to write some thin layer on top of LabGTK 
supporting this style (assuming the "lazy let" binding goes upstream!), 
and it would already make the client code look nicer.


Alain

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Am Donnerstag, den 12.09.2013, 08:41 +0200 schrieb Adrien Nader:
> On Wed, Sep 11, 2013, Adrien Nader wrote:
> > >   1. Lack of documentation. LablGTK doc says "look at C GTK doc". But
> > > the lablgtk binding changes things compared to the C API, so this not
> > > a one-to-one mapping neither. And the "obvious" changes weren't so
> > > obvious to me. A tutorial made by a Korean guy IIRC helped a lot;
> > 
> > I'd like to make another tutorial; a much shorter one that matches
> > lablgtk's high-level API (and therefore conciness). Something like a
> > 10-minutes tutorial; I'll try to get a list of topics for it.
> 
> Oh, btw, forgot to mention that I've used ocamlbrowser quite a lot.
> It has a couple issues but it's actually very nice to browse the API of
> lablgtk and other libs.
> 
> Nowadays you can run it through:
>   ocamlbrowser -I $(ocamlfind query lablgtk2)
> (or maybe -I +lablgtk2 but that's not as portable)

Even that:

ocamlfind browser -package lablgtk2

Gerd


> I think that it has really helped me. You select GWindow, then window
> then whatever you want and you have the API for that, in a small window
> that doesn't eat screen space. It doesn't do anything special but I
> found it efficient.
> 
> Using Merlin too is on my TODO list.
> 
> -- 
> Adrien Nader
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

Gour wrote:
> But what is available for writing GUI app using F# on Mac OS?

Xamarin's toolstack can create fully native Mac OS apps using Cocoa
bindings. Mature high-level type-safe bindings to almost everything...

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
Behalf Of Gour
Sent: 11 September 2013 20:45
To: caml-list@inria.fr
Subject: [Caml-list] Re: OCaml vs Ada and/or GUI options

On Wed, 11 Sep 2013 20:36:50 +0100
"Jon Harrop" <jon@ffconsultancy.com> wrote:

> FWIW, I recently installed a dual boot to Ubuntu and found it very 
> clunky compared to Windows. The GUI libraries available for Linux are 
> just awful.

But what is available for writing GUI app using F# on Mac OS?

Isn't it GTK# only?


Sincerely,
Gour

--
Whatever action a great man performs, common men follow. And whatever
standards he sets by exemplary acts, all the world pursues.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

Richard Jones wrote:
> Then someone wants to enter text in Chinese, and someone else needs to use
their speech reader, and so on.

How is Chinese text a problem? 

If cross-platform speech reading is critically important then maybe GTK is
the way to go.

The main application I tried to develop in this way had very tame GUI
requirements: a GL context and load/save dialogs. That proved too hard for
me using OCaml in 2005. Today, we're revisiting it with a view to porting it
to Windows, Android and iOS. The Windows port of the core turned out to be
easy and has been in our F# for Visualization product for years. Having
played with Xamarin Studio it looks like Android and iOS ports will be easy
too. In each case, I'd write the non-GL GUI code using the native GUI
toolkit rather than trying to be cross platform.

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
Behalf Of Richard W.M. Jones
Sent: 11 September 2013 23:18
To: Jon Harrop
Cc: 'Gour'; caml-list@inria.fr
Subject: Re: [Caml-list] Re: OCaml vs Ada and/or GUI options

On Wed, Sep 11, 2013 at 09:06:05PM +0100, Jon Harrop wrote:
> My advice would be to forget about using OCaml's FFI to interop with 
> Linux' GUI libraries and focus instead on writing a new GUI library 
> from scratch in OCaml using OpenGL.
>
> Objectively, OCaml is extremely good for GUI programming. You've 
> already got libraries to load TrueType fonts and tessellate/rasterize 
> them. OpenGL makes it easy to render anything with excellent 
> performance. LablGL even makes picking (i.e. mouse clicks) easy. The 
> result would be cross platform.

Hmm.  Then someone wants to enter text in Chinese, and someone else needs to
use their speech reader, and so on.  Good luck reimplementing the whole of
Gtk.

Rich.

--
Richard Jones
Red Hat

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Richard W.M. Jones]

On Thu, Sep 12, 2013 at 02:49:27PM +0100, Jon Harrop wrote:
> How is Chinese text a problem? 

Because you want to interface to the input-method-du-jour of the
platform you're running on, eg. ibus on modern Linux or who knows what
on old Linux / Windows / OS X.

Now I didn't say anything was impossible -- clearly people have
written toolkits from scratch on many occasions including both me[*]
and you -- just that it's a large amount of boring grind work to deal
with all the different use cases.

Rich.

[*] Mine didn't deal with Asian language input.  It didn't even use
events (everything was polled).  And it only worked on one specific
graphics card which it talked to via a driver which I'd also written!
And it was largely written in 68k asm.

-- 
Richard Jones
Red Hat

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

Anthony Tavener:
> The difficulty is making a library that supports every edge-case that
every developer needs (and still falling short).

Absolutely. My advice is to walk before you can run. OCaml is nowhere near
having competitive support for basic features required for modern GUI
programming much less supporting "every edge-case that every developer
needs". Get something modern that you can use first. Worry about Chinese and
speech reading later. :-)

Cheers,
Jon.

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Alain Frisch]

On 09/12/2013 04:40 PM, Jon Harrop wrote:
> OCaml is nowhere near
> having competitive support for basic features required for modern GUI
> programming

Hi Jon!

Could you more specific?  Are you referring to language features?

-- Alain

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Lukasz Stafiniak]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Thu, Sep 12, 2013 at 4:51 PM, Alain Frisch <alain@frisch.fr> wrote:

> On 09/12/2013 04:40 PM, Jon Harrop wrote:
>
>> OCaml is nowhere near
>> having competitive support for basic features required for modern GUI
>> programming
>>
>
> Hi Jon!
>
> Could you more specific?  Are you referring to language features?
>
>
I think he is referring to "intellisense", on which there has been a steady
progress, but which is perhaps not yet easy to use out-of-the-box (there
are multiple pieces that one has to integrate with one's toolchain and IDE,
i.e. Emacs).

[-- Attachment #2: Type: text/html, Size: 1125 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Alain Frisch]

On 09/12/2013 04:57 PM, Lukasz Stafiniak wrote:
> I think he is referring to "intellisense", on which there has been a
> steady progress, but which is perhaps not yet easy to use out-of-the-box
> (there are multiple pieces that one has to integrate with one's
> toolchain and IDE, i.e. Emacs).

Oh that, the thing which makes developpers 100x less productive? 
Luckily, OCaml developpers are usually 1000x more efficient than the 
average, so they are still 10x more productive overall when programming 
GUIs.  This is probably what Jon meant when he wrote:

 > Objectively, OCaml is extremely good for GUI programming.


-- Alain

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

More the tooling and documentation than the language although there is some
overlap. The OCaml language is good for expressing GUI and graphical
programs. Polymorphic variants are particularly useful.

I'd say the main challenges are:

1. API Exploration: OCamlBrowser is a great little tool but it is much
slower to use to explore a big API (like a GUI toolkit's API) than
Intellisense.

2. Libraries: OCaml has mature bindings to GTK but GTK has very limited
support for modern GUI features. For example, vector graphics are ubiquitous
in modern GUIs and GTK punts this to Cairo which comparable to using the
Acorn DRAW file format from BBC BASIC in 1987 (26 years ago) but without the
high-level memory safety that BBC BASIC offered.

3. Interoperability: both GTK and Qt punt more advanced (e.g. 3D) vector
graphics to OpenGL but OCaml doesn't have any up-to-date OpenGL bindings.
LablGL is mature but I don't think its bindings to GLU were ever finished
and, of course, it only supports OpenGL circa the turn of the millenium.
Ultimately, the problem is that interoperability is hard with OCaml.

4. Samples: There are relatively few OCaml GUI samples out there.

With tablets reinventing user interface designs, the time is ripe for a new
GUI toolkit, e.g. written in OCaml using OpenGL ES 2.0...

Cheers,
Jon.

-----Original Message-----
From: Alain Frisch [mailto:alain@frisch.fr] 
Sent: 12 September 2013 15:52
To: jon@ffconsultancy.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options

On 09/12/2013 04:40 PM, Jon Harrop wrote:
> OCaml is nowhere near
> having competitive support for basic features required for modern GUI 
> programming

Hi Jon!

Could you more specific?  Are you referring to language features?

-- Alain

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Kakadu]

If we seriously talking about OpenGL GUI I should mention that QtQuick
already uses OpenGL to render itself. Also, if you are going to write
some phone app with OCaml Qt will also be helpful

Kaladu

On Sat, Sep 14, 2013 at 7:05 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> More the tooling and documentation than the language although there is some
> overlap. The OCaml language is good for expressing GUI and graphical
> programs. Polymorphic variants are particularly useful.
>
> I'd say the main challenges are:
>
> 1. API Exploration: OCamlBrowser is a great little tool but it is much
> slower to use to explore a big API (like a GUI toolkit's API) than
> Intellisense.
>
> 2. Libraries: OCaml has mature bindings to GTK but GTK has very limited
> support for modern GUI features. For example, vector graphics are ubiquitous
> in modern GUIs and GTK punts this to Cairo which comparable to using the
> Acorn DRAW file format from BBC BASIC in 1987 (26 years ago) but without the
> high-level memory safety that BBC BASIC offered.
>
> 3. Interoperability: both GTK and Qt punt more advanced (e.g. 3D) vector
> graphics to OpenGL but OCaml doesn't have any up-to-date OpenGL bindings.
> LablGL is mature but I don't think its bindings to GLU were ever finished
> and, of course, it only supports OpenGL circa the turn of the millenium.
> Ultimately, the problem is that interoperability is hard with OCaml.
>
> 4. Samples: There are relatively few OCaml GUI samples out there.
>
> With tablets reinventing user interface designs, the time is ripe for a new
> GUI toolkit, e.g. written in OCaml using OpenGL ES 2.0...
>
> Cheers,
> Jon.
>
> -----Original Message-----
> From: Alain Frisch [mailto:alain@frisch.fr]
> Sent: 12 September 2013 15:52
> To: jon@ffconsultancy.com
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options
>
> On 09/12/2013 04:40 PM, Jon Harrop wrote:
>> OCaml is nowhere near
>> having competitive support for basic features required for modern GUI
>> programming
>
> Hi Jon!
>
> Could you more specific?  Are you referring to language features?
>
> -- Alain
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] OCaml vs Ada and/or GUI options

[Jon Harrop]

Yes. What is the state of Qt bindings for OCaml these days?

Cheers,
Jon.

-----Original Message-----
From: Kakadu [mailto:kakadu.hafanana@gmail.com] 
Sent: 14 September 2013 08:11
To: jon@ffconsultancy.com
Cc: Alain Frisch; Caml List
Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options

If we seriously talking about OpenGL GUI I should mention that QtQuick
already uses OpenGL to render itself. Also, if you are going to write some
phone app with OCaml Qt will also be helpful

Kaladu

On Sat, Sep 14, 2013 at 7:05 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> More the tooling and documentation than the language although there is 
> some overlap. The OCaml language is good for expressing GUI and 
> graphical programs. Polymorphic variants are particularly useful.
>
> I'd say the main challenges are:
>
> 1. API Exploration: OCamlBrowser is a great little tool but it is much 
> slower to use to explore a big API (like a GUI toolkit's API) than 
> Intellisense.
>
> 2. Libraries: OCaml has mature bindings to GTK but GTK has very 
> limited support for modern GUI features. For example, vector graphics 
> are ubiquitous in modern GUIs and GTK punts this to Cairo which 
> comparable to using the Acorn DRAW file format from BBC BASIC in 1987 
> (26 years ago) but without the high-level memory safety that BBC BASIC
offered.
>
> 3. Interoperability: both GTK and Qt punt more advanced (e.g. 3D) 
> vector graphics to OpenGL but OCaml doesn't have any up-to-date OpenGL
bindings.
> LablGL is mature but I don't think its bindings to GLU were ever 
> finished and, of course, it only supports OpenGL circa the turn of the
millenium.
> Ultimately, the problem is that interoperability is hard with OCaml.
>
> 4. Samples: There are relatively few OCaml GUI samples out there.
>
> With tablets reinventing user interface designs, the time is ripe for 
> a new GUI toolkit, e.g. written in OCaml using OpenGL ES 2.0...
>
> Cheers,
> Jon.
>
> -----Original Message-----
> From: Alain Frisch [mailto:alain@frisch.fr]
> Sent: 12 September 2013 15:52
> To: jon@ffconsultancy.com
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options
>
> On 09/12/2013 04:40 PM, Jon Harrop wrote:
>> OCaml is nowhere near
>> having competitive support for basic features required for modern GUI 
>> programming
>
> Hi Jon!
>
> Could you more specific?  Are you referring to language features?
>
> -- Alain
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Francois¡¡Charles Matthieu¡¡Berenger]

On Sat, 14 Sep 2013 04:05:17 +0100
Jon Harrop <jon@ffconsultancy.com> wrote:

> 
> More the tooling and documentation than the language although there is some
> overlap. The OCaml language is good for expressing GUI and graphical
> programs. Polymorphic variants are particularly useful.
> 
> I'd say the main challenges are:
> 
> 1. API Exploration: OCamlBrowser is a great little tool but it is much
> slower to use to explore a big API (like a GUI toolkit's API) than
> Intellisense.

By the way, where is the OCamlBrowser package for OPAM?

Is it not available via OPAM?

Regards,
F.

> 2. Libraries: OCaml has mature bindings to GTK but GTK has very limited
> support for modern GUI features. For example, vector graphics are ubiquitous
> in modern GUIs and GTK punts this to Cairo which comparable to using the
> Acorn DRAW file format from BBC BASIC in 1987 (26 years ago) but without the
> high-level memory safety that BBC BASIC offered.
> 
> 3. Interoperability: both GTK and Qt punt more advanced (e.g. 3D) vector
> graphics to OpenGL but OCaml doesn't have any up-to-date OpenGL bindings.
> LablGL is mature but I don't think its bindings to GLU were ever finished
> and, of course, it only supports OpenGL circa the turn of the millenium.
> Ultimately, the problem is that interoperability is hard with OCaml.
> 
> 4. Samples: There are relatively few OCaml GUI samples out there.
> 
> With tablets reinventing user interface designs, the time is ripe for a new
> GUI toolkit, e.g. written in OCaml using OpenGL ES 2.0...
> 
> Cheers,
> Jon.
> 
> -----Original Message-----
> From: Alain Frisch [mailto:alain@frisch.fr] 
> Sent: 12 September 2013 15:52
> To: jon@ffconsultancy.com
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options
> 
> On 09/12/2013 04:40 PM, Jon Harrop wrote:
> > OCaml is nowhere near
> > having competitive support for basic features required for modern GUI 
> > programming
> 
> Hi Jon!
> 
> Could you more specific?  Are you referring to language features?
> 
> -- Alain
> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Kakadu]

For simple applications: I think it's ready to replace C++. For
complex ones I'm not so sure (some complex widgets can be not
expressable in pure QML), some testing/testers/users are needed.

I have demo application there: https://github.com/Kakadu/QOcamlBrowser_quick
Some opam installation instructions there: http://kakadu.github.io/lablqt/

Best wishes,
Kakadu

On Sat, Sep 14, 2013 at 3:37 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> Yes. What is the state of Qt bindings for OCaml these days?
>
> Cheers,
> Jon.
>
> -----Original Message-----
> From: Kakadu [mailto:kakadu.hafanana@gmail.com]
> Sent: 14 September 2013 08:11
> To: jon@ffconsultancy.com
> Cc: Alain Frisch; Caml List
> Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options
>
> If we seriously talking about OpenGL GUI I should mention that QtQuick
> already uses OpenGL to render itself. Also, if you are going to write some
> phone app with OCaml Qt will also be helpful
>
> Kaladu
>
> On Sat, Sep 14, 2013 at 7:05 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>>
>> More the tooling and documentation than the language although there is
>> some overlap. The OCaml language is good for expressing GUI and
>> graphical programs. Polymorphic variants are particularly useful.
>>
>> I'd say the main challenges are:
>>
>> 1. API Exploration: OCamlBrowser is a great little tool but it is much
>> slower to use to explore a big API (like a GUI toolkit's API) than
>> Intellisense.
>>
>> 2. Libraries: OCaml has mature bindings to GTK but GTK has very
>> limited support for modern GUI features. For example, vector graphics
>> are ubiquitous in modern GUIs and GTK punts this to Cairo which
>> comparable to using the Acorn DRAW file format from BBC BASIC in 1987
>> (26 years ago) but without the high-level memory safety that BBC BASIC
> offered.
>>
>> 3. Interoperability: both GTK and Qt punt more advanced (e.g. 3D)
>> vector graphics to OpenGL but OCaml doesn't have any up-to-date OpenGL
> bindings.
>> LablGL is mature but I don't think its bindings to GLU were ever
>> finished and, of course, it only supports OpenGL circa the turn of the
> millenium.
>> Ultimately, the problem is that interoperability is hard with OCaml.
>>
>> 4. Samples: There are relatively few OCaml GUI samples out there.
>>
>> With tablets reinventing user interface designs, the time is ripe for
>> a new GUI toolkit, e.g. written in OCaml using OpenGL ES 2.0...
>>
>> Cheers,
>> Jon.
>>
>> -----Original Message-----
>> From: Alain Frisch [mailto:alain@frisch.fr]
>> Sent: 12 September 2013 15:52
>> To: jon@ffconsultancy.com
>> Cc: caml-list@inria.fr
>> Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options
>>
>> On 09/12/2013 04:40 PM, Jon Harrop wrote:
>>> OCaml is nowhere near
>>> having competitive support for basic features required for modern GUI
>>> programming
>>
>> Hi Jon!
>>
>> Could you more specific?  Are you referring to language features?
>>
>> -- Alain
>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 13:42:49 +0200
Gerd Stolpmann <info@gerd-stolpmann.de> wrote:

> We would need an HTML5 binding so the programmer wouldn't see the
> Javascript part.

In my search for adequate GUI bindings I've found out about OCaml
bindings (https://github.com/astrada/ocaml-extjs) for ExtJS
(http://www.sencha.com/products/extjs/) so wonder what is your
experience with js_of_ocaml in generall and/or ExtJS?


Sincerely,
Gour

-- 
What is night for all beings is the time of awakening 
for the self-controlled; and the time of awakening for 
all beings is night for the introspective sage.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Am Mittwoch, den 18.09.2013, 13:42 +0200 schrieb Gour:
> On Wed, 11 Sep 2013 13:42:49 +0200
> Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> > We would need an HTML5 binding so the programmer wouldn't see the
> > Javascript part.
> 
> In my search for adequate GUI bindings I've found out about OCaml
> bindings (https://github.com/astrada/ocaml-extjs) for ExtJS
> (http://www.sencha.com/products/extjs/) so wonder what is your
> experience with js_of_ocaml in generall and/or ExtJS?

js_of_ocaml in general: Very good experience so far, it just runs the
code, and with good speed. I haven't used it yet to create complex UIs,
though (what I did was rather trivial on the UI side, - while the
computational backend was quite complicated). It is easy to interface
with JS.

No experience with ExtJS.

Gerd

> 
> 
> Sincerely,
> Gour
> 
> -- 
> What is night for all beings is the time of awakening 
> for the self-controlled; and the time of awakening for 
> all beings is night for the introspective sage.
> 
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
> 
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Alain Frisch]

We have done some experiments running LexiFi's core libraries (symbolic 
manipulations of terms representing financial contracts) in the browser, 
using js_of_ocaml.  We also played with dynamic GUI generation directly 
in the browser, based on our runtime type extension (which works fine 
with js_of_ocaml).

Overall, we were impressed by the easiness to integrate js_of_ocaml (no 
need to patch the compiler or do big changes to the build system) and 
its faithfulness to the semantics of OCaml.  Really no big bad 
surprises, and it was amazing to see a complex piece of software running 
in the browser.  js_of_ocaml opens many interesting doors for using 
OCaml in web development!


(((Some points which required some special care:

   - Support for C primitives.  Each primitive called by the bytecode 
needs to have a Javascript implementation.  Since LexiFi's version of 
OCaml is most often synchronized with OCaml's trunk than with a stable 
release, we had to implement the new primitives.  This raises the 
general point that js_of_ocaml will need some active maintenance, even 
if the OCaml bytecode itself is very stable across versions.

  - A tiny semantic difference: in OCaml, the expression 
"String.unsafe_get s (String.length s)" returns '\000', which gives an 
efficient way to iterate over a string without checking for the 
end-of-string condition explicitly.  This hack (which is also used in 
the stdlib module, btw) does not work with the way strings are 
represented in js_of_ocaml.  That said, we were quite happy to see that 
other low-level hacks we do with the runtime representation of values 
worked well (setting a block tag to Object_tag to force generic 
comparison and hashing to use the second field; or playing with the 
representation of method tables to memoize method calls).

  - The lack of weak hash tables, which we use quite a lot.  I wonder if 
Firefox's experimental WeakMap could be used to simulate them (and if 
other browsers will get similar features).

  - Reliance on Camlp4 for interacting with Javascript.  Getting rid of 
this dependency was our first internal use of -ppx!
)))


Alain




On 09/18/2013 01:42 PM, Gour wrote:
> On Wed, 11 Sep 2013 13:42:49 +0200
> Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>
>> We would need an HTML5 binding so the programmer wouldn't see the
>> Javascript part.
>
> In my search for adequate GUI bindings I've found out about OCaml
> bindings (https://github.com/astrada/ocaml-extjs) for ExtJS
> (http://www.sencha.com/products/extjs/) so wonder what is your
> experience with js_of_ocaml in generall and/or ExtJS?
>
>
> Sincerely,
> Gour
>

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Daniel Bünzli]

Le jeudi, 19 septembre 2013 à 10:11, Alain Frisch a écrit :
> - The lack of weak hash tables, which we use quite a lot. I wonder if
> Firefox's experimental WeakMap could be used to simulate them (and if  
> other browsers will get similar features).

AFAIK, the answer is no. I explain why in this message [1].

Best,

Daniel

[1] https://lists.cam.ac.uk/pipermail/cl-mirage/2013-April/msg00032.html

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Andreas Rossberg]

On Sep 19, 2013, at 10:30 , Daniel Bünzli <daniel.buenzli@erratique.ch> wrote:
> Le jeudi, 19 septembre 2013 à 10:11, Alain Frisch a écrit :
>> - The lack of weak hash tables, which we use quite a lot. I wonder if
>> Firefox's experimental WeakMap could be used to simulate them (and if  
>> other browsers will get similar features).
> 
> AFAIK, the answer is no. I explain why in this message [1].

As you say, WeakMap is a feature of the upcoming EcmaScript 6 standard, and hence will be supported by all browsers sometime soon.  (FWIW, Chrome also has supported WeakMap for a while, albeit you still need to turn on the 'Experimental JavaScript' flag on the chrome://flags page. And IIRC, other vendors are working on it already.)

But yes, WeakMap is carefully designed to not make GC observable, so it cannot implement weak references. Weak references are on the agenda for ES7, but that will take another two years at least.

/Andreas

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gour]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Wed, 18 Sep 2013 14:24:36 +0200
Gerd Stolpmann <info@gerd-stolpmann.de> wrote:

> js_of_ocaml in general: Very good experience so far, it just runs the
> code, and with good speed. I haven't used it yet to create complex
> UIs, though (what I did was rather trivial on the UI side, - while the
> computational backend was quite complicated). It is easy to interface
> with JS.

Thanks a lot - it sounds good.


Sincerely,
Gour

-- 
One who works in devotion, who is a pure soul, and who controls 
his mind and senses is dear to everyone, and everyone is dear to 
him. Though always working, such a man is never entangled.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gour]

On Thu, 19 Sep 2013 10:11:51 +0200
Alain Frisch <alain@frisch.fr> wrote:

> Overall, we were impressed by the easiness to integrate js_of_ocaml
> (no need to patch the compiler or do big changes to the build system)
> and its faithfulness to the semantics of OCaml.  Really no big bad 
> surprises, and it was amazing to see a complex piece of software
> running in the browser.  

Great!

> js_of_ocaml opens many interesting doors for using OCaml in web
> development!

Does it include writing desktop apps running in browser?

:-)


Considering I have a need to call 3rd party C lib via OCaml bindings,
does it change anything in the whole scenario?


Sincerely,
Gour

-- 
From wherever the mind wanders due to its flickering and unsteady 
nature, one must certainly withdraw it and bring it back under 
the control of the self.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

Am Freitag, den 20.09.2013, 06:51 +0200 schrieb Gour:
> On Thu, 19 Sep 2013 10:11:51 +0200
> Alain Frisch <alain@frisch.fr> wrote:
> 
> > Overall, we were impressed by the easiness to integrate js_of_ocaml
> > (no need to patch the compiler or do big changes to the build system)
> > and its faithfulness to the semantics of OCaml.  Really no big bad 
> > surprises, and it was amazing to see a complex piece of software
> > running in the browser.  
> 
> Great!
> 
> > js_of_ocaml opens many interesting doors for using OCaml in web
> > development!
> 
> Does it include writing desktop apps running in browser?
> 
> :-)

I would say so - although you won't get the "look and feel" of a desktop
app, but of a web app. From a design perspective, this is a big win
IMHO, and users probably even like this. E.g. you'll need to use
graphically designed menus, and no menu bars.

The biggest problem I see is that the interaction with the system is
limited (e.g. access to file system is generally not possible with the
exception of special browser-app areas - see "local storage" [1] and
"indexed database API" [2]; there are browser-specific API extensions,
though).

[1] https://en.wikipedia.org/wiki/Web_storage
[2] https://en.wikipedia.org/wiki/Indexed_Database_API

If you are willing to accept browser differences, this is an interesting
option with some future - there is an enormous pressure on the desktop
vendors to make the desktop as easy as the web, e.g you can already run
web apps directly in the Windows 8 desktop (the user doesn't see that
there is a browser running it).

> 
> 
> Considering I have a need to call 3rd party C lib via OCaml bindings,
> does it change anything in the whole scenario?

This won't be directly available, but only with the indirection of
running the lib in a local server process, and accessing it via HTML
requests. (Unless you include it as browser plugin.)

Gerd

> 
> Sincerely,
> Gour
> 
> -- 
> From wherever the mind wanders due to its flickering and unsteady 
> nature, one must certainly withdraw it and bring it back under 
> the control of the self.
> 
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
> 
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Caml-list] OCaml vs Ada and/or GUI options

[Gour]

On Wed, 11 Sep 2013 18:00:07 +0900
Francois Berenger <berenger@riken.jp> wrote:

> My 2 cents: a productive researcher in my field is
> quite interested in GUIs and portability of his software.
> He uses Python.

Forgot to ask whether he uses Qt or wx bindings?


-- 
One must deliver himself with the help of his mind, and not 
degrade himself. The mind is the friend of the conditioned soul, 
and his enemy as well.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810