gtk-directfb-crash
Hi All,
I have built gtk with target directfb.
I have installed following pacakages:
1.gtk+-2.18.0
2.atk-1.28.0
3.cairo-1.8.0
4.glib-2.22.2
5.pango-1.26.0
6.pixman-0.12.0
7.DirectFB-1.2.7
8.FreeType 2-9.16.3
Now I am trying to run examples programs thats comes with gtk.While
running the program one window comes with one mouse pointer and it
freeze.I ran same
program with gtk- x11 where I get a Hello world message with proper
window.I am expecting same thing with gtk-direcfb.
Just for debugging I tried putting one exit(0) before gtk_widget_show
(window) function call.Then I got the following error:
/*/
(helloworld:2654): Gdk-CRITICAL **: gdk_drawable_get_colormap: assertion
`GDK_IS_DRAWABLE (drawable)' failed
/*
Could anyone please let me know how to resolve this ?
Below is the code for reference.
int main( int argc,
char *argv[] )
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *button;
/* This is called in all GTK applications. Arguments are parsed
* from the command line and are returned to the application. */
gtk_init (argc, argv);
/* create a new window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
/* When the window is given the delete-event signal (this is given
* by the window manager, usually by the close option, or on the
* titlebar), we ask it to call the delete_event () function
* as defined above. The data passed to the callback
* function is NULL and is ignored in the callback function. */
g_signal_connect (window, delete-event,
G_CALLBACK (delete_event), NULL);
/* Here we connect the destroy event to a signal handler.
* This event occurs when we call gtk_widget_destroy() on the window,
* or if we return FALSE in the delete_event callback. */
g_signal_connect (window, destroy,
G_CALLBACK (destroy), NULL);
/* Sets the border width of the window. */
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
/* Creates a new button with the label Hello World. */
button = gtk_button_new_with_label (Hello World);
/* When the button receives the clicked signal, it will call the
* function hello() passing it NULL as its argument. The hello()
* function is defined above. */
g_signal_connect (button, clicked,
G_CALLBACK (hello), NULL);
/* This will cause the window to be destroyed by calling
* gtk_widget_destroy(window) when clicked. Again, the destroy
* signal could come from here, or the window manager. */
g_signal_connect_swapped (button, clicked,
G_CALLBACK (gtk_widget_destroy),
window);
/* This packs the button into the window (a gtk container). */
gtk_container_add (GTK_CONTAINER (window), button);
/* The final step is to display this newly created widget. */
gtk_widget_show (button);
exit(0);
/* and the window */
gtk_widget_show (window);
/* All GTK applications must have a gtk_main(). Control ends here
* and waits for an event to occur (like a key press or
* mouse event). */
gtk_main ();
return 0;
}
Thanks,
Moutusi
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Deadlock/Freeze
Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. You might also consider the g_idle_add pattern and have threads use this mechanisms to run callbacks in the main GUI thread, avoiding the locking issues entirely and also making your program more cross-platform. http://irrepupavel.com/documents/gtk/gtk_threads.html explains this pattern somewhat. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Deadlock/Freeze
Michael Torrie wrote: Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. Not sure if this has to be done in the main thread or just the callbacks, though... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Deadlock/Freeze
It is sad to say, but the issue described above, seemed to be generated by an human dumb error (as always). I have set two refresh times: one in the case of full connectivity (about an hour), and the other, smaller (1 minute), in the case of lack of communication. In order to implement this i did: def callback(): data = parse() if not data: gobject.timeout_add(1m, callback) else: gobject.timeout_add(1h, callback) return True As you can notice by yourselves, I forgotten to remove the return True, so it ended not in a so called deadlock, but in a sort of dos, because of the amount of thenumber of callbacks being wainiting in the main loop. So I changed return True, with a return False, and it seems to work properly (at least for the testing till now : ). Now it lasts the question about placing a threads_enter/leave in each callback. Is this really needed? I think that when the gstreamer threads wants to write on the screen, it insert an expose event from the main_loop, so the whole drawing is right handled from the main loop. These are just suppositions. On Thu, Oct 29, 2009 at 7:08 PM, Michael Torrie torr...@gmail.com wrote: Michael Torrie wrote: Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. Not sure if this has to be done in the main thread or just the callbacks, though... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Matteo Landi http://www.matteolandi.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
