Copy full path when hovering over a file?
Is there any keybinding that allows copying into the clip-board the full path of a filename that you hover over in the file chooser dialog? E.g. when looking at the Recent file menu, there is a tooltip popup of the full path of a file. Is it possible to copy the contents of this tooltip so that you can later paste it as text? Thanks! Dov ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK 2.24.10 memory leak on win32?
We have found a regression that block us to migrate our existing apps from
GTK 2.16.x to GTK 2.24.10 (20120208), it seems there is a memory leak in
g_idle_add() use or something related to queue_draw(), anyway the following
code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk
2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with GTK
2.24.10 on win32.
I'm posting the code here before creating a bugzilla entry for it since I'm
not sure I can use g_idle_add to notify a new frame is available without
freeing the source, that works in linux and in older WIN32 versions and it
seems correct since g_idle_add() documentation says:
*If the function returns FALSE it is automatically removed from the list of
event sources and will not be called again.*
The (real) code is a video player with multiple realtime streams, this code
use g_timeout_add() to simulate the 25fps of the video, I fill the drawing
area with a simple red/blue pattern without thinking to much to endianness
of the pixel components, but this is a sample, the code leaks on
win32/2.24.10 also if I do not draw inside the GdkImage...
Anyway here is the code, as short as I could make it :)
#include gtk/gtk.h
#include stdint.h
double last_update;
GtkWidget *dest;
GdkImage *img;
GdkGC *gc;
int frames = 0;
int queue_draw() {
gtk_widget_queue_draw(dest);
return FALSE;
}
double get_timer() {
GTimeVal now;
g_get_current_time(now);
return (double)now.tv_sec + ((double)now.tv_usec / 100.0f);
}
void on_expose() {
gdk_draw_image(dest-window, gc, img, 0, 0, 0, 0, img-width,
img-height);
frames++;
}
int draw_func() {
static int pos = 0;
uint32_t *ptr = (uint32_t *)img-mem;
int x, y;
for (x = 0; x img-width; ++x) {
for (y = 0; y pos; ++y)
ptr[x + y * img-width] = 0xff;
for (y = pos; y pos + (img-height / 2) y img-height; ++y)
ptr[x + y * img-width] = 0x00ff;
for (y = pos + img-height / 2 ; y img-height; ++y)
ptr[x + y * img-width] = 0xff;
}
g_idle_add((GSourceFunc)queue_draw, NULL);
if (++pos = img-height)
pos = 0;
return TRUE;
}
int main(int argc, char *argv[])
{
gtk_init(argc, argv);
GtkWidget *w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
dest = gtk_drawing_area_new();
gtk_container_add(GTK_CONTAINER(w), dest);
gtk_widget_set_usize(dest, 352, 288);
g_signal_connect(dest, expose-event, on_expose, NULL);
gtk_widget_set_app_paintable(w, TRUE);
gtk_widget_set_double_buffered(w, FALSE);
gtk_widget_show_all(w);
last_update = get_timer();
double secs = get_timer();
img = gdk_image_new(GDK_IMAGE_FASTEST, gdk_visual_get_system(), 352,
288);
gc = gdk_gc_new(w-window);
g_signal_connect(w, delete-event, (GCallback)gtk_main_quit, NULL);
g_timeout_add(40, (GSourceFunc)draw_func, NULL);
gtk_main();
secs = get_timer() - secs;
g_printf(%d frames in %f seconds, %f fps\n, frames, secs,
(double)frames / secs);
}
--
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0100980150 Fax: +39-0100980184
s-mail: Piazza Della Vittoria 9/3 - 16121 GENOVA (ITALY)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.24.10 memory leak on win32?
On 07/02/2012 04:44 PM, Gabriele Greco wrote: We have found a regression that block us to migrate our existing apps from GTK 2.16.x to GTK 2.24.10 (20120208), it seems there is a memory leak in g_idle_add() use or something related to queue_draw(), anyway the following code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk 2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with GTK 2.24.10 on win32. have you tried running the code in valgrind on Linux to test this for sure? try: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=32 src/your-binary I don't see any obvious problemin your code, but I have no experience with the code you posted. Olivier ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Threads and idle functions
My understanding is that child threads must never alter the UI in any way. If I have a program which spawns a child thread to download some data and I want to be able to have a dialog pop up should an error occur, is it correct to say that I need an idle function to be running concurrently to monitor some global variable which would contain the status (set by the download thread), and then the idle function would create the dialog pop-up? Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get information out of a child thread and to the UI? Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
(sorry forgot list) On 3 July 2012 01:50, David Buchan pdbuc...@yahoo.com wrote: My understanding is that child threads must never alter the UI in any way. If I have a program which spawns a child thread to download some data and I want to be able to have a dialog pop up should an error occur, is it correct to say that I need an idle function to be running concurrently to monitor some global variable which would contain the status (set by the download thread), and then the idle function would create the dialog pop-up? Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get information out of a child thread and to the UI? Well from what I hear, g_idle_add offers some form of thread safety so a child thread can communicate some item of data via a callback executed in the GUI thread. The documentation also seems to support this view: http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description your child/download thread does the monitoring of the error status and when an error is found, use g_idle_add to wait some moments and then communicate the error to a callback. HTH, James. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
On 3 July 2012 02:10, James Morris jwm.art@gmail.com wrote: (sorry forgot list) On 3 July 2012 01:50, David Buchan pdbuc...@yahoo.com wrote: My understanding is that child threads must never alter the UI in any way. If I have a program which spawns a child thread to download some data and I want to be able to have a dialog pop up should an error occur, is it correct to say that I need an idle function to be running concurrently to monitor some global variable which would contain the status (set by the download thread), and then the idle function would create the dialog pop-up? Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get information out of a child thread and to the UI? Well from what I hear, g_idle_add offers some form of thread safety so a child thread can communicate some item of data via a callback executed in the GUI thread. The documentation also seems to support this view: http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description Forgive me if I speak as if the thread safety of g_idle_add is something to be doubted. Multi-threaded applications are typically complicated affairs and the ease of use of g_idle_add rather contrasts with my (non-professional) experience. That being said, there are probably limits to what can be accomplished using it but for basic use-cases such as these it is perfect. your child/download thread does the monitoring of the error status and when an error is found, use g_idle_add to wait some moments and then communicate the error to a callback. HTH, James. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
yep. Seems to be working. Thanks! Dave From: James Morris jwm.art@gmail.com To: David Buchan pdbuc...@yahoo.com Sent: Monday, July 2, 2012 9:10 PM Subject: Re: Threads and idle functions On 3 July 2012 01:50, David Buchan pdbuc...@yahoo.com wrote: My understanding is that child threads must never alter the UI in any way. If I have a program which spawns a child thread to download some data and I want to be able to have a dialog pop up should an error occur, is it correct to say that I need an idle function to be running concurrently to monitor some global variable which would contain the status (set by the download thread), and then the idle function would create the dialog pop-up? Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get information out of a child thread and to the UI? Well from what I hear, g_idle_add offers some form of thread safety so a child thread can communicate some item of data via a callback executed in the GUI thread. The documentation also seems to support this view: http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description your child/download thread does the monitoring of the error status and when an error is found, use g_idle_add to wait some moments and then communicate the error to a callback. HTH, James. Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
Hi David, probably you should use macros: gdk_threads_enter () gdk_threads_leave (). Best regards, Igor 2012/7/3, David Buchan pdbuc...@yahoo.com: My understanding is that child threads must never alter the UI in any way. If I have a program which spawns a child thread to download some data and I want to be able to have a dialog pop up should an error occur, is it correct to say that I need an idle function to be running concurrently to monitor some global variable which would contain the status (set by the download thread), and then the idle function would create the dialog pop-up? Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get information out of a child thread and to the UI? Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
