Re: SigC::, sigc::, Build Environment, and Main Event Loop Update from deeply-nested recursive functions.

["Murray Cumming" <murrayc murrayc com>]

[snip]
> 2. SigC::, sigc::, and My 0wn Turgid Build Environent. Actually, I had
> hoped to post the above Event Loop update solution ten days ago, as it
> only took a few hours to implement. Unfortunately, there was another
> more pressing item in my exchange with Murray that I wished to address
> first. This had to do with an (ad)mixture of SigC:: and sigc::
> namespaces in my code, and the resulting confusion that ensued when I
> coded signals. Glade generates code that uses SigC::

That seems unlikely, unless you only have libsigc++ 1.2. But anyway,
problems with glademm code generation are for the glademm-list. It's a
separate project that I don't particularly recommend. Future versions of
Glade will remove the code-generation feature from the Glade application.

[snip]
> But don't Go There: you're needed here at home. Besides, this one too is
> solved: for various reasons far beyond my personal control, my target
> platform is plain vanilla completely un-updated Red Hat Linux 7.3 and,
> due to an inability to find an updated Render package, I had prevented
> myself from doing a complete upgrade of my build environment to
> gtk+/gtkmm-2.4. I was seemingly stuck at glib-2.3.6, glibmm-2.3.8,
> gtk+-2.2.4, and gtkmm-2.2.12.

glibmm-2.3.8 and gtkmm-2.2.12 in no way interact together. If you have
gtkmm-2.0 installed then you also have glibmm 2.2 installed. You will have
massive problems if you try to include and link to both the gtkmm-2.0 and
gtkmm-2.4 APIs (likewise glibmm-2.0 and glibmm-2.4). I'm surprised that
the linker allowed this.

> The first two required libsigc++-2.0.16,
> whilst the latter needed libsigc++-1.2.5. Which is why the old SigC::
> namespace was visible in my build. And I didn't know any better than not
> to use it. But I couldn't get rid of libsigc++-1.2.x unless I could
> upgrade to gtk+-2.4.x/gtkmm-2.4.x, and I couldn't do that unless I had
> updated the Render header files, which I thought were part of the system
> X11/XFree86 package, which I thought I couldn't require my intended
> customers to upgrade, so I thought I was stuck at gtk+/gtkmm-2.2.x.
>
>   Only I thought wrong. About Render I mean. I finally found a suitable
> render-0.8 tarball at a suitably obscure SGI (bless 'em) ftp site,
> upgraded to glib-2.6.6/glibmm-2.6.1, gtk+-2.6.10/gtkmm-2.6.5,
> libglade/libglademm-2.4.2, and glade-2.6.8/glademm-2.6.0, all on stock
> vanilla totally un-upgraded Red Hat Linux 7.3 and without
> libsigc++-1.2.anything. As coded on a closed-course by a "professional"
> systems programmer: don't try these stunts at home...

This sounds like a catastrophy. This is no way to install software. If you
can't easily get the new software onto RedHat 7.3 then use the software
tha that you can easily get onto it.

>   (But if you've read thus far and think you really must, reply to this
> and I'll see if I can post my library build script.)
>
>   The upshot of removing libsigc++1.2.x was that SigC:: namespace became
> invisible outside the Glade-generated code (I still don't know why it is
> visible even there -- possibly something todo with #include
> <sigc++/compatibility.h>:) and I was mercifully forced to convert all my
> own signal stuff to sigc:: after which I found I no longer needed to
> derive my C_RowSignal class from Glib::Object, and those sniveling
> start-up objections from gobject.c magically disappeared.

glademm code generation.

>   The immoral being that on gtkmm-list one can learn something new
>   every day.
>
>   On a *really* bad day, *two* new things...
>
> 3. One of the new things I'd like to learn today is this: the odd
> documentation frustration notwithstanding, in general I've been *very*
> impressed with the overall code quality of Gtk+/Gtkmm. As a pleasant if
> unexpected surprise, in two and a half years of development this archive
> application the only bugs I've been able to positively identify have
> been my
> own. Yeah, I know that gtk+/gtkmm has some some, but I've tried hard (if
> unsuccessfully) to keep my particular application simple so as not to
> exercise them. So I'm personally quite pleased. However, I have a
> partner and colleague who has personal friends at Trolltech, and while
> never having actually coded with Qt, is understandably biased in that
> direction. He inquires whether commercial support is available for
> Gtk+/Gtkmm. It it?

Gladly. See the bottom of this page:
http://www.gtkmm.org/commercial_support.shtml

I'm sure there's a few more people and companies who would like to be on
that list.

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com