Fwd: Re: How to locate the 'Gtk-WARNING' line number
On 17.02.2014 10:36, Marco Scannadinari wrote: On Mon, 2014-02-17 at 16:44 +0800, Wiky wrote: Hi,all. I'm currently writing a program based Gtk+-3.0. When it runs, I get '(a.out:10874): Gtk-WARNING **: Failed to ...' in the terminal. I know the problem is about GtkLabel, but I really don't know which GtkLabel. Is there a way to locate the line numer that give the warning? Sorry for my english ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list If your UI is hand-coded, and in main() (not using GtkApplication), then I suppose you can run it through gdb and step through each line to see where it prints the error. Be sure to compile with -Og -g and without optimisations though I think just setting a break-point on g_log and then asking for a backtrace when you hit the breakpoint should also work and is possibly quicker. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spell checking in GIO
This sums up my opinion on this topic quite well. I think we're going to get a better experience if we integrate this at the Gtk level than if we try to invent a bunch of generic interfaces that would be required to get this sort of level of integration. If we can design this as a feature for Gtk and discover that, actually, the API is not that tightly coupled with Gtk, then we could consider the possibility of moving it to GIO -- assuming we become convinced that there is a good non-GTK use for it there. There's a lot of we here. Is anyone actually interested in stepping up to work on this? I'm the current gtkspell maintainer and last year took care of g-objectifying GtkSpell and releasing a Gtk+3 compatible version. That said, if the goal is to adapt gtkspell and integrate in into Gtk, I'm happy to do so (possibly with the assistance of someone more experienced with working inside Gtk). Sandro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_set_size_request delayed until next allocation change
Hello,
I have a GtkDrawingArea inside a GtkViewport, and I have a callback
connected to the size-allocate signal of the GtkViewport which resizes
the GtkDrawingArea by calling gtk_widget_set_size_request on the latter,
see sample source code below.
I however notice that the GtkDrawingArea allocates the requested size
only the _next_ time the allocation of the GtkViewport changes, and
hence the allocation of the GtkDrawingArea is the one requested for the
previous allocation of the GtkViewport.
The issue is best visible when maximizing and unmaximizing the window:
when maximizing, the size of the GtkDrawingArea is still the one for the
unmaximized state, and when unmaximizing again, the size of the
GtkDrawingArea is the one for the maximized state.
Question: Is this a mistake in my code or a Gtk bug? I'm using
gtk3-3.8.1-1.fc20.x86_64
Thanks for any inputs.
Sandro
-- Sample code: --
// gcc alloc.c -o alloc $(pkg-config --cflags --libs gtk+-3.0)
#include gtk/gtk.h
#include stdio.h
void resize_drawarea (GtkWidget* viewport, GdkRectangle* rect, gpointer
data)
{
gtk_widget_set_size_request (GTK_WIDGET (data), rect-width / 2,
rect-height / 2);
gtk_widget_queue_resize (GTK_WIDGET (data));
printf(set_size_request(%d, %d)\n, rect-width /2, rect-height / 2);
// Wait for size_request
while (gtk_events_pending ()) {
gtk_main_iteration ();
}
int w = gtk_widget_get_allocated_width (GTK_WIDGET (data));
int h = gtk_widget_get_allocated_height (GTK_WIDGET (data));
printf(allocation = %d x %d\n\n, w, h);
}
int main(int argc, char* argv[])
{
gtk_init (argc, argv);
GtkWidget* window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
GtkWidget* viewport = gtk_viewport_new (NULL, NULL);
GtkWidget* drawarea = gtk_drawing_area_new ();
gtk_container_add (GTK_CONTAINER (window), viewport);
gtk_container_add (GTK_CONTAINER (viewport), drawarea);
gtk_widget_set_halign (drawarea, GTK_ALIGN_CENTER);
gtk_widget_set_valign (drawarea, GTK_ALIGN_CENTER);
GdkRGBA black = {0., 0., 0., 1.};
gtk_widget_override_background_color (drawarea,
GTK_STATE_FLAG_NORMAL, black);
gtk_window_set_default_size (GTK_WINDOW (window), 640, 480);
g_signal_connect (window, destroy, G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (viewport, size-allocate, G_CALLBACK
(resize_drawarea), drawarea);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk3 set_size_request delayed
Hi, I'm porting a pygtk2 application to Gtk3 aka pygi. I've encountered the problem that set_size_request requests appear to become stuck in the event queue. This can be best seen by the example [1]. If you maximize the window, the DrawingArea does not resize as it was requested to. If you unmaximize the window, only then the size requested previously is applied, with the new size request again stuck somewhere - it will get applied again one iteration too late, after the next resize. Less obviously, but the same problem applies for normal resizes. The corresponding pygtk variant [2] behaves as expected. Also, a C port of [1] ([3]) has the same issue. Am I doing something wrong or is this a Gtk3 bug? Thanks, Sandro [1] http://nas.dyndns.org/temp/test.py [2] http://nas.dyndns.org/temp/test2.py [3] http://nas.dyndns.org/temp/test.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
