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
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
27 matches
Mail list logo
