On 15/10/2021 16:11, Kjell Ahlstedt via gtkmm-list wrote:
Glib, atk, pango and gtk4 have dropped Autotools support. They can
only be built with Meson. Can we drop Autotools support for libsigc++,
cairomm, glibmm, atkmm, pangomm, gtkmm, gtkmm-documentation and
libxml++? Would anyone object?
On 12/10/2021 14:17, Kjell Ahlstedt wrote:
. If you just want to pull from gitlab.gnome.org, I suppose you can
use https instead of ssl. In .git/config, change url =
g...@gitlab.gnome.org:/GNOME/gtkmm to url =
https://gitlab.gnome.org/GNOME/gtkmm.git
Thanks Kjell - https is what I'm already
I haven't needed to access gnome/git repos for a while but I tried this
morning and every repo gives me an error about an expired SSL
certificate. For example, here's what I see when trying to pull from
gtkmm:-
Fetching origin
fatal: unable to access
Forgive my ignorance - this'll probably be obvious to some of you...
Suppose I've got a simple character string, like this:-
const char* my_str = "Hello World";
I can assign it to a Glib::ustring very easily:-
Glib::ustring ustr = my_str;
BUT... instead of pointing to a 'normal'
On 17/03/2017 19:20, Daniel Boles wrote:
Dialogs are supposed to be used with a main (non-dialog) window as
parent; running them without a parent is discouraged.
Thanks Daniel and Pavlo. I was getting mixed up with MSVC where
dialog-based main windows are pretty common.
I followed your
On 17/03/2017 17:57, John Emmas wrote:
its CLOSE button doesn't close the dialog. I've tried other buttons
(OK / CANCEL etc) but none of them seems to close the dialog (which I
assumed would be the default action). What am I missing here..?
Sorry, I should have added that this is gtkmm
Suppose I'm writing an app whose purpose is just to test if something
exists and display an appropriate message box:-
#include
int main (int argc, char *argv[])
{
Gtk::Main app ( , );
Glib::ustring message;
if ( the_thing_exists () )
On 20/01/2017 20:27, Damon Register wrote:
I am working on Windows and 2.22 is
the only one that I could get to work.
Thanks everyone for your work on this. I guess it is time for
me to take another shot at moving up.
Hi Damon, I'm also building on Windows (in my case, using MSVC and
On 26/12/2016 08:02, Romain CENDRE wrote:
the company for which I'm working for, is interested in making build
of GTKMM for Windows and I think that's not an easy part.
And I'm asking you for all informations that can help us to do this
job and support this lib for Windows platform.
As
Suppose I've initialized a tm struct somehow:-
#include
struct tm date_and_time;
initialize_date_and_time_somehow (_and_time);
Is there a simple way to turn that data into a Glib::DateTime object? I
assume I could do something like this:-
Glib::DateTime tm (
On 02/08/2016 09:16, Jonathan Wakely wrote:
On 2 August 2016 at 07:03, John Emmas wrote:
but when I mentioned it on a popular programming forum, someone
pointed out that if the above was working, that was purely a case
of luck.
Why is it purely a case of luck? Because
I just updated my compiler to VS2015 after using VS2005 for many years.
I built a small test app and linked it to my DLLs (which are still built
with the older compiler). Ultimately, they'll be getting built with the
new compiler and I was aware of some things to avoid (such as not
On 30/05/2016 19:29, Kjell Ahlstedt wrote:
I didn't notice that the copied code requires C++11. I'll fix it.
Thanks Kjell, it seems to be building okay again this morning.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
Am I right in thinking that 'noexcept' is C++11 only? If so, there's a
problem in the gtkmm-2-24 branch at line 151 in 'gdk/src/types.hg':-
~ScopedPtr() noexcept { g_free(ptr_); }
I realise that gtkmm master now requires C++11 - but IIRC the 2-24
branch is supposed to be buildable with
On 22/12/2015 00:36, codekiddy wrote:
Hey guys I solved all the issues and would like to share my findings!!
Recently I made several posts here on gtkmm-list having problems with
GTKMM on Windows with msvc builds, so as if
#define GTKMM_ATKMM_ENABLED is defined during compilation there will
On 19/11/2015 20:16, codekiddy wrote:
John,
Test program can't be more simple then it is:
#include
#include
int main(int argc, char* argv[])
{
using namespace Glib;
using namespace Gtk;
RefPtr app = Application::create( argc, argv, "gtkmm.exe" );
Window win;
app->run(win);
}
Does
On 19 Nov 2015, at 18:51, codekiddy wrote:
>
> Used your suggestion to force include a header with following contents:
>
> #ifndef GTKMM_ATKMM_ENABLED
> #define GTKMM_ATKMM_ENABLED 1
> #endif
>
> I set in Common properties > C\C++ > Advanced > Force Include File > "the
> name of the
On 18/11/2015 21:51, John Emmas wrote:
earlier today someone mentioned that if GTKMM_ATKMM_ENABLED is #defined when
building the Gtkmm DLL, it must also get #defined in anything which uses that
DLL. That makes a lot of sense - because otherwise, certain objects (e.g.
class Widget) will have
On 18/11/2015 08:05, Kjell Ahlstedt wrote:
gtkmmconfig.h is not handled like other header files. It's created
from gtkmmconfig.h.in by ./configure. When you use MSVC, you don't use
configure, right?
That's right in my case. I simply copy 'gtkmmconfig.h.in' to
'gtkmmconfig.h'
Only
On 18/11/2015 12:39, John Emmas wrote:
//Any instantiable class that derives from Interface should also
inherit from Object.
I noticed that Atk::Implmentor does derive from Glib::Interface but it
doesn't inherit from Object. Could that be the problem?
I just discovered something
On 18 Nov 2015, at 19:24, Kjell Ahlstedt wrote:
>
> I don't understand what's the difference between
> Implementor::~Implementor() noexcept { }
> and a compiler-generated destructor.
>
No. In fact, I just tried commenting out the ~Implementor() d'tor (and letting
the compiler generate one)
On 17/11/2015 09:07, Kjell Ahlstedt wrote:
You mentioned in an earlier post that the error you see is a double
deletion of some memory. [...] Therefore I ran the toolbar example
program in the gtkmm tutorial (which allocates some widgets on the
heap) with valgrind. It reported some lost
On 17/11/2015 11:31, John Emmas wrote:
template inline
RefPtr::~RefPtr()
{
if(pCppObject_)
pCppObject_->unreference(); // This could cause pCppObject to
be deleted.
// ^ ^ ^ CRASH HAPPENS HERE
}
and the above seems to get called during this 'destr
On 17/11/2015 15:54, Kjell Ahlstedt wrote:
The question now is: Why is pCppObject_->unreference() called in the
RefPtr destructor when gtkmm,
atkmm and glibmm are built with MSVC? Who sets pCppObject_ to
something != nullptr? Or isn't RefPtr's default constructor executed
when the
Do you build Gtkmm from a command line or from an MSVC project? It's
just that I noticed this at line 7 of gtkmmconfig.h.in:-
#undef GTKMM_ATKMM_ENABLED
So I'd assume that if you're building from a VC project, the above
symbol will always be undef'd (even if your project file #defines
On 04/11/2015 04:11, Jason C. McDonald wrote:
I have used Windows XP 32-bit, Windows 7 32-bit, and Windows 7 64-bit.
I have tried MSYS, MSYS2, MinGW, TDM-GCC (Code::Blocks on both). I
have built gtkmm and dependencies from scratch on MSYS following two
different tutorials, and neither
On 01/08/2015 12:13, John Emmas wrote:
On 28/07/2015 19:18, Murray Cumming wrote:
Thanks. I have now created the pangomm-2-36 branch
https://git.gnome.org/browse/pangomm/log/?h=pangomm-2-36
Seems to be working fine. Thanks.
Hmmm... it looks like cairomm has just gone the same way (i.e
On 28/07/2015 19:18, Murray Cumming wrote:
On Tue, 2015-07-28 at 16:14 +0200, Kjell Ahlstedt wrote:
The pangomm 2.36 branch is called pangomm-2-26. A mistake, isn't it?
Thanks. I have now created the pangomm-2-36 branch instead:
https://git.gnome.org/browse/pangomm/log/?h=pangomm-2-36
I couldn't find a mailing list for pangomm so I'm hoping this will get
through to the devs somehow...
I noticed today that pangomm now requires C++11 - BUT...
The latest stable branch (in git) seems to be languishing at around
2.24. We've come a long way since then and are now up to at least
On 02/07/2015 20:21, Kjell Ahlstedt wrote:
.
I have pushed a commit to gtkmm, branch gtkmm-2-24. That commit adds
some #includes which should make if possible to use newer versions of
gmmproc/glibmm. But glibmm 2.44.0 is probably the newest one that can
be used. Now there's probably no need
On 02/07/2015 08:05, Kjell Ahlstedt wrote:
Where have you found your gtkmm 2.24.4?
http://ftp.gnome.org/pub/GNOME/sources/gtkmm/2.24/gtkmm-2.24.4.tar.xz
contains about 200 header files with #include glibmm.h.
Thanks for all your help with this, Kjell. I'm building from the
gtkmm-2-24
Hi guys, I'm building an app which uses gtkmm ver 2.24. By whatever
route, the app ends up #including 'gdkmm/pixbufanimationiter.h'. Line
187 looks like this:-
bool advance(const Glib::TimeVal current_time);
Unfortunately, MSVC tells me that 'TimeVal' is not a member of 'Glib'.
My
On 01/07/2015 14:28, Kjell Ahlstedt wrote:
Which version do you use? gtkmm 2.24.3? Don't! Use 2.24.2 or 2.24.4.
gtkmm 2.24.3 is the mess that Murray mentions. See
https://bugzilla.gnome.org/show_bug.cgi?id=697835, if you're very
interested.
Hi Kjell,
Currently I'm building 2.24.4.
I can't seem to find a dedicated mailing list for atkmm. Hopefully,
someone here can point me in the right direction if this isn't the place
to post...
Basically, I'm just wondering if there's a new stable branch of atkmm
(in the planning stage). For some reason, I got it into my head that
For whatever reason, my only copy of pkg-config.exe seems to be in a
folder called C:\Program Files\gtkmm\bin. I don't know if that's
normally the case - but at least it explains why I'm asking this
question here. My problem is that if I attempt to run pkg-config on my
system, it will only
On 16/12/2014 09:54, John Emmas wrote:
the following command seemed to make pkg-config look in the right
folder:-
set PKG_CONFIG_PATH=F:\+GTK-SOURCES\gnu-windows\lib\pkgconfig;
But this morning it's simply stopped working again!
I figured it out - it was just a badly worded error
On 30/11/2014 10:20, Kjell Ahlstedt wrote:
I believe it's a Microsoft thing and certainly not a perl problem. I
also found this link:
http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx
Okay, this is starting to make some
On 29 Nov 2014, at 11:15, Kjell Ahlstedt wrote:
Don't let gmmproc write a filename (or perhaps a class name, such as Error,
or a method name, such as get_error()?) between the first and the second
colon on a line. Is that the result of your investigation?
Hi Kjell - as bizarre as it
On 27 Nov 2014, at 14:42, John Emmas wrote:
it'll be tomorrow before I can take a good look at that patch.
Hi Kjell - after some further testing this morning, this problem is turning out
to be an unbelievably stupid issue with MSVC!!! I mentioned this yesterday:-
When I examine my
On 28 Nov 2014, at 12:23, Murray Cumming wrote:
On Fri, 2014-11-28 at 10:33 +, John Emmas wrote:
Is there any way I could experiment with changing that message text -
let's say to this:-
gmmproc: 'error': GIOErrorEnum: Example code discarded.
Or maybe
On 28 Nov 2014, at 13:19, John Emmas wrote:
Kjell mentioned yesterday (and I confirmed this morning) that the word
error: in that message is just an indication that the files being processed
(at that particular time) happened to be error.ccg and error.hg. But
MSVC sees the text error
On 28/11/2014 13:58, Kjell Ahlstedt wrote:
The message is printed by glibmm/tools/pm/DocsParser.pm, line 378-379,
print STDERR gmmproc: $main::source: $obj_name: Example code
discarded.\n
if ($example_removals);
There are other warnings that contain $main::source. If you can tell
what
On 26/11/2014 18:59, John Emmas wrote:
.
Does gmmproc have any kind of return value? I'm just wondering if it
might be returning an error status now, when it wasn't previously?
Anyway, I'm too tired tonight to do any more work on this. It'll have
to wait until I feel a bit fresher
On 27/11/2014 10:23, Kjell Ahlstedt wrote:
On 26/11/2014 18:59, John Emmas wrote:
So I've assumed that the first one doesn't indicate an actual build
error. Is that assumption safe?
Yes, it's a safe assumption. error here just means that the message
was printed while processing error.hg
On 27/11/2014 13:08, Murray Cumming wrote:
Maybe you have a bad doxygen? It's not uncommon for various versions of
doxygen to crash on various things.
Hi Murray,
To the best of my knowledge, doxygen isn't involved in the process. What
I mean by that is that I'm not (consciously) generating
On 27/11/2014 14:24, Kjell Ahlstedt wrote:
The extra comments are inserted by gmmproc. All ,hg that contain
_WRAP_GERROR directives will result in bigger .h files now because of
this patch that I added to the git repository last week:
Firstly, a rider... I'm using my own-built MSVC projects for building
glibmm and giomm (i.e. I don't use the ones supplied by git) - but
having said that, my projects have worked perfectly up until this morning.
After updating from git master this morning I noticed that some new
sources got
On 26/11/2014 14:43, Kjell Ahlstedt wrote:
Those warnings are quite common. They only affect the documentation
that gmmproc generates. gmmproc fails to convert a C function name to
a corresponding C++ method name. It shouldn't make the build fail. I'm
sure you've got similar warnings before,
I'm not sure if this is something new or if I just never noticed it
before but round about line 119 of 'gtkmm/treeviewcolumn.cc' I seem to
have these functions:-
CellRenderer* TreeViewColumn::get_first_cell_renderer()
{
return get_first_cell();
}
const
On 17/11/2014 11:46, John Emmas wrote:
I'm not sure if this is something new or if I just never noticed it
before but round about line 119 of 'gtkmm/treeviewcolumn.cc' I seem to
have these functions:-
CellRenderer* TreeViewColumn::get_first_cell_renderer()
{
return
Hi Marcin - you raised a couple of interesting points here:-
1st point:
On 07/09/2014 20:33, Marcin Kolny wrote:
Could you tell us, what exactly problems have you met with /vd2 flag?
If I add the /vd2 flag to my own program (and rebuild, of course) the
program runs fine but it crashes at
This is the conversation that was previously named:-
[Windows] Trash in sigc::trackable::callback_list_ when class is
derived from Glib::Object
(mostly, a discussion between Marcin Kolny and myself). After a bit of
detective work we eventually concluded that where a programmer derives a
On 03/09/2014 10:17, Marcin Kolny wrote:
Hi,
Recently I've used glibmm on Windows, and I've met very strange
problem. Assume simple class:
class Test : public Glib::Object
{
public:
Test()
{
}
};
When I instantiate this class, I see in debugger, that callback_list_
of this
On 03/09/2014 12:32, Marcin Kolny wrote:
Hi,
I just noticed, that when I create my class INSIDE glibmm project, it
works fine. So that might be some kind of bug in MSVC, but I've to do
deeper investigation.
Do report back if you discover anything. It's quite an intriguing
problem!
John
On 03/09/2014 14:56, Marcin Kolny wrote:
OK, I've got it... That's because vd2 flag - enable it in your
project, or disable and recompile in glibmm project.
Wow, excellent detective work! You're absolutely right!!
BTW - are you building from a command line or using the VC IDE? In my
IDE
On 03/09/2014 15:49, Marcin Kolny wrote:
Ah, I'm sorry, it is also possible in VS2010:
Properties-Configuration Properties-C/C++-Command Line, and you can
find a text field Additional Options, where you can enter your options.
Thanks - that's how I did it. So to summarize... when building
On 08/08/2014 09:08, codekiddy wrote:
.
You said You might also be interested to know that there's an
official Microsoft project that aims to build the GTK stack
I'm guessing you talking about this:
http://hexchat.github.io/gtk-win32/
Can you provide a link to the microsoft project you said?
On 06/08/2014 04:02, codekiddy wrote:
hello, I'm building my own gtk and gtkmm libraries with latest msvc
(VS2013), and the problem is that everything was (painfull)successful
(more or less) until I came to the last package (gtkmm) and got 5
undefined externals :/ and I realy stuck in the end
Hi Murray,
For anyone who might want to track the new 2.40 branch, how will we know
when it gets created? I can see a new tag for 2.40 - but AFAICT the
most recent stable branch is still glibmm-2-38. I'm using the URL:-
git://git.gnome.org/glibmm
Do I need to keep checking occasionally
On 14/04/2014 09:18, Murray Cumming wrote:
I'll create the branches for you now. It's usually not so important to
people. (You should still be using the tarballs for your builds.)
I appreciate that, Murray. It's a great help.
Just FYI I've been building directly from git for quite a long
On 24/03/2014 18:33, Klaus Rudolph wrote:
Hi all,
I simply want to draw a semi circle on a goocanvasmm.
I though about two options:
1) Drawing a line with CAP_ROUND style. But I was not able to only draw one end
with the round cap. :-(
2) Drawing a elipse and hide a half, but how?
Any
Hi guys. This morning I updated glibmm from git and tried rebuilding
'master' (Windows). However, giomm/application.cc fails to compile
because of these missing symbols:-
g_application_add_main_option_entries
g_application_add_option_group
I figured that they must be new
On 11/03/2014 10:40, Krzesimir Nowak wrote:
Make sure you are really on proper branch in glib and that origin is
pointing to GNOME git repository.
Oops, you were right... problem with my glib/git configuration. In
fact, I'd been failing to update glib for weeks but hadn't realised
Hi guys. I'm not sure if the problem lies with glib or with glibmm but
either way, it seems as if the following functions recently got added to
'gio/gapplication.c' :-
g_application_send_notification
g_application_withdraw_notification
Glib builds fine for me (using MSVC).
On 06/02/2014 22:19, Gavin Lambert wrote:
It's in general a very bad idea to mix two different CRTs in the same
process. It's not impossible, and there are times when you can get
away with it, but I doubt very much that doing it with a UI framework
such as GTKMM is one of those.
On 17/01/2014 10:14, Murray Cumming wrote:
gtkmm 2.39/40 wraps glib 2.39/40.
A couple of things... Firstly, was that a typo on gnome-announce the
other day? (i.e. should it say glibmm 2.39/40 wraps glib 2.39/40)?
The email subject says glibmm 2.39.3 so I assume it's just a typo...
Thanks for all the suggestions guys.
It turned out that Msys-Git (on Windows) has its own version of Perl
which was conflicting with Strawberry Perl which I'd also installed. By
re-arranging their order in my system path the Perl problem has now gone
away. Unfortunately, I'm now left with
On 08/12/2013 16:56, John Emmas wrote:
It turned out that Msys-Git (on Windows) has its own version of Perl
which was conflicting with Strawberry Perl which I'd also installed.
By re-arranging their order in my system path the Perl problem has now
gone away. Unfortunately, I'm now left
I'm setting up an MSVC build environment (for glibmm and other
associated libraries) on a new, Windows 8 machine. Previously I've set
up similar build environments for Windows XP and Windows 7. When I come
to build glibmm, MSVC gives me the following error in my pre-build step
(my pre-build
On 04/12/2013 18:16, Kjell Ahlstedt wrote:
No, this disagreement can't cause your crash. It's in a comment. It
probably affects the reference documentation. Probably no icon is
shown in the documentation. GO_FORWARD has a similar disagreement.
Hmmm... that's quite interesting.
On 05/12/2013 08:15, John Emmas wrote:
Hmmm... that's quite interesting. GO_FORWARD exhibits the same crash
as GO_BACK, whereas anything else seems fine (including GO_UP and
GO_DOWN).
I found the bug. It was an uninitialized variable in libgtk+. I've
filed a bugzilla report here
I'm building a gtkmm dialog which uses the following line of code to add
a button (where 'back_button' is of type Gtk::Button*):-
back_button = add_button (Stock::GO_BACK, RESPONSE_NO);
When the specified button is 'Stock::GO_BACK' the program repeatedly
crashes at run time. I've
On 28/11/2013 11:33, John Emmas wrote:
Thanks Kjell, I'm busy with another project today but first thing
tomorrow, I'll step through the destruction process and see if my
function sequence matches yours.
Today I've been looking into the 2nd stage of Kjell's destruction
process, namely
Thanks Kjell, I'm busy with another project today but first thing
tomorrow, I'll step through the destruction process and see if my
function sequence matches yours.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
Hi Kjell, I've taken a very quick look into the first stage that you
described (delete some_adjuster):-
On 28/11/2013 09:54, Kjell Ahlstedt wrote:
This is what shall happen, and what does happen when I run the test:
_delete some_adjuster;_
Gtk::Object::~Object() calls
On 27/11/2013 09:24, Murray Cumming wrote:
Does glib's test suite pass 100% for you? For instance, try make check
in glib.
Actually, that's not an easy question to answer... :-(
As far as the vcproj files are concerned the only two test modules (to
get included in them) are
On 27 Nov 2013, at 09:24, Murray Cumming wrote:
I don't see any quark/object-data tests in glib/tests, and I guess there
should be one, but maybe the existing tests would show some base
problem.
That seems like a good idea and worth pursuing but perhaps I should emphasise
that my
On 25 Nov 2013, at 21:22, Ian Martin wrote:
Hi John,
Hope you don't mind me jumping in. I'm curious why you want to do your own
memory management: Gtk::manage takes all the work out of your hands safely,
and stops you deleting widgets in an inappropriate order
Hi Ian,
No, I don't mind
Hi Kjell,
Many thanks for sending me your versions of those files. The good news
is that with only the exception of some commented sections, your
versions are identical to mine. Both versions exhibit the same
behaviour (and unfortunately, the same problems).
I'm wondering now if I've been
On 23/11/2013 10:23, John Emmas wrote:
It would be very interesting if you could apply those patches and see
if they change the calling order for you (like they did for me).
Hi Kjell, I've just had a new idea (a variation on the above theme).
When you can find some time, could you apply
On 22/11/2013 19:17, Kjell Ahlstedt wrote:
2013-11-22 18:45, John Emmas skrev:
This crashes:-
Gtk::SpinButton some_spin_button;
Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
some_spin_button.set_adjustment (some_adjuster);
That's what I have now once again
Gtk::SpinButton some_spin_button;
Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
some_spin_button.set_adjustment (some_adjuster);
If I include the above lines in any gtkmm app (and build with MSVC) the
app eventually crashes at the stage where 'some_spin_button' is
Hi Kjell - we're back here again... :-(
On 22/11/2013 15:58, Kjell Ahlstedt wrote:
What's going on in your system? I get a feeling that the patches
you've applied to your copy of gtkmm 2.24.4 only hide the symptoms of
a different bug than the one those patches fixed in gtkmm 3.
I must
On 21/11/2013 09:17, Kjell Ahlstedt wrote:
Getting back to
https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00043.html, you
say there, before you applied any patches, that gobject_ is set to 0
in Gtk::Object::disconnect_cpp_wrapper(), and then
Gtk::Widget::on_unrealize() is
On 20/11/2013 08:43, Kjell Ahlstedt wrote:
Calling virtual functions from constructors and destructors is best
avoided. It's not always easy to guess which override will be called.
Agreed Kjell. I just wanted to draw it to your attention that this was
happening. I've done much more
On 09/11/2013 15:05, John Emmas wrote:
On 08/11/2013 14:16, Kjell Ahlstedt wrote:
Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(),
it calls Gtk::Object::disconnect_cpp_wrapper(), which removes
glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_
On 18/11/2013 19:16, John Emmas wrote:
On 18/11/2013 18:32, Kjell Ahlstedt wrote:
Seems quite similar to the problem you described in
https://mail.gnome.org/archives/gtkmm-list/2013-November/msg0.html
Have you got any further with the trouble-shooting after
https://mail.gnome.org/archives
Many thanks for persevering with this Kjell. I'm just about to try
applying the patches that Murray recommended here:-
https://bugzilla.gnome.org/show_bug.cgi?id=605728#c25
and I'll report back if that changes anything. It's good that I keep
getting more and more info and things to try.
On 19/11/2013 16:56, John Emmas wrote:
Many thanks for persevering with this Kjell. I'm just about to try
applying the patches that Murray recommended here:-
https://bugzilla.gnome.org/show_bug.cgi?id=605728#c25
and I'll report back if that changes anything.
Okay... I just finished
I'm trying to debug a program which keeps crashing in
'Gtk::Widget::on_hide()'. Here's what that function looks like:-
void Gtk::Widget::on_hide()
{
BaseClassType *const base = static_castBaseClassType*(
g_type_class_peek_parent(G_OBJECT_GET_CLASS(gobject_)) // Get
the
On 18/11/2013 14:59, Alan Mazer wrote:
The G_OBJECT_GET_CLASS macro is probably dereferencing gobject_, e.g.,
replacing it with gobject_-class or some such...
Perhaps so. That would certainly explain the crash if 'gobject_' was
NULL - but as I try to debug this issue things become even
Many thanks for the suggestions guys. This problem has stumped me for
nearly a fortnight so I do appreciate your help!
On 18/11/2013 18:19, Alan Mazer wrote:
What happens if you provide a destructor (empty of course, but not
inlined) for your derived class?
Actually I did try that earlier
On 08/11/2013 14:16, Kjell Ahlstedt wrote:
Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(),
it calls Gtk::Object::disconnect_cpp_wrapper(), which removes
glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_.
I have run your test case that contains
Grrr there was a typo
On 09/11/2013 15:05, John Emmas wrote:
Which versions of glib, glibmm, gtk+, and gtkmm do you use?
glib= 2.38.02 (git)
glibmm = 2.38.00 (git)
gtk+ = 2.34.23 (git)// --- this should have been 2.24.23
gtkmm = 2.24.4(tarball
While I've been tracking down a gtkmm problem I suddenly noticed
something about gdkmm which I'd never realised before
For building on Windows, gtkmm contains the usual __declspec specifier
in the form of GTKMM_API, which gets defined (as appropriate) in
gtkmmconfig.h. But AFAICT there's
On 07/11/2013 17:39, John Emmas wrote:
On 07/11/2013 16:08, Kjell Ahlstedt wrote:
I've used gdb to see what's happening in the functions that you
mention. The datalist in g_datalist_get_data() contains 2 entries:
-- GQuark 1007, gtk-window-icon-info
-- GQuark 181, glibmm_Glib
of gtkwidget.c:-
On 05/11/2013 10:10, John Emmas wrote:
g_signal_emit (widget, widget_signals[UNREALIZE], 0);
As you can probably imagine, the crash occurs in the handler for
UNREALIZE. Unfortunately the handler is fearsomely convoluted but
eventually it ends up
On 07/11/2013 16:08, Kjell Ahlstedt wrote:
I've used gdb to see what's happening in the functions that you
mention. The datalist in g_datalist_get_data() contains 2 entries:
-- GQuark 1007, gtk-window-icon-info
-- GQuark 181, glibmm_Glib::quark_cpp_wrapper_deleted_
The number of registered
On 05/11/2013 09:31, Murray Cumming wrote:
Does this happen with the official (but old) gtkmm 2.22 (and its
dependencies) binaries? https://wiki.gnome.org/gtkmm/MSWindows
Hi Murray,
I can't be precise about that. A week ago I did try going back to
version 2.22 but it seemed to be too old
Again, just clutching at straws - but does this give us any clue...?
Here's a partial sequence of function calls if I build my app using
gtkmm. Here's the sequence I see after clicking to close my main window:-
gtk_widget_destroy()
g_object_run_dispose()
g_object_run_dispose()
1 - 100 of 149 matches
Mail list logo
