Re: cairo pixmap
Hi, On Sat, 2007-05-19 at 13:41 +0200, control H wrote: Hi, I'm planning to make my app use cairo instead of GDK based functions. I'm using a drawing area, which draws into a pixmap when the configure event is emitted, and copies the relevant part of the pixmap back on the screen on the expose event. When I'm doing the same with cairo, a black screen is the result. The ref. manual says in the FAQ that I should either turn off double buffering, or draw in the expose signal. This is also what the example testcairo (coming along with Gtk) does. I'm confused. Does this mean that drawing using cairo is slower since it has to redraw the whole thing again on each expose signal? Or is there some smart thing in Gtk that somehow knows that when the expose event is a result of a configure event, it doesn't really do the drawing but copies the invalidated part back? The signal handler for the expose event is passed some parameters specifying which part of the screen has become invalidated. If you use these in a Cairo drawing mask, then redraw your canvas, it should be quite fast, as Cairo will ignore all operations to areas outside the mask. Philip Thanks... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo pixmap
The signal handler for the expose event is passed some parameters specifying which part of the screen has become invalidated. If you use these in a Cairo drawing mask, then redraw your canvas, it should be quite fast, as Cairo will ignore all operations to areas outside the mask. But this means -if I understand correctly- that I still have to redraw from scratch, be it not the complete drawing area but only the invalidated part. Therefore, it will still be slower than in my old GDK based situation, especially when the to be drawn picture becomes more complex (which in my situation is the case). Do you/does anybody know what the technical reason is why cairo contexts fail outside the expose signal? I'm just curious. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo pixmap
On Sat, 2007-05-19 at 14:12 +0200, control H wrote: The signal handler for the expose event is passed some parameters specifying which part of the screen has become invalidated. If you use these in a Cairo drawing mask, then redraw your canvas, it should be quite fast, as Cairo will ignore all operations to areas outside the mask. But this means -if I understand correctly- that I still have to redraw from scratch, be it not the complete drawing area but only the invalidated part. Therefore, it will still be slower than in my old GDK based situation, especially when the to be drawn picture becomes more complex (which in my situation is the case). That's how I've done it in programs I've written, but I'm far from an expert on the subject. There may well be a way to double-buffer the canvas, and just blit the exposed area from the buffer. Do you/does anybody know what the technical reason is why cairo contexts fail outside the expose signal? I'm just curious. I'm not sure what you mean here, sorry. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Bypassing Force Quit
On Wed, May 16, 2007 at 02:19:19PM -0400, Dan Gruhn wrote:
I am running on FedoraCore5 and I have an application that when the user
clicks the X in the upper right wants to query for saving any changed
data. I have currently coded this as a signal handler for the delete
event which puts up a modal dialog box with the questions and waits for
the user's response. However, after some internal timeout, I get
another dialog box warning me that the window titled ... is not
responding and do I want to force it to quit, losing all of my data.
I would like to disable this if possible, but I've not yet found a way.
Is this caused by GTK? Has anyone encountered this and have you found a
way around it?
You are probably doing something wrong. As you can try
yourself, this program
==
#include gtk/gtk.h
static gboolean
deleted(GtkWindow *window)
{
GtkWidget *dialog;
gint response;
dialog = gtk_message_dialog_new(window, 0,
GTK_MESSAGE_QUESTION,
GTK_BUTTONS_YES_NO,
Really close window?);
response = gtk_dialog_run(GTK_DIALOG(dialog));
gtk_widget_destroy(dialog);
return response == GTK_RESPONSE_NO;
}
int
main(int argc, char *argv[])
{
GtkWidget *window, *widget;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size(GTK_WINDOW(window), 400, 300);
widget = gtk_label_new(Try to close me);
gtk_container_add(GTK_CONTAINER(window), widget);
gtk_widget_show_all(window);
g_signal_connect(G_OBJECT(window), delete-event,
G_CALLBACK(deleted), NULL);
g_signal_connect(G_OBJECT(window), destroy, gtk_main_quit, NULL);
gtk_main();
return 0;
}
==
does exactly what you describe, yet it does not raise any
`force quit' dialog. While this is no hard proof, it still
supports the theory if you let Gtk+ main loop run it
properly responds to anything the window manager may want
a response to.
However, if one replaces the body of deleted() with
sleep(3), metacity indeed starts complaininig about
a non-responsive application with the `force quit' dialog.
This is because the window does not respond to the ping sent
after delete events in 2.25 second now (the timeout value
seems to be hardwired in metacity).
Usually there is no reason why a yes/no dialog construction
should take several seconds. And even if there is, your
application should not become non-responsive for such a long
time, so do the necessary work in a way that lets Gtk+ main
loop to run.
Yeti
--
http://gwyddion.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk-CRITICAL with a GtkFileChooserDialog
Hey,
I create a GtkFileChooserDialog, then I set its current folder to my home
dir, then I create a GtkFileChooserButton.
When I run the prog, I get:
(test_gtk:22697): Gtk-CRITICAL **: gtk_file_system_path_to_uri: assertion
`path != NULL' failed
I have gtk+ 2.10.11
I would like to know what the problem is, please (problem from gtk, from
my code, etc...)
Attached, a simple test case
thank you
Vincent Torri/* gcc -g -Wall -o test_gtk test_gtk.c `pkg-config --cflags --libs gtk+-2.0` */
#include gtk/gtk.h
int
main (int argc, char *argv[])
{
GtkFileChooser *chooser;
GtkWidget *dialog;
GtkWidget *file_input;
gtk_init (argc, argv);
dialog = gtk_dialog_new_with_buttons (X264 Gtk Encoder,
NULL, 0,
NULL);
chooser = (GtkFileChooser*)
gtk_file_chooser_dialog_new(Select a file,
GTK_WINDOW(dialog),
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
gtk_file_chooser_set_current_folder (chooser, g_get_home_dir ());
file_input = gtk_file_chooser_button_new_with_dialog (GTK_WIDGET(chooser));
gtk_main ();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk+ icon compiled into executable
Hello, I am new to Gtk+ and writing a small application with glade. I have my source file and glade file and icon for the dialog. My question is how can I include the icon in the final binary so it does not have to included in the same folder as the binary. Thanks in advance. Brad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ icon compiled into executable
brad smith wrote: Hello, I am new to Gtk+ and writing a small application with glade. I have my source file and glade file and icon for the dialog. My question is how can I include the icon in the final binary so it does not have to included in the same folder as the binary. Perhaps convert the icon file to textual data that can be #include'd in the source code? -- -Mike Melanson ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
