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

[Peter Hildebrandt]

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 at 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.
>
>  > > 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
>
>
>