[cells-gtk-devel] Re: Roberto

[Peter Hildebrandt]

Hi Roberto,

I don't know what's wrong with the cells-gtk-devel list.  I had trouble 
mailing there, too, though.  Maybe there's an over-zealous spam filter 
at work?  I cc'd the list, let's see what happens.

> Any idea? By the way, I have done a very simple window, with a title, a label, 
> another label for the 
> counter, one button for a message dialog, and lastly a label in which I 
> visualize my text entry from the message dialog:

Congrats!  You're moving along quickly.

> The problem is that in this version of cells-gtk (with all your patches 
> applied) I can't see the entry area for the text (while I can see it, and I 
> succeed in write text and visualize it in the label in the main window, with 
> the old version 2006-06-30). The same thing occur to me for the "new" 
> gtk-demo. Everything's work, except that I can't visualize a text entry in: 
> Dialogs - Query for text - Type something.....Again, there is no area in 
> which I could write something... 

I know this one.  It is in fact the only known bug I introduced when I 
built the multi threading thing.  A work around would be to make a 
conventional window with an entry box instead of using the message 
dialog function:

(make-instance 'window
   :kids (c-in (list
                 (mk-vbox
                    :kids (c-in (list
                       (mk-label :text "Enter something:")
                       (mk-entry :md-name :entry)))))))

should work (not tested).  I solved the problem (I think) while porting 
cells-gtk to cells 3.  This, however, is still pretty much work in 
progress, so I'd recommend this work around for now.

> And, more important, in the new Tree view - 
> Cells Tree View, when I select a node, I retrieve this error message:
> 
> Lisp Error: There is no applicable method for the generic function
>      #<STANDARD-GENERIC-FUNCTION CHILDREN-FN(2)>
>                  when called with arguments
>         (NIL)
>          Recklessly continue?         Yes       No

Well -- yes.  The cells-tree-view is still a little more shaky than I 
thought.  I did a good deal of testing, but I overlooked certain things. 
  When porting it to cells 3 (which is more strict in many respects), it 
became obvious that my design was a little edgy here and there.  I'm 
working on it, but it is low priority right now, since I need to get the 
cairo drawing stuff and opengl up and running first.

As soon as cells-gtk3 has grown a little more mature, I'll post it here. 
  For now, I need to focus on other things;  I got job interviews coming 
up tomorrow and the day after.

> If I click Yes, the application goes on and I can visualize the children nodes 
> and add any node that I want (but can't delete them), check the boxes and 
> affect 
> the other (but in the meanwhile the error message reappears, and I have to 
> click yes again, while if I click no, everything crashes....).

Yep, but this is actually "intended":  If cells-gtk runs into a problem, 
usually all that SBCL has to offer is to terminate the gtk-main thread, 
which in turn ruins your lisp session's gtk connection, and you need to 
restart SBCL.  That's why I created the "recklessly continue":  It lets 
you return to the app and quit it gracefully, so that it does not take 
the gtk communication down.

Maybe the commercial lisps are doing better in terms of restarts; I read 
something like that on Planet Lisp a few weeks ago.  Maybe they'd let 
you restart the gtk-thread after you click "no".

> The last thing I would ask you, is if you actually implement this *fantastic* 
> tool, and in the case the answer is YES ( as I hope... ;) ) , in what 
> direction you are looking for ( say, a more easy installation (..... :) ) , a 
> graphic development environment, and so on)  

Well, quoting Ken Tilton (I hope he doesn't mind), "I'm just a simple 
application programmer", that is, I am out to write an application that 
I need for my research.  And I decided it'd be great to write this 
application in lisp, and use cells.  Hence I need a cells-inside GUI. 
And since I prefer GTK widgets over Tcl/Tk's (mainly since Tcl/Tk used 
to look crappy on linux at the time I got started), I set out to make 
cells-gtk fit my needs.

I am happy to make cells-gtk better, but it is not my primary concern at 
the moment (and probably won't become it in the near future).  Right now 
I need to finish my application, write up my work, publish a few papers, 
and get on with my life (that is, get a real, paid job).

Apart from this, I am glad about suggestions for cells-gtk, and I am 
happy to share my work if it is useful to others.

Given this, the direction I am looking at is

* finish the cells3 port (nearly done)

* iron out a few bugs (text entry widget (nearly done), cells-tree-view 
(lots of work to do), menu item labels appearing centred (no idea why), 
error handling (I'm making progress))

* add graphics functionality (cairo (nearly complete) and opengl (not 
yet started))

The installation process is a pain, but I am not quite sure what to do 
about it.  My dream would be to update the asdf-install package and have 
it compile libcellsgtk.so at compile time (e.g. cl-ode does that).

I have never thought about a graphic UI designer.  I won't have the 
resources it would take to get this right, but it could be a cool 
project.  OTOH, you have lisp.  Just do C-c C-c on the defmodel for the 
window and pull it up from the repl.  If you don't like, change the code 
and start over.  The cycle is less that 10 seconds.  We're not talking 
Java :-)

Alright, so far for today.  I'll be out tomorrow and Friday, but I'll be 
back here during the weekend.

Cheers,
Peter


> Ok, Peter, I think for now it's enough....    ;)
> Thank you again,
> Roberto