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
_______________________________________________
cells-gtk-devel site list
cells-gtk-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-gtk-devel
