Hi, All,
I see that the Scope plugin is marked in autotools as gtk+2 only, and rightly so. At some point, gtk+3 broke GtkTextView: instead of a reasonable default size, a view without text is 0 pixels high (actually 1, gtk+ does not support zero). One of these views is critical for the Scope UI. Interestingly, even after typing some text in it (I managed to do that somehow), the view remains 1 pixel high. :)
I can find some workaround for this, though there doesn't seem to be any good ones [1]. And create a PR to fix the insane statusbar padding [2]. And find some non-tabletish theme, and fix it for Windows Medium fonts [3], and...
Enough. If the gtk+3 developers want to target the mobile market or something, so be it. I'm switching to another editor. It has disadvantages, but is stable, and gets the job done.
It'll be nice if somebody makes the vte and headers checks in scope.m4 as unix-only (there's already a "case" for the non-unix platforms). Personally I'll dump a TODO list for the plugin, and mark it as "Orphaned", along with geanyinsertnum and geanyextrasel.
Please, spare me any reproaches, I feel unpleasant as it is.
*** I wish Geany, and all of you, the best of luck. ***
--
[1] For example, set height request 80, as somebody did for the Project Description field, though using a fixed height is against everything gtk+. That Description is broken for me BTW, neither the arrows nor Enter scroll it, and the cursor happily disappears below the lower border after entering a few lines. YMMV.
Another approach is to put some text in the textview, prefferably with new lines, but that worked for me with mixed success.
[2] "gtk 3.16 statusbar size under Win~1" in the maining list.
[3] That doesn't appear as easy as setting a smaller default font for all views, and the gtk+3 programs can't be marked as "DPI unaware" by Windows 7 "Troubleshooting" feature.
-- E-gards: Jimmy
Hi,
Le 27/11/2015 18:57, Dimitar Zhekov a écrit :
I see that the Scope plugin is marked in autotools as gtk+2 only, and rightly so. […]
Enough. If the gtk+3 developers want to target the mobile market or something, so be it. I'm switching to another editor. It has disadvantages, but is stable, and gets the job done.
I for one don't plan on dropping full GTK2 support in any near future. Basically, unless supporting GTK2 prevents us from running on modern OSes too, it'll (most probably) stick.
So yeah, Frank has some plans to require GTK3 support in GP plugins, which I can understand for consistency with Geany and as some setups will (in the future) require a Wayland-capable toolkit (which, AFAIK, GTK2 isn't) and the likes; but Geany (and GP) will not drop GTK2 support just like that.
Regards, Colomban
PS:
[1] For example, set height request 80, as somebody did for the Project Description field, though using a fixed height is against everything gtk+. […]
BTW, instead of size request you can set a "min content width/height" on the GtkScrolledWindow.
Another approach is to put some text in the textview, prefferably with new lines, but that worked for me with mixed success.
AFAIK the small size is a result in changes in GtkScrolledWindow rather, and GtkTextView only asks for its very minimal size. GtkScrolledWindow used to require a quite large size (I'd say around 80x80 maybe), but that changed so now it requires its very minimal size too.
One possible "solution" for an "intelligently" sized view would be to override the size requisition for the scrolled window and do something "smart" in it in all cases, even if the child GtkTextView doesn't ask for anything.
But yeah, that's kinda annoying.
BTW, I'm not sure in what context this is, but default packing flags changed in GTK3, so some things that used to expand by default might not anymore, so this might also be the source of the problem.
On 2015-11-27 9:57 AM, Dimitar Zhekov wrote:
[...]
Enough. If the gtk+3 developers want to target the mobile market or something, so be it. [...]
I feel your frustration. The overall Windows support by GTK+ has severely degraded with GTK+ 3 in a number of ways:
- Uses touch-style GNOME theme which looks absolutely grotesque. We'll have to ship a CSS theme for each Windows version if we care at all about Geany feeling like a good Windows app. - A number of common dialogs have been crippled to facilitate use by mobiles (even though GTK+ basically isn't viable on 99% of the worlds mobile devices). Also the file dialogs crash when compiled for 64-bit Windows (ie. the mainstream). - Doesn't provide any built-in fallback icons, so we'll have to ship a whole set of stock icons we use from Tango or GNOME3 theme. - Can't be bothered to provide binaries as is customary for Windows software to do. Instead, pawn off the responsibility to a simulated Unix-like environment which is massive, slow and requires special scripts in each app to extract all of GTK+ binaries from a full Unix-like root filesystem install. - Not to mention specific bugs and regressions as you're experiencing.
Personally I'll be sticking with GTK+ 2 on Windows with Geany as long as possible.
It's not much better when I'm in Linux either. GTK+ 3 completely broke (ie. de-activated) theme engines, not even waiting for GTK+ 4, so the theme engine KDE used which provided almost perfect integration of GTK+ apps into KDE no longer works and all GTK+ 3 apps look horrid and out of place now. I'll also be sticking with GTK+ 2 on Linux.
</rant>
Sad to hear you're not gonna use Geany though, I find the GTK+ 2 releases of Geany to still be very usable on Windows 7 and 10.
Regards, Matthew Brush
On 28.11.2015 02:56, Matthew Brush wrote:
On 2015-11-27 9:57 AM, Dimitar Zhekov wrote:
[...]
Enough. If the gtk+3 developers want to target the mobile market or something, so be it. [...]
I feel your frustration. The overall Windows support by GTK+ has severely degraded with GTK+ 3 in a number of ways:
- Uses touch-style GNOME theme which looks absolutely grotesque. We'll have to ship a CSS theme for each Windows version if we care at all about Geany feeling like a good Windows app.
- A number of common dialogs have been crippled to facilitate use by mobiles (even though GTK+ basically isn't viable on 99% of the worlds mobile devices). Also the file dialogs crash when compiled for 64-bit Windows (ie. the mainstream).
- Doesn't provide any built-in fallback icons, so we'll have to ship a whole set of stock icons we use from Tango or GNOME3 theme.
- Can't be bothered to provide binaries as is customary for Windows software to do. Instead, pawn off the responsibility to a simulated Unix-like environment which is massive, slow and requires special scripts in each app to extract all of GTK+ binaries from a full Unix-like root filesystem install.
- Not to mention specific bugs and regressions as you're experiencing.
Personally I'll be sticking with GTK+ 2 on Windows with Geany as long as possible.
It's not much better when I'm in Linux either. GTK+ 3 completely broke (ie. de-activated) theme engines, not even waiting for GTK+ 4, so the theme engine KDE used which provided almost perfect integration of GTK+ apps into KDE no longer works and all GTK+ 3 apps look horrid and out of place now. I'll also be sticking with GTK+ 2 on Linux.
</rant>
Sad to hear you're not gonna use Geany though, I find the GTK+ 2 releases of Geany to still be very usable on Windows 7 and 10.
I full agree with that.
Cheers, Frank
On 27.11.2015 18:57, Dimitar Zhekov wrote:
It'll be nice if somebody makes the vte and headers checks in scope.m4 as unix-only (there's already a "case" for the non-unix platforms). Personally I'll dump a TODO list for the plugin, and mark it as "Orphaned", along with geanyinsertnum and geanyextrasel.
For the records: This has been done with 9185ec8e6 and 310a292da. Sad.
Cheers, Frank