On Tue, 2006-12-05 at 16:26 +0100, Duncan Coutts wrote:
On Tue, 2006-12-05 at 14:28 +0100, Hans van Thiel wrote:
> Hello All,
> I've sent a first draft of the first part in txt2tags format to darcs
> and I attach it here too.


BTW, It looks like the 'darcs send' email didn't come through. You
should probably check that your local mail is working. Sadly, just
because darcs send completes doesn't guarantee that the mail agent is
correctly configured. Usually the problem is that the local mail agent
hasn't been set up to forward outgoing mail to the ISP's smtp server.
For example with ssmtp one has to set the mailhub setting
in /etc/ssmtp/ssmtp.conf 
I'm using the standard package for fc6 and this should work out of the box, especially since configuring sendmail is not part of the standard fc6 distribution. Maybe it's something simple, to do with security settings. I'll look into it. Meanwhile, I hope you got the text in a readable form.

It's good to get darcs send working as it makes life much easier when
doing minor edits. It gets kind of tiring to send a new email with an
attachment for a few one line fixes. :-)

So I'll hold of adding the attached version for a couple days to give
you a chance to darcs send again (- that way you get proper credit in
the change log!)

> Duncan, when I run make I get the error
> message:
> make: *** No rule to make target '../../gtk/Graphics/UI/Gtk.hi, needed
> by '../exports' Stop

Yeah, as Axel said it's because it needs everything to be built first.

Here's the quick fix: download this file to your gtk2hs/docs/tutorial/
directory and then 'make' again.

This doesn't work either, but I suspect it's all because I use a local copy of the gtk2hs directory. I've installed ghc 6.6, Gtk2Hs and the Gtk2Hs docs as standard fc6 packages (but not Haddock yet) and I don't want to change anything there manually. But I suppose substituting absolute filepaths in the make files would fix it.

Meanwhile, a question for the developers which should be addressed in the intro tutorial. Compiling the Hello World example with ghc 6.6 works as the tutorial outline says, but ghci needs a no threaded flag. (see my draft). But when I tested the Glade examples, with ghc 6.4 and gtk2hs under fedora core 5 two months ago, ghci worked just fine. So, what is needed for ghci, or are the current gtk2hs and interactive compiler versions incompatible?
And is there a way to use Hugs? Both fc5 and fc6 versions couldn't find the import graphics module, but I suppose there's more to this than that? And maybe there should also be a command for YHC as well as GHC?
Alternatively you can do the build yourself. Build instructions are
basically: (from the root of the build tree)
./configure --enable-hcflags=-O0


What it's actually doing is using gtk/Graphics/UI/Gtk.hi to generate an
index of all the exported Gtk2Hs functions and using that to link
functions in Haskell code snippets to their corresponding haddock
documentation. Cool stuff, but it does need Gtk2Hs to be built first. So
the short-cut is just to grab that exports file that I generated.

I've not included any html header, footer or .ccs file in the docs dir
so the docs come out looking fairly ordinary. I should fix that. I do
have a header/footer that we use for the Gtk2Hs site which includes CSS
for the Haskell syntax highlighting etc.

> In the file index.t2t I've noted some further problems and questions as
> comments.

Ok, great.

> I think that what the beginning user needs to know most is how
> the Gtk+ object oriented specification with classes and instances,
> attributes and methods is mapped into the Haskell type system and how
> the api reflects this.

Yes, this is important for understanding. Though I'm not sure it should
go first. I often think starting with an example helps (eg hello world)
before going into the detailed explanation of the structure.
> After that a global  overview of what events are and what the
> difference is with signals.

As Axel said, we try not to distinguish between events and signals.

Technically, events are things that come directly from X11, like mouse
clicks etc however Gtk+ maps all of these into signals on GtkWidget, so
this allows us to say that there are just signals.
Ok, that's pretty clear.
> (From the api I gather the user can also cause things to happen
> directly from events (?).

Not sure what you mean here.
Sorry, got confused here.

So basically we have, objects which are OOP style objects with mutable
state. The object types form a hierarchy, for example Widget is an
Object and Button is a Widget (and an object). Objects can have
attributes, signals and methods. Each object type has a couple type
casting functions (for safe upcasting and checked downcasting). Most
object types have a constructor function so you can actually make one
(though some are abstract, like Widget or Object).
Thanks, this helps. And is it true that an object class is always a Haskell type class and that an instance corresponds to a Haskell type? And 'self' in type declarations is borrowed from OO and stands for the handle of an instance (actually its type)?

Attributes use the syntax:
 get object attr
 set object [ attr1 := value1, attr2 := value2 ]

At the moment for many attributes there are also methods that duplicate
the functionality. We intend to deprecate these methods in future so we
should encourage people to use the attribute syntax rather than the
widgetGetFoo / widgetSetBar style.
Again, very clear.

For signals, there's an on<Signal> and after<Signal> function per signal
(in the future this will change slightly but not significantly).
Another handy rule. The main purpose of the introduction imo is to provide a guide to the api so the user can quickly and correctly pick and use what he or she wants, from the available widgets.
I hope to finish a complete first draft in a week or two... :-)

A question for Thomas van Noort: any way to view your presentation on building GUIs in Haskell? Sounds interesting!

To others as well, if you have anything which might help, especially problems which you have encountered and solved, please post them here.