[cells-gtk-devel] cells-gtk3 without libcellsgtk

[Ingo Bormuth]

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.

> > 2. 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 all
> those 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-clisp-hack.patch
Type: text/x-patch
Size: 7210 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20080601/f77cddfa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-In-cells3-def-c-output-was-renamed-to-defobserver.patch
Type: text/x-patch
Size: 2762 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20080601/f77cddfa/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Inactivate-optional-stuff-by-default.patch
Type: text/x-patch
Size: 2197 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-gtk-devel/attachments/20080601/f77cddfa/attachment-0002.bin>