About Slate and GUI

[Paul Dufresne]

Well, I could have put "Just to say I am still alive" as the subject
line, but
I guess "About Slate and GUI" will be more correct for the follows up I
can expect.

I am not too proud of the work on SDL I made for Slate.
I was having a bad time, to understand the DUIM-morphic base Brian did.

I have been trying to read and use DUIM from OpenDylan. Dylan has mainly
two
implementations: Gwydion Dylan d2c (that compile Dylan to C code), and
the
old Harlequin's implementation that have been open-sourced for about 1
year,
and is now maintained by the same guys as Gwydion Dylan, that have
renamed it
OpenDylan.

Before understanding DUIM sources, I had to learn a bit of Dylan. I was
very
impressed and please to see that Dylan had a semantic not so different
than
Slate. I was surprised to learn that Dylan could be seen as a
functionnal language.
I was even more surprised to see that Dylan have multiple dispatch that
I have learn
about for the first time with Slate.
I ask myself what is the difference between a prototype based language
and a dynamic
(one could add new methods while running) like Dylan. Yes Dylan have
class(es), but there
very unlike static languages like C++ where they are a fixed model to
build all identical
instances. Indeed, all instances of a class have to be the same, but
when you can so
easily define dynamically new classes and methods on them, the
distinction between the
two, begin to blur. Dylan have optional typing, just like Slate.
Frankly, for me, Slate and
Dylan are so similar, that I believe I prefer Dylan, for still using
plain old class(es),
while not making them static.

Anyway, I recently learn that Goo is based on Dylan. But it is with a
Lispish syntax.
In fact Dylan was at the beginning, with a Lispish syntax too. Goo
syntax is short,
like dm for define-method, dv for define variable, etc. Goo have an old
GUI library that
does not work anymore, based on GTK. This was using SWIG to interface
with C GTK library.
But Goo have a newer C FFI (Alien GOO) that try to let you write C code,
with quite easy
access to functions to switch between C variables and Goo variables and
functions.

I never really learn how to use QT library (KDE) or GTK+ library. In
fact, I was a bit unhappy
with the fact that Linux did not choose one, and rather to decide which
one I wanted to learn,
I have been looking for an alternative OS that would include one, like
Syllable OS. I recently
also played a bit with Spoon OS based on Spoon microkernel written in
C++. Anyway, only
recently did I learn that QT is dual license: commercial or GPL, and
that GTK is really
LGPL. I was once told by a friend that much more people were using KDE
than GNOME (this friend
was convince KDE is much better) and some opinions had almost convinced
me. But now that I
know that GTK+ is LGPL, have signals much like QT, is now using CAIRO
graphics library, my
choice is made, and I prefer GNOME (GTK+).

So, what is the link with Slate GUI. Well, I was a bit unhappy to see
that noone have been
willing to try to use or continue my SDL code for Slate (somehow, I was
hoping that someone
that would be brighter than me and would be good to understand Brian
code, would try to
integrate it with my SDL code). But I now feel that SDL is a bit too
low-level to serve as
the level under DUIM-morphic code. I now have the feeling GTK+ would be
more appropriate.
But for now, I have quite some fun, learning GOO (I like to see/learn
new programming
language, but become bored quite fastly too). And I am more likely to
try interfacing GTK+
with GOO, than with Slate, but maybe I could try to do it for Slate (in
the very long term).

It is not so obvious to me (as it seems to be for Brian) why the
concurrency have to be
implemented in Slate, before working on the GUI code.
By the way, how much finish are the new promise concurrency model in
Slate?

Briefly, I would be happy to see someone a bit better than me with GUI
code, to continue
on my previous work. I could help, but not lead this project.

-- 
http://www.fastmail.fm - Access your email from home and the web