Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
I found a way to fix the issue, and although it doesn't make any sense, it seem to fix it reliably. Unfortunately it has a small side effect that completion popup will have a minimal height that might be taller than necessary when there is only one item in the list. But this cosmetic detail is probably less problematic than a blank popup, right? :)
But I'd like to know if the problem happens to everyone or not, and whether the attached patch fixes the problem for everyone with the issue.
Thanks in advance! Colomban
[1] http://git.geany.org/geany/commit/?id=4d66bd3745eb3759539b116e7784d11d035ebd...
On 14 April 2015 at 07:32, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
XP is no longer supported http://windows.microsoft.com/en-AU/windows/end-support-help so it doesn't matter.
Cheers Lex
I found a way to fix the issue, and although it doesn't make any sense, it seem to fix it reliably. Unfortunately it has a small side effect that completion popup will have a minimal height that might be taller than necessary when there is only one item in the list. But this cosmetic detail is probably less problematic than a blank popup, right? :)
But I'd like to know if the problem happens to everyone or not, and whether the attached patch fixes the problem for everyone with the issue.
Thanks in advance! Colomban
[1] http://git.geany.org/geany/commit/?id=4d66bd3745eb3759539b116e7784d11d035ebd...
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 14.4.2015 г. 02:00, Lex Trotman wrote:
On 14 April 2015 at 07:32, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
XP is no longer supported http://windows.microsoft.com/en-AU/windows/end-support-help so it doesn't matter.
That was heavy. :) Should we declare half of the Linux distributions unsupported, because they never had any official support in the first place? Or discard Windows 8.x, since it's less popular than XP? [1]
[1] http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&am...
-- E-gards: Jimmy
On 14/04/15 18:45, Dimitar Zhekov wrote:
On 14.4.2015 г. 02:00, Lex Trotman wrote:
On 14 April 2015 at 07:32, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
Windows 7 with GTK 2.24.10. Nick has the same problem, we talked about this in http://lists.geany.org/devel/2015-January/009257.html.
Your patch works for me. I personally would not mind the minimal size increase. I completely agree it's better than an empty popup :).
What bothers me more is that for some reason this problem doesn't occur with the cross-compiled nightly binaries. This is what we noticed in the above mentioned thread already, I just re-tested it to get sure. Though I have not yet an idea what could cause the different behaviour by the different builds :(.
XP is no longer supported http://windows.microsoft.com/en-AU/windows/end-support-help so it doesn't matter.
That was heavy. :) Should we declare half of the Linux distributions unsupported, because they never had any official support in the first place? Or discard Windows 8.x, since it's less popular than XP? [1]
Stop this, please. Windows XP is unrelated in this case because this also happens on Windows 7 which is supported.
Regards, Enrico
On 14/04/15 21:54, Enrico Tröger wrote:
On 14/04/15 18:45, Dimitar Zhekov wrote:
On 14.4.2015 г. 02:00, Lex Trotman wrote:
On 14 April 2015 at 07:32, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
Windows 7 with GTK 2.24.10. Nick has the same problem, we talked about this in http://lists.geany.org/devel/2015-January/009257.html.
Your patch works for me. I personally would not mind the minimal size increase. I completely agree it's better than an empty popup :).
What bothers me more is that for some reason this problem doesn't occur with the cross-compiled nightly binaries. This is what we noticed in the above mentioned thread already, I just re-tested it to get sure. Though I have not yet an idea what could cause the different behaviour by the different builds :(.
One more note about the builds: my native Windows build is done by waf. The nightly binaries are cross-compiled but also with Waf.
The used compiler flags for the nightlies can be found at http://nightly.geany.org/win32/build_win32_geany_stderr.log at the top of the output.
Regards, Enrico
On 15 April 2015 at 05:54, Enrico Tröger enrico.troeger@uvena.de wrote:
On 14/04/15 18:45, Dimitar Zhekov wrote:
On 14.4.2015 г. 02:00, Lex Trotman wrote:
On 14 April 2015 at 07:32, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Hi everyone,
I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1].
Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10.
Windows 7 with GTK 2.24.10. Nick has the same problem, we talked about this in http://lists.geany.org/devel/2015-January/009257.html.
Your patch works for me. I personally would not mind the minimal size increase. I completely agree it's better than an empty popup :).
What bothers me more is that for some reason this problem doesn't occur with the cross-compiled nightly binaries. This is what we noticed in the above mentioned thread already, I just re-tested it to get sure. Though I have not yet an idea what could cause the different behaviour by the different builds :(.
XP is no longer supported http://windows.microsoft.com/en-AU/windows/end-support-help so it doesn't matter.
That was heavy. :) Should we declare half of the Linux distributions unsupported, because they never had any official support in the first place? Or discard Windows 8.x, since it's less popular than XP? [1]
Stop this, please. Windows XP is unrelated in this case because this also happens on Windows 7 which is supported.
Was just trying to suggest that @b4n upgrade his VM :)
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Hi,
Le 14/04/2015 21:54, Enrico Tröger a écrit :
[…]
Windows 7 with GTK 2.24.10. Nick has the same problem, we talked about this in http://lists.geany.org/devel/2015-January/009257.html.
Dammit, I knew I saw this recently on a thread, but apparently I can't search my emails :) thanks for the link.
Your patch works for me. I personally would not mind the minimal size increase. I completely agree it's better than an empty popup :).
BTW, I think I found a way to avoid the oversize without subclassing GtkScrolledWindow, which might even be a better fix for the original issue.
What bothers me more is that for some reason this problem doesn't occur with the cross-compiled nightly binaries. This is what we noticed in the above mentioned thread already, I just re-tested it to get sure. Though I have not yet an idea what could cause the different behaviour by the different builds :(.
Interesting. It doesn't surprise me much, as my patch should not fix anything actually -- it doesn't even make sense. I just ended up seeing this change fixed the issue, but I have no clue why it would…
So I guess it's some kind of memory corruption or something, due to either a bug in Geany, Scintilla or GTK, or in mingw itself… I'll try and see if I can track the issue down, but without Valgrind I'm afraid I'll have a hard time…
Anyway, thanks a lot for the infos, it'll probably avoid me heading in the wrong direction :)
Regards, Colomban
Le 15/04/2015 15:27, Colomban Wendling a écrit :
[…]
BTW, I think I found a way to avoid the oversize without subclassing GtkScrolledWindow, which might even be a better fix for the original issue.
Okay, the idea was setting the style property `GtkScrollbar::min-slider-length` to something smaller than the default 21, but a bug in GTK3 makes it virtually impossible (as while the property is set, it is not taken into account the first time, meaning the popup would still be too tall. Of course we don't have the problem on GTK3, but I don't feel like submitting a patch to Scintilla which uses one hack for GTK2 and a completely different one for GTK3.
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way…
On 17/04/15 19:44, Colomban Wendling wrote:
Le 15/04/2015 15:27, Colomban Wendling a écrit :
[…]
BTW, I think I found a way to avoid the oversize without subclassing GtkScrolledWindow, which might even be a better fix for the original issue.
Okay, the idea was setting the style property `GtkScrollbar::min-slider-length` to something smaller than the default 21, but a bug in GTK3 makes it virtually impossible (as while the property is set, it is not taken into account the first time, meaning the popup would still be too tall. Of course we don't have the problem on GTK3, but I don't feel like submitting a patch to Scintilla which uses one hack for GTK2 and a completely different one for GTK3.
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way…
I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
Then I tried gcc 4.8 and gcc 4.6 on Windows, both are failing. I have no idea why. I went through the release notes of all gcc versions between 4.0 and 4.6 looking for promising changes mentioning "align" or "pack" but without success. I'm a bit clueless what really is the issue.
The best guess I have so far is that the GTK 2.24 bundle is compiled with an older gcc, maybe even 3.4, and in later versions some internals have changed which cause ABI breaks. So when we now build with a recent gcc 4.8 our code and link it against the GTK libs which were built with an older gcc, something breaks in the binary alignment of some structs. Though no idea if this is really the case, I'm just guessing here and my knowledge of how compilers work is fairly limited :(.
Furthermore, I tested the SmallerScroller code itself by extracting it from PlatGTK.cxx and put it into src/log.c to replace the stock GtkScrolledWindow there, just to get it sure it is not related to C++ code around in Scintilla. Unfortunately, it didn't work either. Compiled on Windows with gcc-4.8 the log window freezes with SmallerScroller code. The exact same code on Linux works flawlessly.
This might support the above supposition about binary incompatibilities with the GTK libs. But maybe it is something completely different.
So, no idea what to do next.
While the
typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallS...
hack works pretty fine, it is still a crude hack and feels weird to send this to Scintilla upstream.
The other way, to stick with gcc 3.4.x for Windows, seems also quite ridiculous :(.
Regards, Enrico
Le 19/04/2015 15:57, Enrico Tröger a écrit :
On 17/04/15 19:44, Colomban Wendling wrote:
Le 15/04/2015 15:27, Colomban Wendling a écrit : […]
So we'll have to fix the Windows build issue in some way…
I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
Then I tried gcc 4.8 and gcc 4.6 on Windows, both are failing. […]
This might support the above supposition about binary incompatibilities with the GTK libs. But maybe it is something completely different.
Thanks a lot for that in-depth investigation and testing!
But… dammit. If this is really an ABI issue depending on the GCC version, we don't have so many solutions:
1) build Geany using the same GCC as GTK was build;
2) use a GTK that is built with the same GCC as GTK (would mean rebuilding GTK I guess);
3) avoid hitting the ABI issue by not relying on the size of the structure (would mean not subclassing, but then I don't really have a solution);
4) avoid hitting the ABI issue by adding dummy padding (as we don't actually access any data ourselves it doesn't matter).
None of those solutions are really great… 1 is not really practical, and 2 is just a dream. I don't have a good way of doing 3. 4 is a bit ugly but quite easy to implement.
While the
typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallS...
hack works pretty fine, it is still a crude hack and feels weird to send this to Scintilla upstream.
At worse we can always add it to our Scintilla patch…
I'll open an issue on Scintilla and see what Neil thinks, whether he'd accept a hack like that dummy field -- or maybe if he has a better understanding of ABI issues on Windows (but I'm afraid here there really is an ABI incompatibility and we're screwed on that front).
The other way, to stick with gcc 3.4.x for Windows, seems also quite ridiculous :(.
Indeed. And the mingw package for GCC3 even conflicts with the 4.x one :(
Regards, Colomban
Le 19/04/2015 17:31, Colomban Wendling a écrit :
[…]
I'll open an issue on Scintilla and see what Neil thinks, whether he'd accept a hack like that dummy field -- or maybe if he has a better understanding of ABI issues on Windows (but I'm afraid here there really is an ABI incompatibility and we're screwed on that front).
Reported (https://sourceforge.net/p/scintilla/bugs/1726/), accepted (https://sourceforge.net/p/scintilla/code/ci/e9f9c964236a6b740f75d09a8b0ac76e...), and imported (https://github.com/geany/geany/commit/9b98d55defc918c951660f05e9ebdd30e9bfb1...), yay!
Thanks a lot Enrico for helping debugging this!
Cheers, Colomban
On 24/05/15 18:54, Colomban Wendling wrote:
Le 19/04/2015 17:31, Colomban Wendling a écrit :
[…]
I'll open an issue on Scintilla and see what Neil thinks, whether he'd accept a hack like that dummy field -- or maybe if he has a better understanding of ABI issues on Windows (but I'm afraid here there really is an ABI incompatibility and we're screwed on that front).
Reported (https://sourceforge.net/p/scintilla/bugs/1726/), accepted (https://sourceforge.net/p/scintilla/code/ci/e9f9c964236a6b740f75d09a8b0ac76e...), and imported (https://github.com/geany/geany/commit/9b98d55defc918c951660f05e9ebdd30e9bfb1...), yay!
Yay +1!
Thanks a lot Enrico for helping debugging this!
Thank you for getting a working patch and taking the boring part of reporting :).
Regards, Enrico
Am 19.04.2015 um 15:57 schrieb Enrico Tröger:
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way… I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did you try -mms-bitfields or -mno-ms-bitfields with the old one, does that make a difference?
Thanks for your effort!
Best regards
On 19/04/15 17:39, Thomas Martitz wrote:
Am 19.04.2015 um 15:57 schrieb Enrico Tröger:
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way… I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did you try -mms-bitfields or -mno-ms-bitfields with the old one, does that make a difference?
I already tried -mms-bitfields vs. -mno-ms-bitfields but forgot to mention it, sorry. -mno-ms-bitfields is not an option at all because GTK is built with and building Geany without leads to crashes at early startup.
Sizeof is good idea. gcc-4.8: 84 gcc-3.4: 88
So, this supports the theory of an ABI incompatibility?
Regards, Enrico
On 20 April 2015 at 07:43, Enrico Tröger enrico.troeger@uvena.de wrote:
On 19/04/15 17:39, Thomas Martitz wrote:
Am 19.04.2015 um 15:57 schrieb Enrico Tröger:
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way… I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did you try -mms-bitfields or -mno-ms-bitfields with the old one, does that make a difference?
I already tried -mms-bitfields vs. -mno-ms-bitfields but forgot to mention it, sorry. -mno-ms-bitfields is not an option at all because GTK is built with and building Geany without leads to crashes at early startup.
Sizeof is good idea. gcc-4.8: 84 gcc-3.4: 88
So, this supports the theory of an ABI incompatibility?
Just a wild stab, does it work with 64 bit?
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 19/04/15 23:46, Lex Trotman wrote:
On 20 April 2015 at 07:43, Enrico Tröger enrico.troeger@uvena.de wrote:
On 19/04/15 17:39, Thomas Martitz wrote:
Am 19.04.2015 um 15:57 schrieb Enrico Tröger:
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way… I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did you try -mms-bitfields or -mno-ms-bitfields with the old one, does that make a difference?
I already tried -mms-bitfields vs. -mno-ms-bitfields but forgot to mention it, sorry. -mno-ms-bitfields is not an option at all because GTK is built with and building Geany without leads to crashes at early startup.
Sizeof is good idea. gcc-4.8: 84 gcc-3.4: 88
So, this supports the theory of an ABI incompatibility?
Just a wild stab, does it work with 64 bit?
No idea, I never got a 64bit Windows build environment.
Regards, Enrico
On 20 April 2015 at 07:58, Enrico Tröger enrico.troeger@uvena.de wrote:
On 19/04/15 23:46, Lex Trotman wrote:
On 20 April 2015 at 07:43, Enrico Tröger enrico.troeger@uvena.de wrote:
On 19/04/15 17:39, Thomas Martitz wrote:
Am 19.04.2015 um 15:57 schrieb Enrico Tröger:
This said, the reason we need the hack is because of https://bugzilla.gnome.org/show_bug.cgi?id=712220, so if this was fixed we could one day drop the hack. But this would mean depend on a fixed version, which probably won't be acceptable before a decade or so :)
So we'll have to fix the Windows build issue in some way… I gave it another look, however I sort of give up :(.
What I know is, with gcc 3.4 the popups work cleanly and as expected, even when compiled natively on Windows. This is why the nightly builds work, they are built with an old gcc 3.4.
What gives sizeof(GtkScrolledWindow) with the old gcc vs new gcc? Did you try -mms-bitfields or -mno-ms-bitfields with the old one, does that make a difference?
I already tried -mms-bitfields vs. -mno-ms-bitfields but forgot to mention it, sorry. -mno-ms-bitfields is not an option at all because GTK is built with and building Geany without leads to crashes at early startup.
Sizeof is good idea. gcc-4.8: 84 gcc-3.4: 88
So, this supports the theory of an ABI incompatibility?
Just a wild stab, does it work with 64 bit?
No idea, I never got a 64bit Windows build environment.
Ok, never mind, just a thought to try a different ABI
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 14/04/2015 21:54, Enrico Tröger a écrit :
Windows 7 with GTK 2.24.10. Nick has the same problem, we talked about this in http://lists.geany.org/devel/2015-January/009257.html.
I just tested with GTK 2.24.10 on Windows 7, and it does fail the same.
I also tried with GTK 3.6.4 (!) and the problem wasn't present (but there are several sub-optimal details with 3.6.
Your patch works for me. I personally would not mind the minimal size increase. I completely agree it's better than an empty popup :).
What bothers me more is that for some reason this problem doesn't occur with the cross-compiled nightly binaries. This is what we noticed in the above mentioned thread already, I just re-tested it to get sure. Though I have not yet an idea what could cause the different behaviour by the different builds :(.
I just noticed this in the debug messages:
GLib-GObject WARNING : specified instance size for type `SmallScroller' is smaller than the parent type's `GtkScrolledWindow' instance size GLib CRITICAL : g_once_init_leave: assertion `initialization_value != 0' failed GLib-GObject CRITICAL : g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Gtk CRITICAL : gtk_container_set_border_width: assertion `GTK_IS_CONTAINER (container)' failed Gtk CRITICAL : gtk_scrolled_window_set_policy: assertion `GTK_IS_SCROLLED_WINDOW (scrolled_window)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_CONTAINER (container)' failed
which explains at least why it's not working. Why the structure wouldn't have the correct size is more of a mystery, as it's defined as
typedef GtkScrolledWindow SmallScroller; typedef GtkScrolledWindowClass SmallScrollerClass;
…any idea? Of course if I try and see what the sizeof() of all those are, they match (84 for the instances and 444 for the classes FTR).
The same happens if I try and create a structure wrapping them:
typedef struct { GtkScrolledWindow parent; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; } SmallScrollerClass;
However, a workaround is to add a small additional member:
typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallScrollerClass;
I still have no clue what the heck is going on though…
Regards, Colomban
Le 15/04/2015 22:38, Colomban Wendling a écrit :
I just noticed this in the debug messages:
GLib-GObject WARNING : specified instance size for type `SmallScroller' is smaller than the parent type's `GtkScrolledWindow' instance size GLib CRITICAL : g_once_init_leave: assertion `initialization_value != 0' failed GLib-GObject CRITICAL : g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Gtk CRITICAL : gtk_container_set_border_width: assertion `GTK_IS_CONTAINER (container)' failed Gtk CRITICAL : gtk_scrolled_window_set_policy: assertion `GTK_IS_SCROLLED_WINDOW (scrolled_window)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_CONTAINER (container)' failed
[…]
typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallScrollerClass;
I still have no clue what the heck is going on though…
Hum, incidentally GtkScrolledWindow contains bitfields, would it be possible it is a -mms-bitfields-like problem? We really seem to pass -mms-bitfields, but maybe gtkscrolledwindow.c wasn't build with it or something like that?
And actually the extra size is not needed in the Class.
On 15/04/15 23:14, Colomban Wendling wrote:
Le 15/04/2015 22:38, Colomban Wendling a écrit :
I just noticed this in the debug messages:
GLib-GObject WARNING : specified instance size for type `SmallScroller' is smaller than the parent type's `GtkScrolledWindow' instance size GLib CRITICAL : g_once_init_leave: assertion `initialization_value != 0' failed GLib-GObject CRITICAL : g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Gtk CRITICAL : gtk_container_set_border_width: assertion `GTK_IS_CONTAINER (container)' failed Gtk CRITICAL : gtk_scrolled_window_set_policy: assertion `GTK_IS_SCROLLED_WINDOW (scrolled_window)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_CONTAINER (container)' failed
[…]
typedef struct { GtkScrolledWindow parent; int dummy; } SmallScroller; typedef struct { GtkScrolledWindowClass parent; int dummy; } SmallScrollerClass;
I still have no clue what the heck is going on though…
Hum, incidentally GtkScrolledWindow contains bitfields, would it be possible it is a -mms-bitfields-like problem? We really seem to pass -mms-bitfields, but maybe gtkscrolledwindow.c wasn't build with it or something like that?
Wow, great process, Colomban. Reading your previous mail the -mms-bitfields thingy instantly came also to my mind.
I checked the nightly builds as well the builds on my Windows VM, both had -mms-bitfields set, also for PlatGTK.cxx. This opton is set by gtk+-2.0.pc (GTK pkgconfig file), so it's obvious both builds have it set.
But maybe it's related to the compiler version. The cross-compiled nightlies are a bit special in terms of cross-compiling and that they use a quite old mingw-gcc 3.4 while the mingw-gcc on my Windows VM is a more recent 4.8. I found http://gcc.gnu.org/gcc-4.7/changes.html where a short note says: Windows mingw targets are using the -mms-bitfields option by default.
I would say this is probably not relevant because we compile our code with -mms-bitfields in all cases because GTK pulls it in. But IANAC (I am not a compiler :D).
Does anyone here has by accident a Windows system with a mingw-gcc < 4.7?
I'll try to further debug this on the weekend if I find time.
Regards, Enrico