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