Hi Peter,
sorry for that late reply. Due to a misbehaving progmailrc your last mail was sorted into the cells-devel folder where I didn't read it.
Please find the following patched attached:
0001-Remove-clisp-hack.patch
Complete removes the clisp-call-next-method hack as I think it's no longer needed at all. See below.
0002-In-cells3-def-c-output-was-renamed-to-defobserver.patch
Renames remaining occurrences of 'def-c-output'. I wonder why there weren't any errors as the macro was removed from cells3.
0003-Inactivate-optional-stuff-by-default.patch
Inactivate optional features (threads, cairo, opengl and libcellsgtk) by default. I think it's more convenient to activate those when needed instead of patching the .asd files all the time. Test-gtk.asd still does exactly this.
- Also if used in a single threading environment (like clisp)
(g-thread-init...) and (gdk-threads-init) do get called which results in an error.
Hmm, I never changed that, I think. They were always called in cells-gtk if IIRC. However, if it does no harm to leave them out, then that seems the right thing to do.
Are you on windows or linux? I'm just guessing, but it might be the case that it is a GTK issue and not a cells-gtk issue whether to call them: On linux GTK supports threads, so it might be necessary to call those (even if you don't use threads yourself). On windows it doesn't, so maybe you can't call them. In this case, we should condition on :unix vs. :windows. But again, I'm just guessing. If you're on linux, then forget everything I said.
I'm primarily on sbcl/linux. Recently I started to maintain the project for clisp/windows. As far as I remember thought, I realized the described problem have way down on clisp/linux.
As to the call-next-method thing, the background is this:
[...]
I'd suggest you just go ahead and deactivate allthose calls (e.g by conditioning on :no-progn-combination instead of :clisp), which should remove those warnings.
As mentioned above I decided against ':no-progn-combination'.
In my opinion the call-next-method hack is of little use since '(:method-combination progn)' was removed for clisp in 'cells.lisp'.
Please tell me in case I'm wrong here so I can change the patch.
Thanks again (everybody)
Ingo
_______________________________________________________________ Schon gehört? Der neue WEB.DE MultiMessenger kann`s mit allen: http://www.produkte.web.de/messenger/?did=3016
Hi Ingo,
thanks a lot for the patches. I committed them today.
Additionally I added some support for "gtkmisc"; now you can layout labels, images, and arrows with xalign, yalign, xpad, and ypad without the need for an alignmnent container. I changed the label widget to default to left (vs. centered). Let me know what you think.
Also, I moved the configure event to notify about reshaping from gtk-object to widget, thus getting rid of a few warnings.
Cheers, Peter
On 6/1/08, Ingo Bormuth Bormuth@web.de wrote:
Hi Peter,
sorry for that late reply. Due to a misbehaving progmailrc your last mail was sorted into the cells-devel folder where I didn't read it.
Please find the following patched attached:
0001-Remove-clisp-hack.patch
Complete removes the clisp-call-next-method hack as I think it's no longer needed at all. See below.0002-In-cells3-def-c-output-was-renamed-to-defobserver.patch
Renames remaining occurrences of 'def-c-output'. I wonder why there weren't any errors as the macro was removed from cells3.0003-Inactivate-optional-stuff-by-default.patch
Inactivate optional features (threads, cairo, opengl and libcellsgtk) by default. I think it's more convenient to activate those when needed instead of patching the .asd files all the time. Test-gtk.asd still does exactly this.
- Also if used in a single threading environment (like clisp)
(g-thread-init...) and (gdk-threads-init) do get called which results in an error.
Hmm, I never changed that, I think. They were always called in cells-gtk if IIRC. However, if it does no harm to leave them out, then that seems the right thing to do.
Are you on windows or linux? I'm just guessing, but it might be the case that it is a GTK issue and not a cells-gtk issue whether to call them: On linux GTK supports threads, so it might be necessary to call those (even if you don't use threads yourself). On windows it doesn't, so maybe you can't call them. In this case, we should condition on :unix vs. :windows. But again, I'm just guessing. If you're on linux, then forget everything I said.
I'm primarily on sbcl/linux. Recently I started to maintain the project for clisp/windows. As far as I remember thought, I realized the described problem have way down on clisp/linux.
As to the call-next-method thing, the background is this:
[...]
I'd suggest you just go ahead and deactivate allthose calls (e.g by conditioning on :no-progn-combination instead of :clisp), which should remove those warnings.
As mentioned above I decided against ':no-progn-combination'.
In my opinion the call-next-method hack is of little use since '(:method-combination progn)' was removed for clisp in 'cells.lisp'.
Please tell me in case I'm wrong here so I can change the patch.
Thanks again (everybody)
Ingo
Schon gehört? Der neue WEB.DE MultiMessenger kann`s mit allen: http://www.produkte.web.de/messenger/?did=3016
-
Ingo Bormuth -
Peter Hildebrandt