2013-10-01 10:38, John Emmas skrev:
Since I posted that originally, I've encountered one or two other
situations where I needed to add either 'glibmm/arrayhandle.h' or
'glibmm/value.h' to a particular .hg file. It's probably for
exactly the same reason that you just described above. Would
On 29/09/2013 17:55, Kjell Ahlstedt wrote:
2013-09-17 09:11, John Emmas skrev:
One thing that's of interest is my patch to 'gdk/src/types.hg'. gtkmm
3 has the following #include already added:-
#include glibmm/value.h
whereas I found that I actually need 3 x extra #includes, like
2013-09-17 09:11, John Emmas skrev:
After some further experimentation yesterday, your suggestion #3 looks
very promising:-
3. Insert the necessary #include directives in the .hg files, as
has been done in gtkmm 3.
I discovered that only a few, very small additions to just two .hg
On 16/09/2013 14:35, Kjell Ahlstedt wrote:
gmmproc is part of glibmm. I don't know if that's optimal, but it has
worked well in most cases. It causes problems here, because you use
gtkmm 2. I suppose you're forced to do that because there is still no
gtkmm 3 (or gtk+ 3) version that runs on
2013-09-15 18:16, John Emmas skrev:
Hello Kjell,
If you cast you mind back a few weeks you'll remember fixing some
auto-generation stuff which hadn't been working properly. I pulled in
your fixes and ran a test build. Everything seemed to be fine. Today
is the first time that I've needed
On 16/09/2013 08:29, Kjell Ahlstedt wrote:
Why can't you use the tarball, and refrain from regenerating the .h
and .cc files? That would be easier for both of us. Ok, I understand
that you won't do that, I just don't know why.
Thanks again Kjell. I'm not averse to using the tarball. It's
2013-09-16 10:03, John Emmas skrev:
On 16/09/2013 08:29, Kjell Ahlstedt wrote:
Why can't you use the tarball, and refrain from regenerating the .h
and .cc files? That would be easier for both of us. Ok, I understand
that you won't do that, I just don't know why.
Thanks again Kjell. I'm
Hello Kjell,
If you cast you mind back a few weeks you'll remember fixing some
auto-generation stuff which hadn't been working properly. I pulled in
your fixes and ran a test build. Everything seemed to be fine. Today is
the first time that I've needed to use the built libraries though
On 26/08/2013 08:19, Kjell Ahlstedt wrote:
You seem to have a mixture of the master and glibmm-2-36 branches.
After I do 'git checkout glibmm-2-36' there is no properties_type
anywhere.
[...]
After 'git checkout master' the string properties_type is found in
class.h, class.cc, interface.cc
2013-08-17 19:58, John Emmas skrev:
On 17/08/2013 08:31, John Emmas wrote:
For those of us who are still building version 2, will you be pushing
your fix to the latest 2.24 branch or should I just apply it locally
as a patch?
Oops - forgive my misunderstanding, Kjell. I assumed this
Hi Kjell, hope you had a nice break! I think I might be able to shed
some light onto this
On 25/08/2013 07:32, Kjell Ahlstedt wrote:
This is really strange. When I look at the latest version of class.h
in the git master branch,
On 25/08/2013 08:53, John Emmas wrote:
In my case I'm having to use glib v2. Therefore I'm building glibmm
from its branch glibmm-2-36, rather than from master. In glibmm-2-36,
it looks like glib/glibmm/class.h doesn't yet have those changes.
Hmmm... this is all a bit strange. Firstly,
On 25/08/2013 11:11, John Emmas wrote:
even if I switch to master and pull the latest code I still don't see
those changes you mentioned in 'glib/glibmm/class.h'. Two things
1) The current version number (for master) is 2.37.5. Is that the
same as yours?
2) In my current working
On 16/08/2013 08:05, Kjell Ahlstedt wrote:
I have fixed the bugs in _WRAP_SIGNAL, git commit
https://git.gnome.org/browse/glibmm/commit/?id=118f894606a1016a15f48a1659ebb29a95f4cdf5.
That version of gmmproc inserts both #ifdef GTKMM_ATKMM_ENABLED and
#ifndef GTKMM_DISABLE_DEPRECATED at the
On 17/08/2013 08:31, John Emmas wrote:
For those of us who are still building version 2, will you be pushing
your fix to the latest 2.24 branch or should I just apply it locally
as a patch?
Oops - forgive my misunderstanding, Kjell. I assumed this morning that
your fix was in gtkmm but
2013-08-14 10:20, John Emmas skrev:
On 13/08/2013 19:07, Kjell Ahlstedt wrote:
*_WRAP_METHOD*
#ifndef has deliberately been moved. New versions of gmmproc puts
both comment and function declaration inside #ifndef/#endif. That's
the right thing to do. If xxx_DISABLE_DEPRECATED is defined when
On 13/08/2013 19:07, Kjell Ahlstedt wrote:
*_WRAP_METHOD*
#ifndef has deliberately been moved. New versions of gmmproc puts both
comment and function declaration inside #ifndef/#endif. That's the
right thing to do. If xxx_DISABLE_DEPRECATED is defined when the
module is built
On 12/08/2013 21:39, John Emmas wrote:
Thanks Kjell. That bug report suggests that Kalev has already produced a new
tarball for 2.24.4 which includes the correct (i.e. older) version of gmmproc.
No, I was mistaken. The tarball doesn't include any version of
gmmproc. Presumably Kalev
2013-08-13 08:01, John Emmas skrev:
On 12/08/2013 21:39, John Emmas wrote:
Thanks Kjell. That bug report suggests that Kalev has already
produced a new tarball for 2.24.4 which includes the correct (i.e.
older) version of gmmproc.
No, I was mistaken. The tarball doesn't include any
On 13/08/2013 08:17, Kjell Ahlstedt wrote:
The change of #include directives (from glibmm.h to glibmm/ustring.h
and sigc++/sigc++.h) was done in the unstable glibmm version 2.31.0.1.
You should use an earlier version, and preferably a stable one, e.g.
2.30.1
Thanks Kjell,
The most
2013-08-13 10:28, John Emmas skrev:
On 13/08/2013 08:17, Kjell Ahlstedt wrote:
The change of #include directives (from glibmm.h to glibmm/ustring.h
and sigc++/sigc++.h) was done in the unstable glibmm version
2.31.0.1. You should use an earlier version, and preferably a stable
one, e.g.
On 13/08/2013 15:34, Kjell Ahlstedt wrote:
There are many glibmm versions in the subdirectories of
http://ftp.gnome.org/pub/GNOME/sources/glibmm/
Yeah, I just picked 2.28.2 because it was stated as being the most
recent stable version. I don't mind trying the others but I can imagine
it
2013-08-13 17:21, John Emmas skrev:
On 13/08/2013 15:34, Kjell Ahlstedt wrote:
In my case I'm building on Windows. My equivalent command for
building gtkmm/gtk/src looks like this:-
perl -IF:/+GTK-SOURCES/gnu-windows/src/MB3Glibmm/tools/pm
I'm building gtkmm on Windows (using MSVC). Rather than building from a
tarball I'm using the git sources (which means me having to build all
the auto-generated stuff, using gmmproc etc). Everything builds pretty
well. I've even built glibmm, atkmm and pangomm the same way. The only
hiccup
It depends on which version of glibmm (and thus gmmproc) you use. The
same bug is mentioned in
https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version
unknown).
https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a different
result with glibmm 2.32.0.
The gtkmm 2.24.4
On 12/08/2013 18:25, Kjell Ahlstedt wrote:
It depends on which version of glibmm (and thus gmmproc) you use. The
same bug is mentioned in
https://bugzilla.gnome.org/show_bug.cgi?id=697835#c16 (glibmm version
unknown).
https://bugzilla.gnome.org/show_bug.cgi?id=697835#c21 shows a
different
You're right, the latest version of glibmm (gmmproc) generates erroneous
code. I thought it was an old version that did that. This is something I
should look into, I think.
Anyway, you will have other problems if you let a new version of gmmproc
generate code for gtkmm 2.24.4. That's what bug
On 12 Aug 2013, at 20:32, Kjell Ahlstedt wrote:
You're right, the latest version of glibmm (gmmproc) generates erroneous
code. I thought it was an old version that did that. This is something I
should look into, I think.
Anyway, you will have other problems if you let a new version of
28 matches
Mail list logo