Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
On Tue, 17 Jun 2014 17:34:22 -0700
Matthew Brush wrote:
> On 14-06-17 09:28 AM, Dimitar Zhekov wrote:
> >
> > 5. The waf build of geany plugins does not currently support gtk+3.
>
> Not a problem with GTK3, just a matter of those using/responsible for
> Waf to update the build system. [...]
Attached is a simple diff with gtk+3 support for waf build of plugins.
Apply with -p0, specify --enable-gtk3, and also --enable-plugins=list,
since it does not check which ones support gtk+3.
On Sat, 21 Jun 2014 12:48:40 +0300
Dimitar Zhekov wrote:
> I wrote simple gtk+3 support for geany plugins wscript, but have only
> tested it under windows so far, not linux.
Now tested under Win~1 and Linux. If you give me a green light, I can
push it to plugins git.
--
E-gards: Jimmy
--- wscript.orig Sun Apr 27 13:56:40 2014
+++ wscript Thu Jun 19 13:11:11 2014
@@ -62,6 +62,9 @@
APPNAME = 'geany-plugins'
VERSION = '1.25'
LINGUAS_FILE = 'po/LINGUAS'
+MINIMUM_GTK_VERSION = '2.16.0'
+MINIMUM_GTK3_VERSION = '3.0.0'
+MINIMUM_GLIB_VERSION = '2.20.0'
top = '.'
out = '_build_'
@@ -79,12 +82,16 @@
conf.load('compiler_c')
# common for all plugins
-check_cfg_cached(conf,
- package='gtk+-2.0',
- atleast_version='2.16.0',
- uselib_store='GTK',
- mandatory=True,
- args='--cflags --libs')
+# GTK / GLIB version check
+gtk_package_name = 'gtk+-3.0' if conf.options.use_gtk3 else 'gtk+-2.0'
+minimum_gtk_version = MINIMUM_GTK3_VERSION if conf.options.use_gtk3 else MINIMUM_GTK_VERSION
+conf.check_cfg(package=gtk_package_name, atleast_version=minimum_gtk_version, uselib_store='GTK',
+mandatory=True, args='--cflags --libs')
+conf.check_cfg(package='glib-2.0', atleast_version=MINIMUM_GLIB_VERSION, uselib_store='GLIB',
+mandatory=True, args='--cflags --libs')
+# remember GTK version for the build step
+conf.env['gtk_package_name'] = gtk_package_name
+
check_cfg_cached(conf,
package='geany',
atleast_version='1.24',
@@ -98,7 +105,7 @@
conf.define('REVISION', revision, 1)
# GTK/Geany versions
geany_version = conf.check_cfg(modversion='geany') or 'Unknown'
-gtk_version = conf.check_cfg(modversion='gtk+-2.0') or 'Unknown'
+gtk_version = conf.check_cfg(modversion=gtk_package_name, uselib_store='GTK') or 'Unknown'
load_intltool_if_available(conf)
setup_configuration_env(conf)
@@ -205,6 +212,9 @@
# Options
opt.add_option('--no-scm', action='store_true', default=False,
help='Disable SCM detection [default: No]', dest='no_scm')
+opt.add_option('--enable-gtk3', action='store_true', default=False,
+help='compile with GTK3 support (experimental) [[default: No]',
+dest='use_gtk3')
# Paths
opt.add_option('--libdir', type='string', default='',
help='object code libraries', dest='libdir')
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
On Sat, 21 Jun 2014 19:27:16 +0200 Colomban Wendling wrote: > Le 21/06/2014 11:48, Dimitar Zhekov a écrit : > > [...] > > > > With gtk+3, pressing "down" to scroll in a source file gives CPU usage > > of 50% (that is, 100% on a single cores), and the scrolling is a bit > > jumpy. For reference, gtk+2 uses 22% CPU, and SciTE for Win32 only 9% > > (due to the fact is uses Win32 API directly). > > I just stumbled upon > http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/ > which seems to say that with GTK 3.8+ widgets doing scrolling "the old > way" (e.g. the GTK < 3.8 way) will likely be just slow, as IIUC the old > optimization for it was dropped. But the binary used is 3.6.4, so that's not the cause. BTW, gtk+2 scrolling is buggy: if there is a window above the text, it's "scrolled" as well. For example, with a Find dialog and scrolling down, it's title is duplicated N times above of the dialog. The non-gtk windows are affected as well, for example Win~1 Task Manager, which is on Top of the other windows by default. I'm beginning to suspect how the gtk+2 scrolling under Win~1 works. :) The first full redraw of the scintilla widget fixes everything, so it's not much of a problem. I won't check anything else on the $subject until an official Win~1 binary with the new drawing model is released, it's simply not worth. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
Le 21/06/2014 11:48, Dimitar Zhekov a écrit : > [...] > > With gtk+3, pressing "down" to scroll in a source file gives CPU usage > of 50% (that is, 100% on a single cores), and the scrolling is a bit > jumpy. For reference, gtk+2 uses 22% CPU, and SciTE for Win32 only 9% > (due to the fact is uses Win32 API directly). I just stumbled upon http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/ which seems to say that with GTK 3.8+ widgets doing scrolling "the old way" (e.g. the GTK < 3.8 way) will likely be just slow, as IIUC the old optimization for it was dropped. Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
Le 18/06/2014 20:09, Dimitar Zhekov a écrit : > On Tue, 17 Jun 2014 17:34:22 -0700 > Matthew Brush wrote: >> On 14-06-17 09:28 AM, Dimitar Zhekov wrote: >>> 4. The second and especially the third tab in the About dialog cause >>> 100% CPU load and blocking. >>> >> >> IIRC we have some weird stuff in those tabs, custom wrapping widgets >> which are no longer needed for GTK3, etc. Actually, GeanyWrapLabel is still required with GTK3, because although GtkLabel is somewhat supposed to do it, it actually doesn't. You can make it wrap dynamically by setting the character-width property, but that won't event really do what you want, apparently the label will still request the minimal size for it to display when wrapped at that size, and then will be too tall if wrapper to something larger. >> Even on Linux the "Credits" >> tab is fairly broken, it doesn't allow selection, context menu, etc. That's not really "broken", it's just a bunch of labels. But yeah we could make those selectable if we wanted. >> IMO >> we should move this whole dialog to Glade, just use a plain GtkTextView >> and add all the names into the Glade file instead of loading from static >> arrays and doing all the markup formatting using string/markup >> functions, etc or just use GtkAboutDialog (properly). > > The second tab is mostly two labels with markup, and the third is > exactly a GtkTextView, which is disturbing for my Scope plugin. I fixed something in the about dialog header with GTK 3.8+, that might have been the cause of the CPU usage you saw. On Linux it used to eat some CPU, and emit tons of warnings (probably like 1 each 4 clock tick, which is probably like 15 a second). Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
Hi,
Some more informatin on $subject and related topics.
--
At the time when gtk_widget_get_window(main_widgets.window) is invoked,
there is indeed no main window (GetActionWindow() returns NULL).
Since this is about reopening files on startup, their shortcuts, if
any, were already resolved when the files were open in the first place.
The right thing to do is probably instruct document_open_file_full()
not resolve them again.
--
There are lots of warnings about implicit declaration of function
'win32_...', probably a result of "include what you use" (and not
specific to gtk+3).
--
With gtk+3, pressing "down" to scroll in a source file gives CPU usage
of 50% (that is, 100% on a single cores), and the scrolling is a bit
jumpy. For reference, gtk+2 uses 22% CPU, and SciTE for Win32 only 9%
(due to the fact is uses Win32 API directly).
--
With gtk+3, when I have a selected tree view row in an unfocused tree
view, it's displayed in gray as usual (with the default theme), but
positioning the mouse over it alters the display, showing any check
boxes (GtkCellRendererToggle) as unchecked. gtk+2 is OK.
--
The plugins do not build with the latest Geany, due to a bug in Geany
wscript: 'localedir': '${datarootdir/locale' is missing "}".
--
I wrote simple gtk+3 support for geany plugins wscript, but have only
tested it under windows so far, not linux.
--
Scope does not currently build with gtk+3; I wrote a fix and will send
it when I can [1]. GtkTextView works without problems, so the blocking
of Geany About Dialog is not because of GtkTextView per se.
--
[1] Last, there was a large storm at my town (g:varna flood), and the
internet is unstable, so I'll probably use mail only for a few days,
not svn or git.
--
E-gards: Jimmy
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
On Tue, 17 Jun 2014 17:34:22 -0700 Matthew Brush wrote: > On 14-06-17 09:28 AM, Dimitar Zhekov wrote: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin > > ... > > > > ... > > > > I coudn't get a proper HWND for Geany main window. Using > > gdk_win32_window_get_handle(gdk_get_default_root_window()) works, > > but the link UI may (or may not?) be displayed below the Geany > > window, looking as if we blocked. > > > > A possible solution would be to use some Windows API directly, for > > example GetActiveWindow(). > > > > There's tons of bug reports about crashers on a number of different > platforms when you search Google for "gdk_window_has_impl" (with and > without leading underscore), seems like it does/did miss a NULL check or > such. My first thought is that we try to access the native window handle > before it has actually been allocated (eg. before a map event or > whichever event fires once window resources have been allocated), but > it's just an idea. Well it works on gtk+2... Whether the window actually exists can be easily tested by GetActiveWindow(). Personally I see no reason to use GDK macros, when we need exactly the active window. > Maybe trying to do `gtk_widget_map(win)` (or > whichever is the correct function) before trying to access the HWND > would fix/hide the bug? That's the main Geany window... I'm not sure it's a good idea. > > 3. The items under cursor are not always highlighted. For example, > > when I open Edit and move the mouse, the menu items are highlighted > > fine, except for Preferences, which may or may not be highlighted. > > > > I never noticed this when using GTK3 on Windows, but it's possible it > happened and I just didn't notice. Maybe there's something weird about > that particular menu item, like that we have one below it who's > sensitivity changes depending on runtime conditions, or the current UI > language/translation string, etc. It'd be interesting to move the menu > item up to the top of the menu, try changing the stock/icon/labels, > removing accelerator, etc. to see why only one item acts weird. I gave this as a more or less stable example. Sometimes a button is not highlighted, but it's rare and random. > > 4. The second and especially the third tab in the About dialog cause > > 100% CPU load and blocking. > > > > IIRC we have some weird stuff in those tabs, custom wrapping widgets > which are no longer needed for GTK3, etc. Even on Linux the "Credits" > tab is fairly broken, it doesn't allow selection, context menu, etc. IMO > we should move this whole dialog to Glade, just use a plain GtkTextView > and add all the names into the Glade file instead of loading from static > arrays and doing all the markup formatting using string/markup > functions, etc or just use GtkAboutDialog (properly). The second tab is mostly two labels with markup, and the third is exactly a GtkTextView, which is disturbing for my Scope plugin. > > 5. The waf build of geany plugins does not currently support gtk+3. > > > > Not a problem with GTK3, just a matter of those using/responsible for > Waf to update the build system. Not a gtk+3 problem, of course, just a note. I'll try to add gtk+3 support to test Scope. > > Wikipedia calls gtk+3.4 "the first version of GTK+ 3 that works well > > on Windows", but that seems to be an overstatement. Maybe 3.10+ with > > the changed event loop and drawing will be better. Or worse... > > It might be assuming the "works well" is for applications coded against > GTK3, fully using the framework supporting the toolkit, not trying to > support gtk2 and 3 at the same time, and that don't have almost a decade > of cruft built up to work around issues which may or may not even exist > anymore in the toolkit or/on the supported Windows versions :) Hello world? :) I haven't seen any large and popular application started with gtk+3. Of course, some may be partially rewritten to take full advantages of it. > > For now, we'd better stick to gtk+2 under Windows. > > Even better would be to find out what is causing the problems and fix > the issues, most likely the stuff is going to be things we did slightly > weird in GTK2 that is no longer needed or doesn't work exactly the same > with GTK3. If we hold off switching to bundled version to GTK3, nobody > will use it and it won't get tested or fixed. The event loop and drawing were changed considerably in 3.10. It may be reasonable to wait a bit, and see how Geany works with it. After all, these problems are specific to gtk+3 under Win~1. > BTW, which Windows version and which GTK+ architecture bundle (32/64) > are you using, in case I get a chance to try and reproduce? XP, 32-bit, OEM. Maybe I'll buy a new machine this year with 7 or 8. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mai
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
On 14-06-17 09:28 AM, Dimitar Zhekov wrote: Hi, Taking point from "[Geany-Users] I can't see highlighted item in menu", here are some results of compiling and running Geany under Windows with the official gtk+3.6.4 binary: 1. Compiles and install normally (waf build system). 2. On start, if at least 1 file was open, crashes with: Program received signal SIGSEGV, Segmentation fault. 0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin \libgdk-3-0.dll (gdb) bt #0 0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll #1 0x006e4388 in _gdk_window_has_impl () from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll #2 0x0071898e in gdk_win32_window_get_handle () from c:\tmp\scp\gtk+\bin\libgdk-3-0.dll #3 0x0045e998 in win32_get_shortcut_target () #4 0x00428992 in document_open_file_full () #5 0x00408758 in open_session_file () #6 0x00408886 in configuration_open_files () #7 0x0045ff75 in load_startup_files () #8 0x0046047f in main () The problem is in GDK_WINDOW_HWND(gtk_widget_get_window (main_widgets.window)), used to compute HWND to serve as parent window when resolving a link, if this happens to require UI. On link target missing, Win~1 searches for "similar" files, displaying a small dialog, and sometimes asks whether file X is the missing link. I coudn't get a proper HWND for Geany main window. Using gdk_win32_window_get_handle(gdk_get_default_root_window()) works, but the link UI may (or may not?) be displayed below the Geany window, looking as if we blocked. A possible solution would be to use some Windows API directly, for example GetActiveWindow(). There's tons of bug reports about crashers on a number of different platforms when you search Google for "gdk_window_has_impl" (with and without leading underscore), seems like it does/did miss a NULL check or such. My first thought is that we try to access the native window handle before it has actually been allocated (eg. before a map event or whichever event fires once window resources have been allocated), but it's just an idea. Maybe trying to do `gtk_widget_map(win)` (or whichever is the correct function) before trying to access the HWND would fix/hide the bug? 3. The items under cursor are not always highlighted. For example, when I open Edit and move the mouse, the menu items are highlighted fine, except for Preferences, which may or may not be highlighted. I never noticed this when using GTK3 on Windows, but it's possible it happened and I just didn't notice. Maybe there's something weird about that particular menu item, like that we have one below it who's sensitivity changes depending on runtime conditions, or the current UI language/translation string, etc. It'd be interesting to move the menu item up to the top of the menu, try changing the stock/icon/labels, removing accelerator, etc. to see why only one item acts weird. 4. The second and especially the third tab in the About dialog cause 100% CPU load and blocking. IIRC we have some weird stuff in those tabs, custom wrapping widgets which are no longer needed for GTK3, etc. Even on Linux the "Credits" tab is fairly broken, it doesn't allow selection, context menu, etc. IMO we should move this whole dialog to Glade, just use a plain GtkTextView and add all the names into the Glade file instead of loading from static arrays and doing all the markup formatting using string/markup functions, etc or just use GtkAboutDialog (properly). Related fact: Skimming the Git history, I was the last developer contributor added to the About dialog in 2011 :) (translation contributors seems to have more recent updates though). I wonder if we could/should generate this list from Git log? 5. The waf build of geany plugins does not currently support gtk+3. Not a problem with GTK3, just a matter of those using/responsible for Waf to update the build system. Probably the quickest way to get this resolved is to start shipping Geany for Windows releases with GTK3 so it has to be done for plugins to work, otherwise probably nobody will take the initiative until Geany core bumps min. to GTK3, and in the meantime nobody will be testing Geany or plugins on GTK3 in order to resolve quirks like you're finding. Wikipedia calls gtk+3.4 "the first version of GTK+ 3 that works well on Windows", but that seems to be an overstatement. Maybe 3.10+ with the changed event loop and drawing will be better. Or worse... It might be assuming the "works well" is for applications coded against GTK3, fully using the framework supporting the toolkit, not trying to support gtk2 and 3 at the same time, and that don't have almost a decade of cruft built up to work around issues which may or may not even exist anymore in the toolkit or/on the supported Windows versions :) For now, we'd better stick to gtk+2 under Windows. Even better would be to find out what is causing the problems and fix the issues, most likely the stuff is goin
