Get dim-label color
Hello, i'm looking for a way to get Gtk.STYLE_CLASS_DIM_LABEL color Tried to play with style context but failed. Thanks, -- Cédric Bellegarde ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Get dim-label color
On Thu, Nov 06, 2014 at 11:04:08AM +0100, Cedric Bellegarde wrote: Hello, Hi. i'm looking for a way to get Gtk.STYLE_CLASS_DIM_LABEL color Tried to play with style context but failed. Is it something like this that you want to do? In Python: sc = widget.get_style_context () sc.add_class (Gtk.STYLE_CLASS_DIM_LABEL) Marcus ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK widget focus control
Hi, I'm trying to get a C++ GTK application that works under GTK 2.2 in Ubuntu 10.04 to run under GTK 2.24 in Ubuntu 14.04. I'm having a problem with focus control in the new system. Some screens with edit fields still handle the keyboard Tab key properly by moving focus to the next widget; others do nothing when Tab is pressed. Using Tab to move focus works on all screens in the old system. In the new system, if I click on any edit field, it accepts focus, so it doesn't seem to be a can-focus type problem. Any ideas what to look for, or what has changed in focus handling between these? (Some code has had to change between the two versions, so it's not exactly the same code base and something may have been broken but none of the changes have been related to focus control as far as I know.) I've read the GTK FAQ and a number of online postings related to GTK focus control without finding anything. Regards, John Boncek ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Notes on wip/gdk-gl2
On sön, 2014-10-12 at 18:47 -0400, Owen Taylor wrote: Performance on my system is actually quite poor in at the moment, which seems at least to be pathological interactions with the system (i915, Fedora 21, Haswell.) I see 60fps with the default configuration of gdkgears for any windowed size of the window, but when I maximize I see the frame rate drop to 30fps, and when I make it fullscreen, I see it drop to 10fps. 'perf top' shows kernel memory allocation as the top functions, so it may be that the continual allocation of new render buffers is triggering the problem. I've done a lot of changes to how the glarea works and how the internal gl machinery works. I'm seeing a lot better performance than this, can you try it again and see how the current code performs? I also see rendering locked at a sub-multiples of 60fps - despite the fact that the rendering is additionally synchronized with the compositor frame clock. If I export vblank_mode=0 I see the expected non-locking behavior. How exactly do you see this? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gdk-pixbuf - more compilation woes with MSVC
I recently noticed this newly introduced statement at line 616 of 'gdk-pixbuf/io-jpeg.c':- density_str = g_strdup_printf (%d, DPCM_TO_DPI (cinfo.X_density)); There's a similar statement, a few lines further down. In 'gdk-pixbuf/gdk-pixbuf-private.h' we define DPCM_TO_DPI like so:- #define DPCM_TO_DPI(value) ((int) round ((value) * 2.54)) Unfortunately, MSVC doesn't contain 'round()'. Its closest equivalent function is probably 'floor()'. Can this be fixed? Also (while I'm at it) there's an unrelated problem at line 757 of 'gdk-pixbuf/io-tiff.c':- guint16 codec = strtol (compression, NULL, 0); Because we're building as 'C' (rather than C++) the variable 'codec' needs to get declared at the top of the function (along with all the other declarations). I can enter these problems into Bugzilla if that's preferable. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk-pixbuf - more compilation woes with MSVC
Hi John, please yes file those issues in bugzilla, since they will get the proper attention faster. Also providing patches will make it even faster. Cheers. On Thu, Nov 6, 2014 at 5:31 PM, John Emmas john...@tiscali.co.uk wrote: I recently noticed this newly introduced statement at line 616 of 'gdk-pixbuf/io-jpeg.c':- density_str = g_strdup_printf (%d, DPCM_TO_DPI (cinfo.X_density)); There's a similar statement, a few lines further down. In 'gdk-pixbuf/gdk-pixbuf-private.h' we define DPCM_TO_DPI like so:- #define DPCM_TO_DPI(value) ((int) round ((value) * 2.54)) Unfortunately, MSVC doesn't contain 'round()'. Its closest equivalent function is probably 'floor()'. Can this be fixed? Also (while I'm at it) there's an unrelated problem at line 757 of 'gdk-pixbuf/io-tiff.c':- guint16 codec = strtol (compression, NULL, 0); Because we're building as 'C' (rather than C++) the variable 'codec' needs to get declared at the top of the function (along with all the other declarations). I can enter these problems into Bugzilla if that's preferable. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk-pixbuf - more compilation woes with MSVC
On 06/11/2014 16:33, Ignacio Casal Quinteiro wrote: please yes file those issues in bugzilla, since they will get the proper attention faster. Also providing patches will make it even faster. Thanks Ignacio, I'm shutting up for the night here but I'll enter those issues tomorrow morning. One more thing... I've also noticed that when building the various pixbuf-loaders as DLLs, I now need to link to libintl (which was never needed before). It's needed now for the symbol 'gettext()'. Is that an intentional change or should I treat that as a bug too? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
