Re: Shall we keep supporting Autotools?
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? I'm not sure about libxml++, because the underlying C library, libxml2, can't be built with Meson. Admittedly this is a side-issue but as someone who prefers the Visual C++ IDE (and IDE's in general) I've hardly ever used Autotools - but then again I've hardly ever used Meson either. Initially I'd high hopes for Meson because it could (supposedly) generate .vcxproj files. But back in those early days, the generated files were often too limited to be useful. One big problem (back then) was that Meson could only generate 1 x build target - either Debug or Release but not both in the same project. In fact I'm not even sure if it could generate 32-bit and 64-bit targets in the same project. I spend a lot of my time switching between the different targets so it was very frustrating to lose that ability. I'd like to try Meson again but I'm just wondering if that limitation is still present? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: SSL certificate error
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 using. Did you mean that the other way around? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
SSL certificate error
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 'https://gitlab.gnome.org/GNOME/gtkmm/': SSL certificate problem: certificate has expired I'm guessing I need to add / change something here? But what..? Thanks, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
utf8 and Glib::ustring
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' string (simple ASCII characters), let's suppose that 'my_str' was already pointing to a string in utf8 format. Will the same assignment still work - or is there some better way of assigning a utf8 string to a Glib::ustring? Thanks, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Closing a Gtk::MessageDialog
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 advice and rearranged things so that the application will now launch Gtk::MessageDialog as a child dialog (rather than it actually 'being' a Gtk::MessageDialog) and it's now working as expected. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Closing a Gtk::MessageDialog
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 2.24 (rather than 3). John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Closing a Gtk::MessageDialog
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 () )
message = "Yes, it existed";
else
message = "No, it didn't exist";
Gtk::MessageDialog mainWnd (message, false,
Gtk::MESSAGE_INFO, Gtk::BUTTONS_CLOSE);
app.run (mainWnd);
return 0;
}
The above code does display a MessageDialog (with the correct text) but
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..?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: EXTERNAL: ANNOUNCE: gtkmm 3.89.3
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 gtkmm-2-24). You need to be aware that beyond 2.24, gtkmm introduced a dependency on C++11. So if either your compiler (or any of your projects) don't support C++11 you might be better off to stick where you are... John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GTKMM for Windows - Informations request
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 someone who regularly builds gtkmm on Windows I initially found this message a bit confusing. Admittedly, though... I'm still building gtkmm version 2. But when I typed "gtkmm" and "windows" into Google, I soon realised that a lot of the links seem to end up in a page which says "this page has not been created yet". Binary packages (i.e. pre-built libraries) do exist though:- http://www.gtkmm.org/en/download.shtml#Binary So maybe there's been some delay in creating the various information pages?? Anyway Romain - you'll need to consider which compiler you want to use. MSVC and mingw (gcc) are both supported. Maybe someone will correct me here - but from a look at my own installation, VC5, VC8 and VC10 are the only MSVC compilers supported currently (for gtkmm v2). And (I'm guessing here...) the pre-built binary packages are most likely built with gcc. They're probably okay to get you started - but if you're building your app with (say) MSVC10, you should ultimately aim to build your GTK libs with the same compiler. Remember also that you'll need libraries which match your app (64-bit libs for a 64-bit app or 32-bit libs for a 32-bit app). And don't forget that libgtkmm isn't a stand-alone library. It needs other dependencies, such as libglib / libgtk / libsigc++ etc, etc. A guy called Tarnyko is probably one of the most prolific supporters of GTK/GTKMM for Windows. Search in Google for "tarnyko" and "gtk". John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Is there a simple way to turn a tm structure into a Glib::DateTime object ?
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 ( g_date_time_new ( g_time_zone_new (), date_and_time.tm_year, date_and_time.tm_mon , date_and_time.tm_mday, date_and_time.tm_hour , date_and_time.tm_min,date_and_time.tm_sec )); but it all seems a bit convoluted... Have I missed something a lot simpler? Thanks, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Shouldn't Glib::ustring::raw() return const char* ?
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 get_application_name() returns a std::string by value, which tries to copy the VS2005 type using the code from VS2015? On 02/08/2016 09:12, Kjell Ahlstedt wrote: Glib::ustring::raw() and Glib::ustring::operator std::string() return string_. Glib::ustring::c_str() returns string_.c_str(). Glib::ustring::data() returns string_.data(). What more do you want? Or is it the name "raw" that you find misleading? Oops, you're both right. I was getting mixed up and thinking that Glib::get_application name() returns std::string, whereas it doesn't - it returns Glib::ustring. That explains why calling its 'c_str()' function works, while a simple assignment doesn't. Glib::ustring's std::string operator returns it's 'string_' member. In my case, this IS a std:;string - but it's the old type of std::string that was known to VS2005 (which presumably can't be simply copied to the new type that's known to VS2015). Thanks for clearing this up guys, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Shouldn't Glib::ustring::raw() return const char* ?
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
allocating memory in a DLL and trying to release it in the new app
etc). But I didn't anticipate the problem with std::string. Consider
this example:-
void some_func()
{
std::string test = Glib::get_application_name();
}
'test' is a std::string in the format expected by VS2015 - whereas (in
my case) the call to 'get_application_name()' returns a std::string in
the format that was known to VS2005 - so calling that function from my
new app is guaranteed to crash my program. I figured that if I could
obtain the application name in a POD char array, that might help - and I
quickly discovered that this change seemed fix things:-
std::string test = Glib::get_application_name().c_str();
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. Then
something occurred to me...
Wouldn't it make more sense if 'Glib::ustring::raw()' returned 'const
char*' rather than returning 'const std::string'? Or to put it another
way... shouldn't 'Glib::ustring::raw()' return 'string_.cstr()' instead
of just returning 'string_'?
Or is there some other function that'll return the raw (POD type) data?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: 'noexcept' and 'nullptr' in gtkmm-2-24
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 https://mail.gnome.org/mailman/listinfo/gtkmm-list
'noexcept' and 'nullptr' in gtkmm-2-24
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 earlier compilers. 'nullptr' is
also causing problems a couple of lines earlier, at line 149:-
ScopedPtr() : ptr_(nullptr) {}
Just flagging them up. They should be pretty simple to fix. Regards,
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Why this code doesn't work?
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 be a runtime crash and destruction problem with Glib::RefPtr layout; The problem was that I compiled ATKMM and PANGOMM with /vd2 compiler switch, and that was causing program shutdown crash in Atk::~Implementor and Layout::~Layout I recompiled these 2 without the /vd2 option and with GTKMM_ATKMM_ENABLED 1, now everything works just fine :D Hi codekiddy, This is a total guess - but if we think back to your problems with GTKMM_ATKMM_ENABLED you'll remember we concluded that it needs to be defined identically everywhere. You can't have it defined in some modules but undefined in others. If that happens, the size of Gtk::Widget will be different in different modules (that's what was causing your crash). In fact I suggested using a "Force Include" header file to make sure it'll always be the same everywhere. Maybe there's a similar requirement for /vd2? I noticed that it's defined for all these VC projects:- glibmm giomm atkmm pangomm gdkmm gtkmm but interestingly - not for cairomm. I've no idea if that's a possible explanation. Just flagging it up as a discrepancy. And if /vd2 is enabled for the "mm" libraries, does that mean you must also enable it for your own application? Maybe someone here can tell us. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 'Application::create()' call 'gtk_init()'? If you can see the
resulting Window then I guess it must do but I don't really have time to
check. This line will definitely call it though, if you need to try an
alternative:-
Gtk::Main app (, );
If the above isn't relevant then I'd tend to agree with Phil. You've
probably got some other file somewhere which is undeffing
GTKMM_ATKMM_ENABLED. Most likely you might have multiple copies of
gtkmmconfig.h. It looks like you edited one (to add #define
GTKMM_ATKMM_ENABLED 1) but maybe there are others somewhere which still
say #undef GTKMM_ATKMM_ENABLED ?
Another thing you could try is to modify your ForceInclude file. Instead
of its current contents try it with just this line:-
#include
That will (hopefully) ensure that the same header file gets #included
every time. If you've got more than one copy, it might end up including
the wrong one - but at least it should always be the same one!
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 file".h > > This didn't work > > [...] > > What am I doing wrong here? > Hmm... that's a mystery. Presumably your test project needs to link to both gtkmm and atkmm. What happens if you don't link it to atkmm? You should then see linker errors relating to Atk::Implementor (keep the test project simple - so that it doesn't need anything else from atkmm). John___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 different sizes in different modules. To me, that sounds like a promising explanation for this 'delete' problem. [...] I'll try rebuilding everything, making absolutely sure that GTKMM_ATKMM_ENABLED is #defined in all modules. Fingers crossed, that might solve the problem! Hi Kjell. I just found some time to try the above strategy and guess what... that fixed it !! codekiddy - the secret to making this work is that every module which uses gtkmm MUST know the status of GTKMM_ATKMM_ENABLED. In theory, gtkmmconfig.h should achieve this - but to be absolutely certain (for testing purposes) I made use of MSVC's /FI option (ForceInclude). I used it to force include a specific header file in which I'd #defined GTKMM_ATKMM_ENABLED. This guarantees that _every_ compiled source file will know about that #define. Simply making the change in gtkmmconfig.h should achieve the same thing but it looks like that isn't quite working properly. In fact, I know it isn't working properly - because after I used the /FI option, everything which previously linked to gtkmm now also needed to get linked to atkmm. So the problem is that something somewhere needs to be #including gtkmmconfig.h but is failing to do so. My guess would be 'gtkmm/window.cc' (maybe??) Perhaps even anything that references a Widget? If it forgets to #include widget.h the wrong size might be assumed for 'Widget'. Admittedly I'm guessing here - but it does seem like there's an important #include missing somewhere :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 Gtk::Window contains the Glib::RefPtr accel_group_ which also seems to be involved in a way that I don't understand. I must admit, I'm also baffled by this. In my simple example, the order of destruction seems to be this:- ~Widget ~Container ~Bin ~Window ~Implementor And the crash / hang always happens while destroying Implementor. I did notice this comment at line 53 of 'glibmm/glib/glibmm/interface.cc':- //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? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 else interesting... I don't know if this is
technically valid code but FWIW, even something as simple as this hangs:-
int main (int argc, char *argv[])
{
Atk::Implementor *imp = new Atk::Implementor (NULL);
delete imp; // <-- hangs here !!
return 0;
}
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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) but it didn't make any difference.
I can't find it now but 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 different sizes in
different modules. To me, that sounds like a promising explanation for this
'delete' problem.
I'm busy for a couple of days now - but at the weekend I'll try rebuilding
everything, making absolutely sure that GTKMM_ATKMM_ENABLED is #defined in all
modules. Fingers crossed, that might solve the problem!
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 (leaked) memory. That's
normal with programs that use glib and gtk+. No other memory
problems.And I checked with gdb that Atk::Implementor::~Implementor()
was called several times.
Hi Kjell - presumably you built with gcc, yes..?
I'm actually building with MSVC-8 but for the hell of it, I re-built
Gtkmm this morning - this time making sure that GTKMM_ATKMM_ENABLED was
definitely #defined. Believe it or not I see the same crash as
codekiddy! I used a very simple application:-
int main (int argc, char *argv[])
{
Gtk::Main app (, ); // Calls 'gtk_init()'
Gtk::Window mainWnd;
mainWnd.set_title ("Whatever");
app.run (mainWnd);
return 0;
}
When I attempt to close the app's window it crashes in the d'tor for
Glib::Atk::Implementor. More specifically, it crashes at this code in
'glibmm/glib/glibmm/refptr.h':-
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 'destroy_()' call in
'gtkmm/gtk/gtkmm/window.cc':-
Window::~Window()
{
destroy_();
}
My guess would be that there is indeed some kind of double deletion
happening. I'll spend another hour or so on it and see if I can get any
further...
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 'destroy_()' call in
'gtkmm/gtk/gtkmm/window.cc':-
Window::~Window()
{
destroy_();
}
My guess would be that there is indeed some kind of double deletion
happening. I'll spend another hour or so on it and see if I can get
any further...
I didn't really get much further - except to realise that the crash
doesn't happen in that 'destroy_()' call - it actually happens after the
call (when 'Window' goes out of scope). So my gut feeling is that this
probably isn't a double deletion. Maybe 'pCppObject_->unreference()' is
getting called for an object that's already gone out of scope? Is that
even possible..?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 Gtk::Window is created?
RefPtr is proving tricky to debug into (maybe because it's a template -
and inline?) However while trying it, I discovered something slightly
more worrying. Even this fails when GTKMM_ATKMM_ENABLED is #defined:-
int main (int argc, char *argv[])
{
Gtk::Main *app = new Gtk::Main (, );
Gtk::Window *mainWnd = new Gtk::Window;
delete mainWnd; // <-- hangs here !!
delete app;
return 0;
}
codekiddy - can you try the above example and let us know if you also
see a hang at that line? Tomorrow I'll try rebuilding (this time with
GTKMM_ATKMM_ENABLED #undef'd) just to confirm that it doesn't then fail.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: compiling gtkmm with atkmm support fails in implementor.cc
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 it). I just checked here and it does seem to be undef'd for me (even though it's #defined in my project's preprocessor definitions!!) Just wondering how it's getting #defined at your end? Presumably you're building from a command line? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Compiling on Windows...At ALL
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 worked. I installed them on MSYS2 using the official method, and then manually built the entire program, only to get a 0xc07b error when I tried to run the executable. It looks like you're trying to build with versions of gcc. If you're able to use MSVC there's a complete build stack available here:- https://github.com/hexchat/gtk-win32/blob/master/README.md Admittedly, it only builds Gtk-2 (not Gtk-3) but it should get the vast majority of dependencies built (so you'd only need to figure out Gtk-3 for yourself). According to that web site it even comes with a PowerShell script that will download all the sources for you, apply any necessary patches and then run the build. It sounds like all you'd need to do is install the various build tools (Visual Studio / CMake / Msys2 etc) then make yourself a cup of coffee! There's a pre-built bundle that you can install - or you can run the PowerShell script and built it all from source. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Building from git (without C++ 11)
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. it now also requires C++11). Would it be possible to do the same thing for cairomm? i.e. create a new branch (1.10?) as the last branch which DOESN'T require C++11? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Building from git (without C++ 11)
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 Seems to be working fine. Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Building from git (without C++ 11)
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 2.34 (possibly 2.36?) For those of us still using older compilers, would it be possible for the devs to create a new branch? One which corresponds to the last version which DIDN'T need C++11? (i.e. a 2.36 branch, or whatever). It's just that for people in the same boat as me, building from git master won't be feasible any more - but it'd be useful to be able to track any future changes / fixes if any get applied to 2.36. Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Missing #include from pixbufanimationiter.h ?
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 for you to use an older glibmm. That's great work Kjell, thanks! Just a heads-up... when building gtkmm (2.24) I see this error from gmmproc (it's probably always been there but I just never noticed it before):- entrycompletion.hg:221: End of gmmproc directive within a quoted string. The relevant line looks like this:- _WRAP_PROPERTY(text_column, int) Is there maybe a missing end-quote after text_column ?? I spotted the problem while building my gtkmm-2-24 branch. It seems to be okay in master. Regards, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Missing #include from pixbufanimationiter.h ?
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 branch in git. If you generate .h files yourself [...] you must use an old version of gmmproc (glibmm), 2.31.0 or earlier. That could possibly be the problem. My version of glibmm is around 2.44.x - BUT I'm pretty sure I've had to settle on this version of gmmproc simply because it causes the fewest problems. I found a thread from last year (which turned out to be an issue with gmmproc):- https://mail.gnome.org/archives/gtkmm-list/2014-November/msg00020.html and this one from even earlier (also an issue with gmmproc):- https://mail.gnome.org/archives/gtkmm-list/2013-August/msg00098.html Having said all that... I'll willingly try the older version. Would you happen to have a link to it? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Missing #include from pixbufanimationiter.h ?
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 guess is that 'pixbufanimationiter.h' should be #including glibmm/timeval.h (which it doesn't). I can fix the problem locally but ideally I guess this needs to get fixed upstream? Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Missing #include from pixbufanimationiter.h ?
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. Code for gtkmm 2 must be generated with an old version of gmmproc (i.e. glibmm) that includes glibmm.h in all generated header files. Gtkmm 2.24.3 was generated with a newer gmmproc, which does not include glibmm.h. Interesting... AFAICT all generated source files (.cc files) seem to be #including glibmm.h - but the only header files which include it are:- gtk/gtkmm.h gtk/gtkmm/stockid.h Needless to say, 'gdkmm/pixbufanimationiter.h' doesn't #include either of them. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
atkmm (new branch)
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 an 'atkmm-2-24' branch was due sometime soon (and FWIW another new stable branch for cairomm). I haven't the faintest idea where I got that information. Does anyone know anything about them - or did I just dream the whole thing? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
PKG_CONFIG_PATH on Windows
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 find .pc files if they happen to be in the following folder:- C:\Program Files\gtkmm\lib\pkgconfig but on my system, my .pc files are almost all on the drive that I use for building (F:). Yesterday, I discovered an environment variable called PKG_CONFIG_PATH. I needed to experiment a bit - but eventually, 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! Issuing the above command does stop it from looking on my C: drive - but it doesn't find my .pc files any more, even though that path is correct (including the '+' sign). I've tried with and without the semicolon on the end. I've tried using forward slashes instead of back slashes and I've also tried enclosing the path in quote marks - but nothing seems to work. Maybe something more is needed, apart from just setting that env var. Is there another step that I need to know about?? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: PKG_CONFIG_PATH on Windows
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 message. I was seeing a message like this:- Checking for 'glibmm-2.4' 2.32.0 : not found which made me assume that glibmm-2.4.pc wasn't getting found. But it was... one of its dependencies wasn't getting found! John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 sense now. Here's the text, as output by DocsParser.pm:- gmmproc: error: GIOErrorEnum: Example code discarded. And here's the format of a typical MSVC error message, as output by the compiler:- path to the source file: error some error number: brief error description: more detail. Notice that both examples have precisely the same format! In particular, they both contain 3 colons and the text string error (among some other text) is in between the 1st and 2nd colons. That would definitely explain why MSVC is mis-interpreting the DocsParser output as being an error! If it's really impossible to turn off the error message awareness of Visual Studio, I'll change gmmproc for you. But first please check it really**is impossible. Knowing the above, even if it was possible to turn the awareness off, my guess is that all such error messages would then get ignored - even genuine errors. It's pretty amazing that something like this has never cropped up before! I think that changing from colons to commas is definitely the safest solution here. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 might seem, yes. Isn't there a way to inform MSVC that it shall not try to interpret the output from gmmproc? I found this link: http://msdn.microsoft.com/en-us/library/ms171484.aspx. I don't know if it's relevant. To be absolutely honest, I'm not convinced that this is MSVC's problem. If the IDE was simply looking for the word error, okay - that I could understand. But why would it look for some text including error that was (somewhere in between) two colons? That just doesn't sound like a Microsoft thing to me. I wonder if there's a problem with perl maybe? I followed the link that you provided. The article is slightly misleading because 'Tasks' are a feature of MSBuild, rather than Visual Studio. MSBuild and VS are related to each other but they're not the same thing so that suggestion wouldn't help in this case. If we have to change gmmproc, I think I prefer gmmproc, error.h, GIOErrorEnum: Example code discarded. in this case. There are several other print directives in gmmproc that are potentially problematic. I tried with commas, rather than colons and that works fine. Hope that helps, John___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 build log, the only instance of the word error (which
isn't part of a function name) is this line:-
gmmproc: error: GIOErrorEnum: Example code discarded.
Basically, I'm processing 125 x hg / ccg pairs as a pre-build step. After the
recent changes you mentioned yesterday ('Output.pm' and 'gerror.m4') I'm now
seeing the above line while the error pair is getting processed (keep in mind
that MSVC routinely captures the output text from any pre-build steps).
What seems to be happening is that it's noticing the word error: in that
captured text - and assuming that one of the pre-build steps failed.! If I
temporarily rename error.hg and error.ccg to something else (then process the
renamed files instead) the problem goes away. But that's not a viable solution
of course!
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 to this:-
gmmproc: (source_module='error'): GIOErrorEnum: Example code discarded.
Experimenting with that text output will probably be the only solution, I
think. Thanks.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 to this:- gmmproc: (source_module='error'): GIOErrorEnum: Example code discarded. It's not really an error. Maybe we can call it a warning or just a note. Hi Murray, 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: and wrongly assumes that an error occurred :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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: and wrongly assumes that an error occurred :-( Hmmm... in fact, maybe we could just print the full file name - in this case:- gmmproc: error.ccg: GIOErrorEnum: Example code discarded. That would hopefully solve it? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 suits MSVC, I can modify them. I think the word /error /in the message can confuse human readers as well as MSVC. I'd prefer error.hg|ccg or error.hg or something like that. The .hg file is more important than the .ccg file here. Phew - this has had me tearing my hair out for the whole afternoon! Up to now, the output text from those lines looked something like this:- gmmproc: error: GIOErrorEnum: Example code discarded. Basically what I found was that if the text error appears anywhere between the 1st and 2nd colon, MSVC assumes that an error occurred. It makes no difference if those characters are on their own or as part of some other string. So all these variations will get regarded as an error:- print STDERR gmmproc: error: $obj_name: Example code discarded.\n; print STDERR gmmproc: something_with_error_in_it: $obj_name: Example code discarded.\n; print STDERR gmmproc: \no error detected\: any text here: Example code discarded.\n; I also tried printing to STDOUT (in the hope that the word error on STDOUT mightn't get interpreted as an error - but no such luck :-( In the end, I found that the only real solution is to remove that first colon (after 'gmmproc'). I experimented with a few variations and my favourite was probably this one:- print STDERR gmmproc ($main::source.hg) - $obj_name: Example code discarded.\n if ($example_removals); The resulting text looks like this:- gmmproc (error.hg) - GIOErrorEnum: Example code discarded. Note that there's only one colon! To my eyes, that looks the most pleasing - but of course, it no longer matches the other printouts which have multiple colons - so (for neatness) they'd probably all need to get adjusted. Kjell - if you have any other preferences that you'd like me to try, just list them in an email and I'll try them over the weekend. Thanks again, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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, tomorrow! Well.. even after some more tests this morning, I'm still as baffled as ever! When I examine my build log, the only instance of the word error (which isn't part of a function name) is this line:- gmmproc: error: GIOErrorEnum: Example code discarded. I don't see that line in the previous version (which builds okay). But does that indicate a genuine error? Up to now, I've assumed it doesn't - because, in both builds, I do see similar looking lines, such as:- gmmproc: enums: GIOErrorEnum: Example code discarded. gmmproc: file: g_file_get_uri_scheme: Example code discarded. So I've assumed that the first one doesn't indicate an actual build error. Is that assumption safe? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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.
Hi Kjell (and first of all, apologies for this being long-winded).
You're not going to believe this - it must surely be the world's biggest
irony - but processing error.hg is somehow producing an error now!!
I mentioned yesterday how the following 3 files had increased (in their
generated size) since my last build:-
gio/giomm/resource.cc
gio/giomm/resource.h
gio/giomm/error.h
I can understand the first two (because resource.ccg and resource.hg
have also increased in size). But error.hg is exactly the same as it
was two weeks ago. So what's making error.h so much bigger..? Up until
a fortnight ago, line 51 of the generated 'error'h' looked like this:-
class Error : public Glib::Error
{
public:
enum Code
{
// a bunch of enums
};
// remaining generated code
};
But since yesterday, that same code section now looks like this:-
class Error : public Glib::Error
{
public:
/** @var Code FAILED
* Generic error condition for when an operation fails and
no more specific IOErrorEnum value is defined.
*
* @var Code NOT_FOUND
* File not found.
*
* @var Code EXISTS
* File already exists.
*
* @var Code IS_DIRECTORY
* File is a directory.
*
* @var Code NOT_DIRECTORY
* File is not a directory.
*
// and a whole bunch of similar comments
*/
enum Code
{
// the same enums as before
};
// remaining generated code
};
Strictly speaking, these are all just extra comments - but somehow, they
seem to have introduced an error condition while processing 'error.hg'.
Does that help explain anything? How can an unchanged input file be
producing different output?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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 any documentation files. Or are you saying that it'll be doxygen that's inserting all those extra comments all of a sudden? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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:
https://git.gnome.org/browse/glibmm/commit/?id=491b05f2a8e503109400e692aee0f5f7da788284
I'm surprised that those comments can make the build fail. They look
like perfectly normal comments when I generate error.h on my Ubuntu
14.10 system.
I agree Kjell. Not only do the comments look normal but the generated
files ('error.cc' and 'error.h') compile without any problems. It's the
previous stage of generating them which seems to be going wrong. All
tolled I have a list of around 125 x ccg/hg pairs which I process. If I
just take that one pair out of the list, everything builds normally
again (except that ultimately, 'error.cc' ends up as a missing file, of
course!)
Sadly, I need to take my sister for a hospital appointment this
afternoon so it'll be tomorrow before I can take a good look at that
patch. It looks like only 2 files were affected though - so I might try
reverting them temporarily and see if that changes anything. Thanks
Kjell and Murray for your help with this.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
MSVC build problems after updating from git
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 added to glibmm (namely, 'glib/src/binding.ccg' and its header file, 'binding.hg'). I added them to my project and glibmm built perfectly (i.e. my project converts them into the corresponding cc and h files). However, when the build then moved to giomm I suddenly see a lot of errors like this (which I've never seen before) and the build fails:- DocsParser.pm:lookup_object_of_method(): Warning: GtkDefs::lookup_object() failed for object name=GNotification, function name=g_notification_set_priority This may be a missing define-object in a *.defs file. There are probably half a dozen similar errors (where 'function name' is 'g_resources_register' / 'g_settings_schema_source_lookup' or whatever). I've never seen these errors before. Can anyone suggest what might be causing them? A new script that I need to run, maybe?? FWIW all the named 'function names' can be found in 'gio/src/gio_methods.defs') - except for the very last one which is 'g_settings_schema_key_range_check' (that one isn't found in any of my .defs files). Does that shed any light on the problem? Thanks, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: MSVC build problems after updating from git
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, just you haven't noticed them when the build succeeded. Hi Kjell and thanks for the prompt reply. Firstly, you're right about those messages. My last update was about a fortnight ago (Nov 11th) and by a stroke of luck I backed it up. So I restored my old backup and ran a build (which worked). I only see 4 of those messages for giomm - but they do include the one I thought might be problematic (g_settings_schema_key_range_check). So I think you're right about that just being coincidental. You should probably search for the reason for the build failure somewhere else. Did any compilation start? Did you get compilation errors? No - in fact it fails exactly at the point where the compilation would normally begin. But there's no obvious reason. All the ccg and hg files got converted (correctly AFAICT). And I can compile the generated cc files (manually) and link them manually. It just won't flow from the pre-compile step into the compile stage any more. I decided to examine the generated cc and h files for giomm. 'resource.cc', 'resource.h' and 'error.h' are all significantly bigger than a fortnight ago but they all compile okay (so I don't think they're causing any problem) and everything else looks the same! 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, tomorrow! John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
TreeViewColumn::get_first_cell_renderer()
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 CellRenderer* TreeViewColumn::get_first_cell_renderer() const
{
return get_first_cell_renderer();
}
I assume the intention was that the 2nd function would call the 1st one
but MSVC warns me that the 2nd function will just call itself
recursively until the stack overflows. Any thoughts anyone?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: TreeViewColumn::get_first_cell_renderer()
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 get_first_cell();
}
const CellRenderer* TreeViewColumn::get_first_cell_renderer() const
{
return get_first_cell_renderer();
}
I assume the intention was that the 2nd function would call the 1st
one but MSVC warns me that the 2nd function will just call itself
recursively until the stack overflows. Any thoughts anyone?
Apologies - I should have added that this is in git (branch
'gtkmm-2-24'). 'master' (and presumably gtkmm-3-xx?) don't seem to have
the above code.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [MSVC] - Compiler option /vd2
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 shutdown. The crash occurs at this
code in 'libsigc++2/sigc++/signal_base.h'
struct SIGC_API signal_impl
{
// some stuff
inline void unreference()
{ if (!(--ref_count_)) delete this; } // --- CRASH OCCURS
HERE !!
// some stuff
};
I'm guessing there's some kind of problem with the 'this' pointer. FWIW
it makes no difference if I rebuild libsigc++ after adding the /vd2
flag. The only way I can avoid the crash is to NOT add /vd2, either to
libsigc++ or to my own program code.
2nd point:
On 07/09/2014 20:33, Martin Kolny wrote:
if you really would like to remove this flag, you have to know, that
you can't use dynamic_cast operator in your consturctors in that case.
(I don't know whether it's used somewhere in *mm projects or sigc++,
you have to check it).
What's interesting about this is the example code that you supplied
originally. AFAICT there wasn't any dynamic_cast operator getting used
(either in your own c'tor - or Glib::Object's c'tor - or
Glib::ObjectBases's c'tor - or anywhere in libsigc++). And yet the
constructed object was clearly not getting initialized properly.
So I'm wondering if it was just a happy accident that /vd2 fixed your
original problem (since that wasn't an example of the kind of problem
it's intended to fix).
Sadly, I'm still very mystified about what's going on here... :-(
One thing of note though class Glib::ObjectBase is derived from
sigc::trackable - but sigc::trackable seems to have a non-virtual
d'tor. I suppose that might be a factor in the crash that I'm seeing.
I should probably look a bit deeper into this when I can find some time.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
[MSVC] - Compiler option /vd2
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
class from Glib::Object (when building with MSVC) it's necessary to set
the compiler flag /vd2 during compilation. Marcin gave this simple
example:-
class Test : public Glib::Object
{
public:
Test()
{
}
};
When instantiating the above class, we could see that the member
variable 'callback_list_' wasn't getting initialised correctly with most
versions of MSVC. Adding the flag '/vd2' fixed the problem. I checked
the higher level libraries (atkmm / gdkmm / pangomm / gtkmm) and
discovered that all except for cairomm do indeed have this flag set
during compilation. So it seemed reasonable to apply it to my own
programs (wherever they might declare objects derived from
Glib::Object). It certainly seemed to do the trick for the above example.
However... I'm noticing that for more complex programs, the 'vd2' flag
tends to cause strange runtime crashes - especially so in libsigc++
(remember that the variable 'callback_list_' is of type
'sigc::trackable'). Currently I'm not building libsigc++ with the
'/vd2' flag enabled. Maybe I should be?? Is there any official advice
regarding this for MSVC devs? At the moment, adding that flag seems to
have caused me a lot more problems than it solves... :-(
Thanks, John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [Windows] Trash in sigc::trackable::callback_list_ when class is derived from Glib::Object
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 object is not null (exactly, 0xfffc), but should be null.
It disallows me to use e.g. sigc::mem_fun.
I saw in trackable constructor, that this field is set to zero, but
when I used debugger, and step by step through code, I noticed, that
callback_list_ changes at the beginning of Glib::Object constructor.
Hi Marcin. I don't have any explanation but I can confirm that the same
thing happens if I build your test sample with MSVC 8. In fact AFAICT
it happens with any glibmm object that's derived from ObjectBase. For
example, Glib::Interface and Gio::Icon both exhibit the same behaviour.
However, if I derive my own classes from Glib::ObjectBase, they show
'callback_list_' as being zero (immediately after construction).
Unfortunately I'm not familiar enough with glibmm to know if what we're
seeing is indicative of a problem (e.g. should you have called some
initialization function before using GObject??) Maybe sigc++ needs some
initialization - or even glibmm itself?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [Windows] Trash in sigc::trackable::callback_list_ when class is derived from Glib::Object
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 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [Windows] Trash in sigc::trackable::callback_list_ when class is derived from Glib::Object
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 project properties I couldn't find anything that would toggle that flag - although it worked just fine if I added the flag manually. I'm just wondering if there's a way of setting it in my IDE compiler properties? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: [Windows] Trash in sigc::trackable::callback_list_ when class is derived from Glib::Object
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 with msvc 1) IF - your app uses glibmm / gtkmm etc 2) AND - it defines any class (of its own) that's (ultimately) derived from Glib::Object 3) your app should be built with the compiler switch /vd2 Can any of the main devs confirm if that's an accurate summary? It seems to hold true for the other OO libraries. Except for cairomm, they're all getting built using /vd2 (atkmm / gdkmm / pangomm etc). But I'll bet there are loads of msvc devs out there who never realized it was needed (I certainly didn't!!) Thanks Marcin for tracking this down. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: version information or bundles for visual studio
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? No, it isn't stictly Hexchat - although I know that Microsoft's devs have been in touch with the Hexchat guys and possibly used Hexchat as a starting point. The project itself is called CoApp:- http://coapp.org/index.html From what I can tell it's effectively some kind of apt-get system for Windows (although the apt-get bit is called NuGet). One of its aims is to harmonize the use of GTK on Windows so that (if possible) there'll just be one 'official' library stack (built with MSVC, of course) that everyone can use. It'll probably have different options (for VC10 / 11/ 12 /13 etc) such that debugging is available across all compilers. I've had some limited involvement in the project myself (just discussions really, with Microsoft and the other devs). Progress is a bit slow, from what I can tell... :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: version information or bundles for visual studio
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 like never before. Hi there, I'm quite experienced at building both gtk and gtkmm with MSVC although there are a couple of caveats here... firstly, I'm building the older gtk (gtk2) rather than the newer, gtk3. And secondly, I'm restricted to using an older version of MSVC (i.e. VS2005). However, if you could list the 5 unresolved externals I could possibly let you know what libraries they come from and which library version you'll need. You might also be interested to know that there's an official Microsoft project that aims to build the GTK stack (along with all its dependencies) with the aim of producing an official Microsoft release (basically, Microsoft is getting worried about all us small independent devs releasing our own builds and potentially plunging everybody back to DLL Hell). I'm not sure how advanced the project is but it's been going for at least a year. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ANNOUNCE: glibmm 2.40
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 or will there be another announcement when (and if) a new glibmm-2-40 branch appears? Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ANNOUNCE: glibmm 2.40
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 time now and apart from some initial teething problems (which are always to be expected) it really works quite well. I maintain an ongoing (master) branch and also a stable branch, which our other devs use. Admittedly the 'auto-generated' stuff was tricky to set up - so not something I'd recommend for everyone - but I've got quite a big library of projects now that I build exactly the same way. And in each case of course, I've still got the option of reverting to tarballs if anything goes wrong - but (touch wood) I haven't needed to do that yet. We're only at the early stages of building our main app - but all the supporting libraries seem to work flawlessly! (why do I get the feeling those will be famous last words!!) Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Drawing a semi circle with goocanvasmm
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 hint? Hi Klaus, I've never heard of goocanvasmm and i'm by no means a graphics expert - but a semi-circle is just an arc isn't it? If you can find any functions for drawing an arc you should be able to draw a semi-circle. Regards, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
g_application_add_main_option_entries
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 functions in glib. But when I then updated glib, there've been no updates since Jan 15th. Are the two libraries out of step or should those functions be coming from somewhere else? Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: g_application_add_main_option_entries
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 anything was wrong!! One more thing... I noticed that in both glib and glibmm the version numbers suddenly jumped from about 2.39.04 to 2.39.91. Is that an indication of anything? e.g. is there a new stable release imminent or something like that? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
New functions in gio/gapplication.c
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). However, after I updated glibmm today and tried to build it, I got these compiler errors from 'gio/giomm/application.cc' :- error C3861: g_application_send_notification: identifier not found error C3861: g_application_withdraw_notification: identifier not found As I mentioned, the errors occur when compiling 'application.cc' (from giomm) which attempts to wrap the new functions. At first I assumed that a declaration must be missing from a header file somewhere - but then I noticed some other functions, such as 'g_application_unmark_busy' which looks like it got added maybe a year ago. Similarly, that function gets wrapped by glibmm and, likewise, it doesn't seem to get declared in any header file. So I'm not sure what mechanism is at play here (i.e. why the old functions get found successfully but the newly added ones don't). I'm guessing there must be something else that needs to get added for the new functions to get found but I can't see anything obvious. Does it make sense to anyone here? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm and VS2013
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. *Gavin's advice is spot on, Syed. You should pay great attention to it.* Unless you really understand what you're doing, mixing and matching different CRTs in the same process is an excellent way to build an unreliable app. Given that the VC10 version of gtkmm will probably rely on other components that were also built with VC10, I'd strongly advise you to pick up a cheap version of VC10, rather than continuing to build with VS2013. There's a technique you can use to force VS2013 to use an older CRT but it's probably a bit advanced for a beginner. I'm pretty sure you could obtain VC10 cheap (or free) if you searched hard enough. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ANNOUNCE: glibmm 2.39.3
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... Secondly (whilst on the subject of glibmm) are there any plans to create a stable branch in git (for glibmm 2.38) or has the opportunity for that gone now? Thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: XML/parser.pm
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 an error message returned from M4. When running the gmmproc script I see:- m4 failed with exit code 255 I tried a few searches on Google without much success. Does anyone know what that error means? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: XML/parser.pm
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 with an error message returned from M4. When running the gmmproc script I see:- m4 failed with exit code 255 Hmmm... this seems to be essentially the same problem. Msys-Git offers its own version of M4 too. Again, re-arranging my system path seems to have fixed the problem. :-)) John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
XML/parser.pm
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 step deals with all the auto-generation etc):- Can't locate XML/Parser.pm in @INC (@INC contains: F:\+GTK-SOURCES\gnu-windows\src\MB3Glibmm/tools/pm /usr/lib/perl5/5.8.8/msys /usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/msys /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl etc, etc @INC is presumably an environment variable and the paths listed must be paths that get searched to find a file called 'XML/Parser.pm'. As you can see, they're mostly Linux style paths so they wouldn't be relevant on my Windows 8 machine. I must admit, I have no recollection of needing to set this up for my WinXP and Win7 builds. Furthermore, when I list their environment variables, there isn't one called INC. But it's quite possible that I did need to set something up and I've just forgotten. So to test that theory, I went back to WinXP and temporarily renamed any file called Parser.pm (i.e. so that it wouldn't get found). As you can imagine, that gave me exactly the same build error - except that this time, the paths listed were Windows style paths and they included the path that contains 'XML/Parser.pm'. I'm baffled. Can anyone think what I might need to set up in order to get the correct search paths? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Stock item GO_BACK
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. GO_FORWARD exhibits the same crash as GO_BACK, whereas anything else seems fine (including GO_UP and GO_DOWN). If I can find some time today or tomorrow I'll try to investigate further but if anyone can think of something that's unusual about those two values, please let me know! John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Stock item GO_BACK
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:- https://bugzilla.gnome.org/show_bug.cgi?id=719896 I must admit, I don't understand why it only affected those two button types though ??? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Stock item GO_BACK
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 tried around 20 other values (Stock::OPEN / Stock::CANCEL / Stock::QUIT etc) and all of them worked successfully. It's just that one value which crashes. The only discrepancy I can see is this (in gtkmm/stock.h):- extern GTKMM_API const Gtk::BuiltinStockID GO_BACK; /*! left-to-right languages: @image html gtk-go-back-ltr.png */ compared to this, in gtkstock.h (libgtk):- /** * GTK_STOCK_GO_BACK: * * The Back item. * inlinegraphic fileref=go-previous-ltr.png format=PNG/inlinegraphic * RTL variant * inlinegraphic fileref=go-previous-rtl.png format=PNG/inlinegraphic */ #define GTK_STOCK_GO_BACK gtk-go-back Notice from the comments that gtkmm seems to think the graphic image should be called gtk-go-back-ltr.png whereas gtkmm thinks it's called go-previous-ltr.png. I don't know if I happened to pick 20 good examples but in all the other cases, gtkmm and gtk+ seemed to agree about the name. Could this disagreement be causing my crash? And if so, which name is the right one? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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:- On 28/11/2013 09:54, Kjell Ahlstedt wrote: _delete some_spin_button;_ Gtk::Object::~Object() calls Gtk::Object::_destroy_c_instance(), which calls g_object_unref(). The call to g_object_unref() removes the last reference to GtkSpinButton. When the last reference to GtkSpinButton is removed, it also removes its reference to GtkAdjustment. Both the GtkAdjustment and GtkSpinButton objects are finalized. That finalization process (for the GtkAdjustment) is where the crash occurs. Remember from yesterday that we'd deleted 'some_adjuster'. This deleted the C++ object although it left the underlying 'C' object intact. But when we reach the stage of finalizing the GtkAdjustment, it appears to try to access that deleted C++ object. Here's the sequence (in abbreviated form because it's really very convoluted):- 1) SpinButton::~SpinButton() 2) Object::destroy_() 3) Object::_destroy_c_instance() 4) gtk_spin_button_finalize() - which calls:- gtk_spin_button_set_adjustment (GTK_SPIN_BUTTON (object), NULL); 5) gtk_spin_button_set_adjustment() calls 'g_object_unref (spin_button-adjustment)' 6) g_object_unref() calls 'object-finalize (object)' (where 'object' is the underlying 'C' GtkAdjustment) 7) The above call to 'finalize()' ends up calling g_object_finalize() (still for the underlying 'C' GtkAdjustment) 8) The call to g_object_finalize() calls g_datalist_clear(). Note this line:- data-data[i].destroy (data-data[i].data); 9) The above line ends up calling 'ObjectBase::destroy_notify_callback(void* data)' at this point I'm not entirely sure what kind of object 'data' refers to. However, the above function casts it to ObjectBase* and at that point, MSVC's debugger shows it as a deleted object (0xfeeefeee pattern). From its memory address I'd guess that it's one of the base classes for the Gtk::Adjustment that got deleted a long time ago (though that's just an intuitive guess because the two addresses are always VERY close to each other). Whatever it is, it looks like it got deleted when GtK::Adjustment got deleted. A few lines further down we try to call its 'destroy_notify()' member and that's where the crash occurs. When 'ObjectBase::destroy_notify_callback()' casts the parameter to ObjectBase* is there any way to verify if the pointer is pointing to a valid object? That seems to be the problem AFAICT. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 Gtk::Object::_destroy_c_instance(), which calls g_object_unref(). The call to g_object_unref() does not remove the last reference to GtkAdjustment. Therefore Glib::ObjectBase::destroy_notify_callback_() is not called. Gtk::Object::_destroy_c_instance() calls Gtk::Object::disconnect_cpp_wrapper(), which calls g_object_steal_qdata() and g_object_set_qdata(). Hmmm... I do end up with g_object_steal_data() and g_object_set_data() getting called but the path is somewhat different to the one you described. In fact, Gtk::Object::~Object() hasn't even been reached by the time those functions get called. Here's the sequence that I see... 1) Adjustment::~Adjustment() 2) Object::destroy_() 3) Object::_destroy_c_instance() 4) g_object_unref() (which essentially does nothing) 5) gtk_object_destroy() 6) g_object_run_dispose() 7) gtk_object_dispose() 8) g_object_real_dispose() (which does something to do with quarks) 9) Object::disconnect_cpp_wrapper() (which calls those 'steal_data()' and 'set_data()' functions) 9a) The above call also sets 'gobject_' to NULL but does not free up any memory associated with it. 10) Object::~Object() 11) Object::_destroy_c_instance() (gets called a second time but does nothing now because 'gobject_ == 0' But the conclusion of your statement is essentially correct. This convoluted sequence ensures that Glib::ObjectBase::destroy_notify_callback_() does not get called when deleting 'some_adjuster'. And consequently the line delete this; (in 'ObjectBase::destroy_notify_()') doesn't get reached either. Nevertheless, 'some_adjuster' does get deleted of course (the CRT deletes it). Tomorrow I'll look into what's happening when we delete the Gtk::SpinButton. For example, is it assuming that the above actions somehow prevented the Gtk::Adjustment from getting deleted? John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 'tests/testglib.c' and 'tests/gobject/testgobject.c'. I do build both of them and both modules run without any errors. However There's some evidence that I should be able to build a larger number of tests using the 'makefile.msc' makefile, together with nmake. Unfortunately, when I try to build it, only two of the tests get built. It seems to crash at the third one, giving me this error message:- NMAKE : fatal error U1073: don't know how to make 'base64-test.exe' The two tests which do get built are:- atomic-tests.exe asyncqueue-test.exe When I run them, both tests appear to complete (without hanging or crashing) but they don't give me any text output whatsoever. I don't know whether that means they're passing or failing :-( I'd be quite happy to build the remaining tests if I could get past the 'base64-test' problem. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 impression (albeit a 'gut feeling') is that this problem isn't necessarily connected with quark management. What seems to be happening is this:- When a Gtk::SpinButton has a Gtk::Adjustment attached, a time will eventually come when the SpinButton goes out of scope (i.e. gets destroyed). During the destruction process, something gets done to the attached Adjustment. AFAICT that something doesn't actually destroy the Adjustment - but whatever does get done includes an assumption that the Gtk::Adjustment (if still attached) will still be a valid object. Things go wrong if the Adjustment has already gone out of scope by the time the SpinButton goes out of scope. It's not impossible that there's a connection with quark management but the key to this will be to identify what exactly is getting done to the Adjustment during destruction of the SpinButton. If we could identify what's actually getting done, that would probably get us a lot closer to understanding this problem. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 you contributing at all and I'm very pleased to hear your suggestion about Gtk::Manage. The problem in this case is that it's not in any technical sense my program. This is a complex and very well established Linux program which has been around for a very long time. When the program was at Version 2, I adapted it to be buildable with MSVC while someone else was adapting it for OS-X. At the risk of boasting, the MSVC version is by far the easiest to debug and for that (and other) reasons, it seems to be the most stable of the three options (by a very big margin). I'd estimate that only 3% of user complaints are about the Windows version, So as an exercise, it was well worth doing. However, the program has moved on and is now at Version 3, which I'm trying again to adapt. But Version 3 seems to be riddled with strange problems (all of them, so far, down to gtkmm). For stack based objects in particular, simply changing the order of creation can be enough to crash the program - or stop it from crashing if it was previously crashing. A couple of weeks ago, gtkmm would crash if I derived a class from Gtk::Window or Gtk::Dialog - whereas both classes worked fine if I used them directly, instead of deriving from them. These are extremely serious issues for a modern C++ library. No library should crash simply because I change the creation order of two objects. Nor should it crash if I derive an object from some other object that was previously well behaved. So whilst I appreciate your suggestion about Gtk::Manage (and for all I know, it might even help with the problems) ultimately, it would only be helping to mask some very serious and dangerous bugs. Gtk::Manage might well be helpful as a workaround - but whether it's helpful or not, the underlying problems do need to get fixed. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 fooling myself to think that this SpinButton/Adjuster issue is somehow related to the previous one that got solved. For various reasons it does look a bit similar - but I'm now starting to think that the SpinButton/Adjuster problem is actually a clearly defined issue in its own right. The reason I'm wondering is that this sequence crashes:- Create a SpinButton Create an Adjustment Attach the Adjustment to the SpinButton Delete the Adjustment Delete the SpinButton // Remember that the (deleted) Adjustment is still attached !! OTOH this sequence doesn't crash:- Create a SpinButton Create an Adjustment Attach the Adjustment to the SpinButton Delete the SpinButton // Adjustment hasn't been deleted yet !! Delete the Adjustment But wait a minute... during my tests I discovered some evidence to suggest that this sequence wouldn't crash either:- Create a SpinButton Create an Adjustment Attach the Adjustment to the SpinButton Detach the Adjustment (using 'Gtk::SpinButton::unset_adjustment()') Delete the Adjustment // These two deletions can now Delete the SpinButton // get done (safely) in either order So I guess I'm questioning the safety of deleting a Gtk::SpinButton whilst it has an (invalid) Gtk::Adjustment attached. I don't know enough about the gtkmm spec to know whether that should (or should not) be safe. It certainly isn't safe at present, from what I can tell. Would it help for me to try the same thing with a plain GTK+ app? If it's safe to do with GTK+ I'd assume it should also be safe with gtkmm John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 those two relevant patches to your copy of 2.24 (which I believe is currently unpatched)? Then rebuild and send me your copies of the following four files:- gtk/gtkmm/object.cc gtk/gtkmm/window.cc gtk/gtkmm/widget.cc gtk/gtkmm/widget.h I can then substitute them in my own gtkmm build. Obviously if your versions produce any difference in operation, I can then compare them with my local copies and try to figure out what's going on. That might be the quickest route to understanding what's different. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 tested with 2.24.4 without extra patches. No crash! Hi Kjell, Please don't take that as an indication that the problem must be at my end. The crash is caused by some memory getting deleted and later re-accessed. When MSVC deletes some memory it sets the memory pointer to some junk value (typically 0xfeeefeee). This causes a crash if you carry on using the pointer or if you try to free the memory twice. GCC doesn't do this AFAIK. It will quite happily let you delete memory but then carry on using the pointer (not safely of course but often, it can work). It will NEVER work for an MSVC build. I once again get the suspicion that g_object_steal_qdata() does not work correctly for you. I agree (read on...) I've used gdb, and set breakpoints at Gtk::Object::disconnect_cpp_wrapper() and Glib::ObjectBase::destroy_notify_callback_(). Here's the result: Could you try setting a third breakpoint in Object::destroy_notify_() ? Here's the reason I'm asking In my current code (which now includes the two patches) 'Object::destroy_notify_()' invariably gets called BEFORE any call to 'Object::disconnect_cpp_wrapper()'. The net effect is that these two function calls now NEVER get reached:- g_object_steal_qdata((Gobject*)gobj(), Glib::quark_)); g_object_set_qdata((Gobject*)gobj(), Glib::quark_cpp_wrapper_deleted_, (gpointer)true)); These are the calls you're suspicious about. Clearly, they're still getting reached on your system though it would be interesting to know if that's still true after you apply the patches. My suspicion is either:- a) On your system, 'disconnect_cpp_wrapper()' gets called before 'destroy_notify_()' (the opposite way to me). b) The call order is the same - but there's something different about the functions. Another possibility is that there's a bit more to the patch (an extra bit that I haven't got yet?) I only applied the two patches mentioned in Comment #25:- https://bugzilla.gnome.org/show_bug.cgi?id=605728#c25 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). John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Gtk::SpinButton crash
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 getting destroyed (this is with gtkmm 2.24.4). If the app is run from a command line, Windows outputs a message saying pure virtual function call and then terminates it. A couple of things might be significant:- 1) If I comment out the 3rd line the crash doesn't happen. 2) The crash has a very similar feel to the problem I reported very recently with derived windows and dialogs (i.e. the signs are very much like a C++ wrapper got disconnected from its C object too early). 3) The crash happens in 'gtk_spin_button_finalize()' while executing this line:- gtk_spin_button_set_adjustment (GTK_SPIN_BUTTON (object), NULL); I could provide a more comprehensive example if needed but I thought I'd check first in case this is already a known issue. AFAICT just adding those three lines to any gtkmm app is enough to trigger the problem. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::SpinButton crash
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 admit that's niggling away at me too - but let's worry about that
if we find some actual evidence...
Did you test with or without the patches from bug 605728?
Right at this minute I'm testing with the patches applied. However, I'd
already observed this problem before applying the patches (it was #2 on
a list of two gtkmm issues I keep seeing). In other words, the patches
haven't introduced the problem. It was already there.
Does the order of definition of some_spin_button and some_adjuster
matter? When some_spin_button is defined before some_adjuster,
some_adjuster will be deleted before some_spin_button (at least the
C++ part of it, probably not the underlying GtkAdjustment).
You're definitely onto something there
This crashes:-
Gtk::SpinButton some_spin_button;
Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
some_spin_button.set_adjustment (some_adjuster);
This doesn't:-
Gtk::Adjustment some_adjuster (2, 0, 100, 1, 10, 0);
Gtk::SpinButton some_spin_button;
some_spin_button.set_adjustment (some_adjuster);
This crashes:-
Gtk::SpinButton* some_spin_button = new Gtk::SpinButton;
Gtk::Adjustment* some_adjuster = new Gtk::Adjustment (2, 0,
100, 1, 10, 0);
some_spin_button-set_adjustment (*some_adjuster);
delete some_adjuster;
delete some_spin_button;
This doesn't:-
Gtk::SpinButton* some_spin_button = new Gtk::SpinButton;
Gtk::Adjustment* some_adjuster = new Gtk::Adjustment (2, 0,
100, 1, 10, 0);
some_spin_button-set_adjustment (*some_adjuster);
delete some_spin_button;
delete some_adjuster;
So it seems to be an issue if the adjuster gets destroyed before the
spin button. FWIW the crash occurs in
ObjectBase::destroy_notify_callback_() at the call to
'cppObject-destroy_notify_()'
void ObjectBase::destroy_notify_callback_(void* data)
{
//GLIBMM_LIFECYCLE
// This method is called (indirectly) from g_object_run_dispose().
// Get the C++ instance associated with the C instance:
ObjectBase* cppObject = static_castObjectBase*(data);
//Previously set with g_object_set_qdata_full().
#ifdef GLIBMM_DEBUG_REFCOUNTING
g_warning(ObjectBase::destroy_notify_callback_: cppObject =
%p, gobject_ = %p, gtypename = %s\n,
(void*) cppObject, (void*) cppObject-gobject_,
G_OBJECT_TYPE_NAME(cppObject-gobject_));
#endif
if(cppObject) //This will be 0 if the C++ destructor has
already run.
{
cppObject-destroy_notify_(); //Virtual - it does different
things for GObject and GtkObject.
}
}
When the crash does NOT occur 'cppObject' and 'cppObject.gobject_' are
both valid and Object::destroy_notify_() gets called. When the crash
occurs, 'cppObject' seems to be valid but 'cppObject.gobject_' is
0xfeeefeee. That value usually indicates that the CRT has just freed
some memory associated with that variable. A couple of times I noticed
the crash happening at the line indicated below - but it wasn't 100%
consistent:-
void ObjectBase::destroy_notify_()
{
#ifdef GLIBMM_DEBUG_REFCOUNTING
g_warning(Glib::ObjectBase::destroy_notify_: gobject_ = %p,
(void*) gobject_);
#endif
gobject_ = 0; // Make sure we don't unref it again in the dtor.
delete this; // --- crash was observed here
}
Does any of that help us?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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 called, and the program crashes there, because gobject_ == 0. But when disconnect_cpp_wrapper() sets gobject_ = 0, it also removes Glib::quark_ with g_object_steal_qdata((GObject*)gobj(), Glib::quark_). If that's done, on_unrealize() won't be called. See also https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00045.html. Thanks Kjell, I now understand what you meant when you said that 'steal_qdata' and 'set_qdata' weren't doing what they're supposed to do. It's academic now of course - but before I applied the patch, you must have been right with that assertion. The most puzzling thing is why you are (as far as I know) the only one who have reported crashes with even the shortest possible gtkmm applications. Your problems are so severe that I would expect complaints from most affected users of gtkmm. The only explanation I can think of is that something changed very very recently so most users haven't had time to encounter it yet. The main point is that it does seem likely that those patches are needed in 2.24.4. As it happens I did encounter one snag while applying the patches but rather than describe it here I'll update the bug report later, so it's in the right place. Thanks for all the effort you've put into investigating this problem. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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 testing today and I'm satisfied that applying those patches from yesterday has fixed the crashing issue. Only one thing remains puzzling me... On 19/11/2013 15:48, Kjell Ahlstedt wrote: You mentioned in https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00022.html that you have glibmm_Glib::quark_ in the list of GQuarks, when I have glibmm_Glib::quark_cpp_wrapper_deleted_. It's as if g_object_steal_qdata((GObject*)gobj(), Glib::quark_); g_object_set_qdata((GObject*)gobj(), Glib::quark_cpp_wrapper_deleted_, (gpointer)true); in Gtk::Object::disconnect_cpp_wrapper() don't do what they should. Confusing! What's confusing to me is that your code ever reaches those two lines! When I close my test window (MyDialog), the function Object::destroy_notify_() invariably gets called before Object::disconnect_cpp_wrapper(). Since Object::destroy_notify_() sets 'gobject_' to NULL, I don't see how those lines can ever get reached... ??? Should it be setting 'gobject_ to NULL or is there a bit of the patch missing? Apart from that little quirk it's all much more solid today than it was yesterday. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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_.
Thanks Kjell, I'll test that on my system and see if I also get those
changes (I'm guessing I won't).
Hi Kjell, I got so bogged down with gtkmm problems that I forgot about
comparing my own execution path here - but yes, my code follows the very
same path. FWIW this is the interesting code from 'gtk/gtkmm/object.cc'
(function 'Object::disconnect_cpp_wrapper()')
if(gobj())
{
//Prevent gtk vfuncs and default signal handlers from calling our
instance methods:
g_object_steal_qdata((GObject*)gobj(), Glib::quark_); //It will
no longer be possible to get the C++ instance from the C instance.
//Allow us to prevent generation of a new C++ wrapper during
destruction:
g_object_set_qdata((GObject*)gobj(),
Glib::quark_cpp_wrapper_deleted_, (gpointer)true);
//Prevent C++ instance from using GTK+ object:
gobject_ = 0;
}
Pay particular attention to that last comment. This, I believe, is the
root of the problem. Setting 'gobject_' to zero DOES NOT prevent any
C++ wrapper from attempting to access it. Here's an example from
Gtk::Widget::on_unrealize() which can get called AFTER the call to
Object::disconnect_cpp_wrapper().
void Gtk::Widget::on_unrealize()
{
BaseClassType *const base = static_castBaseClassType*(
g_type_class_peek_parent(G_OBJECT_GET_CLASS(gobject_)) // Get
the parent class of the object class (The original underlying C class).
);
if(base base-unrealize)
(*base-unrealize)(gobj());
}
The commented line consistently crashes (for me) if 'gobject_' is zero.
I gave a very similar example here yesterday:-
https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00034.html
The consensus of replies was that it's NOT safe to call these functions
if gObject_ == NULL. Does that give us any more help in tracking these
issues down??
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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/gtkmm-list/2013-November/msg00024.html ? You're right, it's exactly the same issue. [...] I'll resume my trouble-shooting on that previous issue and report back what I find. Okay, it only took a few minutes to resume my trouble-shooting so I've just added an update about what I found. Getting back to the MyDialog example I supplied yesterday, this is the sequence of function calls when closing MyDialog on my system:- 1) Gtk::Widget::on_hide() // occurs on window closure (BEFORE the call to delete). Therefore 'gobject_' is still valid 2) Window::_destroy_c_instance() // occurs during the call to 'delete' and subsequently calls 3) Object::disconnect_cpp_wrapper() // invalidates 'gobject_' (sets it to NULL) 4) Gtk::Widget::on_unrealize() // crashes because gobject_ == NULL Kjell, if you can find some time today could you try building MyDialog and verify if you see the same sequence? If you do, we'll need to figure out why your gcc build is tolerant of gobject_ being NULL whereas my MSVC build isn't. I feel as if we're getting quite close to a solution though. Many thanks. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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. Sadly this problem is 100% repeatable at my end (and that's regardless of whether I use my own built code or the official tarball sources) so it's quite important that I persist in trying to track it down. As things stand, I can't even run the most trivially simple of gtkmm apps :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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 applying the patches. I've by no means carried out any exhaustive testing but initial signs are that it's fixed the crashing issue. I'll do some more comprehensive testing tomorrow but my first impression is that this stuff is still some way from working elegantly. For example, Gtk::Widget::on_unrealize() is a virtual function. However, if I override it in my derived class (MyDialog, which is derived from Gtk::Dialog), Gtk::Widget::on_unrealize() continues to get called, instead of MyDialog::on_unrealize(). Unfortunately, I can't tell whether that problem already existed or whether the patches are somehow responsible. To be fair though, that's the only issue I've noticed so I think we can definitely regard this as progress! I've had a long and very tiring day today so I'll sign off for tonight - but if anyone can spare a few minutes, maybe they could try over-riding some of those on_xxx() functions (in their own, derived class) and see if the correct version gets called? Many thanks to everyone for their help. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Gtk::Widget::on_hide
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 parent class of the object class (The original underlying C class).
);
if(base base-hide)
(*base-hide)(gobj());
}
Every time the crash occurs, variable 'gobject_' is always NULL.
Although I'm currently trying to figure out why, the above code looks
(to my untrained eye) as though it should be reasonably well behaved
with a NULL gobject_. It looks as if that function should be safe, even
when gobject_ is NULL. Is that a reasonable assessment or just wishful
thinking on my part?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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 more
confusing. Consider this sample program:-
#include gtkmm/main.h
#include gtkmm/dialog.h
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Dialog* mainWnd = new Gtk::Dialog (Hello World,
true, true);
app.run( *mainWnd );
delete mainWnd;
return 0;
}
The above example runs exactly as expected displaying a small, empty
dialog window entitled Hello World. Now consider this extended
example which uses a class derived from Gtk::Dialog:-
#include gtkmm/main.h
#include gtkmm/dialog.h
class MyDialog : public Gtk::Dialog {
public:
MyDialog (const Glib::ustring title, bool modal, bool
use_separator);
};
MyDialog::MyDialog (const Glib::ustring title, bool modal,
bool use_separator)
: Gtk::Dialog (title, modal, use_separator)
{
}
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
MyDialog* mainWnd = new MyDialog (Hello World, true, true);
app.run( *mainWnd );
delete mainWnd; // --- crashes here !!
return 0;
}
When built using MSVC and gtkmm v2.24.2, the extended example
consistently crashes at the line delete mainWnd;. It either crashes
in Gtk::Widget::on_hide() or slightly later, in
Gtk::Widget::on_unrealize(). It's almost as if the C++ window object is
going out of scope before gtkmm has finished its cleanup. Could this be
a threading issue? I haven't created any threads (as you can see) so
unless gtkmm or gtk+ created some I don't see how threading could be the
problem. Or is there something obviously wrong which I'm failing to see??
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::on_hide
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 today. FWIW it doesn't make a difference if I explicitly provide a d'tor :-( 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/gtkmm-list/2013-November/msg00024.html ? Thanks Kjell. You're right, it's exactly the same issue. I've been so wrapped up in it I didn't notice the similarity! It's getting late here (UK time) but first thing tomorrow I'll resume my trouble-shooting on that previous issue and report back what I find. On 18/11/2013 18:03, Kjell Ahlstedt wrote: 1. There is a bug in gtkmm 3.7.12 and 3.8.0 that can make such a call happen. See https://bugzilla.gnome.org/show_bug.cgi?id=605728#c5 That bug was fixed in 3.8.1. 2. Your program calls Gtk::Widget::on_hide(). You should not do that unless you really know what you're doing. My program definitely doesn't call 'on_hide()'. However, that bug report looks interesting. Again, I'll take a closer look tomorrow after a good night's sleep! I notice that Murray asked if your patch should also get applied to 2.4 and you were a bit skeptical - but to be honest Kjell, my experiences seem uncannily similar to that report. Would you mind giving it a bit more thought and decide if the same patch is needed in 2.4? Thanks again for being so patient and helpful.! John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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 /delete mainWnd/. Thanks Kjell, I'll test that on my system and see if I also get those changes (I'm guessing I won't). 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) gtkmm = 2.24.4(tarball) John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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) ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Building gdkmm
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 no equivalent specifier for gdkmm (i.e. there's no GDKMM_API). Does that imply that gdkmm should get built as a static library? Or are all its objects derived from gtkmm objects? (it doesn't look as if they are...) John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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::quark_cpp_wrapper_deleted_ You're right. In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d-len) equals 3 and their values are:- 1st entry: 93// Don't know how to work 2nd entry: 856 // out what these ones are 3rd entry: 3219138047 // I'm assuming this one's garbage. The above values are the values I get when the search string is gtk-selection-handlers. For other search strings I get different values. Hi Kjell, Better late than never but this morning, I realised I could simply print out the relevant strings! Here's what I'm getting for those first two entries:- 1st entry (GQuark 93)= glibmm__Glib::quark_ 2nd entry (GQuark 856) = gtk-window-icon-info Notice that my 2nd string is the same as your 1st string. I wonder if this indicates some kind of alignment problem? John n ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 06/11/2013 10:01, Kjell Ahlstedt wrote:
I've made some tests on a Linux system (Ubuntu 13.10) with gtk+
2.24.22 and gtkmm 2.24.4 from tarballs, glib and glibmm fairly new
versions from git's master branch. I get the same sequence of calls as
you get, but no crash. gtk_widget_dispose() is called after
gtk_widget_unrealize() in both cases. valgrind does not report any
accesses to freed memory.
I'll make some more tests. It would be nice if I could reproduce the
crash or some similar misbehaviour. I wonder if gtk+ behaves
differently on Windows and Linux systems.
Thanks Kjell,
Literally within the last few minutes I've discovered the exact cause of
the crash. Although it showed all the hallmarks of a double deletion
somewhere, I gradually became convinced that it was something more
subtle. Last time, I mentioned that I'd traced the crash as far as line
3065 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 in 'gtk_widget_real_unrealize()' which calls
'gtk_selection_remove_all()'. That seems to remove some things called
'current_retrievals' and 'current_selections' (whatever they are) and it
ends up calling 'gtk_selection_target_list_remove()'. This calls
'g_object_get_data()' which ends up in 'g_datalist_get_data()' which
looks like this:-
gpointer
g_datalist_get_data (GData **datalist,
const gchar *key)
{
gpointer res = NULL;
GData *d;
GDataElt *data, *data_end;
g_return_val_if_fail (datalist != NULL, NULL);
g_datalist_lock (datalist);
d = G_DATALIST_GET_POINTER (datalist);
if (d)
{
data = d-data;
data_end = data + d-len;
while (data data_end)
{
if (strcmp (g_quark_to_string (data-key), key) == 0) //
--- NOTE THIS LINE
{
res = data-data;
break;
}
data++;
}
}
g_datalist_unlock (datalist);
return res;
}
NOTE THE MARKED LINE - 'g_quark_to_string()' gets called and its return
value is compared (in this case) to the string
gtk-selection-handlers*. But 'g_quark_to_string()' can return NULL.
Here's what it looks like:-
const gchar *
g_quark_to_string (GQuark quark)
{
gchar* result = NULL;
gchar **strings;
gint seq_id;
seq_id = g_atomic_int_get (quark_seq_id);
strings = g_atomic_pointer_get (quarks);
if (quark seq_id)
result = strings[quark];
return result;
}
Going back to where it gets called on the final iteration around
the 'while' loop, 'data-key' appears to have an uninitialized value.
This causes 'g_quark_to_string()' to return NULL, which crashes
strcmp(). This is all way above my comfort level with GTK. I've no
idea what data-key represents or whether there's some valid reason why
it might be uninitialized - BUT - on my particular system its value
happens to be a very high number. If it had been zero (or any low
number) this problem would probably go unnoticed.
Hope one of you guys can make sense of this.
John
P.S. If I appear to be slow in responding please forgive me. At my
end, the gtkmm mailing list is very variable. Sometimes postings get
sent to me straight away. Other times they can take a day or more to
reach me!!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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 quarks (seq_id in g_quark_to_string()) is 1059. I would not be surprised if the quark indexes or the total number of quarks differ slightly in a Windows system, or with other versions of gtk+ and/or glib than my versions. You're right. In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d-len) equals 3 and their values are:- 1st entry: 93// Don't know how to work 2nd entry: 856 // out what these ones are 3rd entry: 3219138047 // I'm assuming this one's garbage. The above values are the values I get when the search string is gtk-selection-handlers. For other search strings I get different values. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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 for version 3 of our app (I got loads of unresolved symbols at link time). Having said that, 2.22 would definitely work against my simplified test app but there's a huge amount of work involved for me to get back to 2.22 - and even when I get there I can't debug anything effectively. FWIW, version 2 (of our app) uses a much older version of gtkmm (2.6) which I can confirm does NOT exhibit this problem. After some further digging this morning I discovered that the actual crash seems to occur in GTK+ at line 3605 of gtkwidget.c, namely:- g_signal_emit (widget, widget_signals[UNREALIZE], 0); Does that give you any clue about the possible cause? AFAICT that one statement is the only place where the UNREALIZE signal ever gets emitted. From my observations this morning it DOESN'T appear as if it's getting emitted twice. Therefore perhaps the signal is never getting caught anywhere? Is there some default function that should get called if there's no actual handler? Just clutching at straws here. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
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()
gtk_widget_dispose()
gtk_widget_unrealize() // --- crashes during unrealize
As near as I can make it, here's the same test app written to use plain GTK+
#include gtk/gtk.h
static void destroy (GtkWidget *window, gpointer data)
{
gtk_main_quit ();
}
int main (int argc, char *argv[])
{
GtkWidget *window;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window), Hello World!);
gtk_widget_set_size_request (window, 200, 100);
/* Connect the main window to the destroy signal */
g_signal_connect (G_OBJECT (window), destroy, G_CALLBACK
(destroy), NULL);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
and here's the (subtlely different) sequence of function calls at closure:-
gtk_widget_destroy()
g_object_run_dispose()
gtk_widget_dispose()
gtk_widget_unrealize() // --- doesn't crash this time
gtk_widget_dispose()
Not sure if that helps at all. I'd assume that the sequence should
essentially be the same??
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
