multithreaded gtk app
Hi everybody,
I'm having troubles debugging a multithreaded gtk app I made.
The app creates an animation in the main window by continuously
displaying a scrolled pixmap and uses its GUI to modify animation
parameters. The animated zone in the main window is updated by
g_timeout_add_full(..., handler, ...) and the timeout handler uses
gdk_draw_drawable() to draw on a gdk drawing area in the main
window.
The animation works fine but the app always crashes after opening a few
other windows (using the GUI) and I get either a segfault or this
pthread error:
Assertion 'pthread_setspecific(t-key, userdata) == 0' failed at
pulsecore/thread-posix.c:200, function pa_tls_set(). Aborting.
Basically, the app looks like this:
gint handler()
{
gdk_threads_enter();
if (...) {
/* display a different part of the pixmap each time */
gdk_draw_drawable(drawing_area, pixmap, parameters);
gdk_threads_leave;
return TRUE;
}
else {
create a new pixmap
g_timeout_add_full(..., delay, handler, ...);
gdk_threads_leave;
return FALSE;
}
}
int main(...)
{
...
if (!g_thread_supported())
g_thread_init(NULL);
gdk_threads_init();
gdk_threads_enter();
gtk_init(argc, argv);
...
g_timeout_add_full(..., delay, handler, ...);
gtk_widget_show_all(...);
gtk_main();
gtk_threads_leave();
return 0;
}
To compile, I also have added these flags:
-g -D G_ERRORCHECK_MUTEXES `pkg-config --libs gtk+-2.0 gthread-2.0`
Did I made something wrong with gdk threads, or do I miss something or...?
Then the extra problem is I don't know much about multithread app debugging
(and I've already been searching the f** web a lot!)
Any clue will be welcome because I'm a really stuck at the moment.
Thanks in advance.
Emmanuel Thomas-Maurin
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
window background transparent
Hi, I'm trying to set a gtk window transparent. I'm using this gtk hello world example. http://library.gnome.org/devel/gtk-tutorial/2.18/c39.html#SEC-HELLOWORLD And I'm adding gtk_window_set_opacity(GTK_WINDOW(window), 0.5); but window does not get transparent. I'm trying to call gtk_window_set_opacity both before gtk_widget_show and after. Neither way works. I'm using xfce and transparent window configurations works fine. Also, I can set my hello world gtk window transparent with transset. I investigated, and discovered that both transset and libgtk uses XChangeProperty in the same way, but window id is different in transset and libgtk. when using xprop on window id used by transset, I get: $ xprop -id 15825983 _NET_WM_WINDOW_OPACITY(CARDINAL) = 2147483647 on window id used by libgtk, I get: $ xprop -id 48234499 _NET_WM_ICON_GEOMETRY(CARDINAL) = 709, 772, 194, 28 _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 22, 4 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK WM_STATE(WM_STATE): window state: Normal icon window: 0x1067a30 _NET_WM_DESKTOP(CARDINAL) = 0 _WIN_WORKSPACE(CARDINAL) = 0 _WIN_STATE(CARDINAL) = 0 _NET_WM_STATE(ATOM) = WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x2e1 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 48234501 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x2e4 WM_CLIENT_LEADER(WINDOW): window id # 0x2e1 _NET_WM_PID(CARDINAL) = 9263 WM_LOCALE_NAME(STRING) = fr_FR.UTF-8 WM_CLIENT_MACHINE(STRING) = bendonkey WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 104 by 45 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = hello, Hello WM_ICON_NAME(STRING) = hello _NET_WM_ICON_NAME(UTF8_STRING) = 0x68, 0x65, 0x6c, 0x6c, 0x6f WM_NAME(STRING) = hello _NET_WM_NAME(UTF8_STRING) = 0x68, 0x65, 0x6c, 0x6c, 0x6f Do you have any idea where how I can solve this problem ? On a related note, I'm wondering if and how it is possible to have a window whose background is semi-transparent but whose contained widgets (GtkButton, ...) are not. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multithreaded gtk app
Hi, 2010/1/20 Manu TM manutm...@gmail.com: I'm having troubles debugging a multithreaded gtk app I made. Basically, the app looks like this: You need to post a complete small program that people can compile and run. Though from your fragment it doesn't look like you are using threads, just timeouts. ARe you sure you want a multi-threaded GTK application? John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ComboBox submenus
Hi Tadej,
1) you were right, titles in combobox submenus can be easily removed
calling gtk_cell_layout_set_cell_data_func, as demonstrated in gtk-demo.
2) I also found that the width of submenus can be easily set, with the
property width-chars, applied to the cell_renderer.
I posted the relevant code below, in case it helps someone else.
Many thanks to Tadej Borovšak and Matthias Clasen, for clarifying this,
Carlos
renderer = gtk_cell_renderer_text_new ();
gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (combo), renderer, FALSE);
gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (combo), renderer,
text, 0, NULL);
/* set the same width in chars for all submenus */
g_object_set (renderer, width-chars, 12, NULL);
/* hide the submenu titles */
gtk_cell_layout_set_cell_data_func (GTK_CELL_LAYOUT (combo),
renderer, hide_titles, NULL, NULL);
void hide_titles (GtkCellLayout *layout, GtkCellRenderer *renderer,
GtkTreeModel *model, GtkTreeIter *iter, void *data)
{
int sensitive;
sensitive = TRUE;
if (gtk_tree_model_iter_has_child (model, iter) == TRUE)
sensitive = FALSE;
g_object_set (renderer, sensitive, sensitive, NULL);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Receiving a callback on GDK window destroy
I do get one XID per instance, but that XID is created by Firefox's plugin host code in GtkSocket's internal GdkWindow. So the XID is already mapped to that GdkWindow by the time NPP_SetWindow runs, hence gdk_window_foreign_new() just returns a pointer to that pre-existing GdkWindow, so the parentage tree that _gdk_window_destroy_hierarchy traverses is still hooked up. But after some more hacking I was able to figure out a work-around. gdk_window_foreign_new() only re-uses the existing GdkWindow if the GdkDisplay pointers match, and gdk_display_open does _not_ re-use existing connections! So by explicitly opening the display and using gdk_window_foreign_new_for_display I was able to force it to really use a foreign window, and now I get all the expected callbacks (unmap, delete, unrealize). In fact, with the _for_display() trick I can use a GtkPlug and get the same callbacks just fine. So the code I eventually settled on is basically this: // Re-open the X11 connection gdk_display_ = gdk_display_open(XDisplayString(display)); // Create plug. gtk_plug_ = gtk_plug_new_for_display(gdk_display_, windowId); // Stop the browser from destroying our GtkPlug too soon. g_signal_connect(G_OBJECT(gtk_plug_), delete-event, G_CALLBACK(gtk_widget_hide_on_delete), NULL); Thanks for the help! On 19 January 2010 20:55, Kevin DeKorte kdeko...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/10 20:29, Tristan Schmelcher wrote: Actually, after debugging and looking at the code, it seems that gdk_window_foreign_new() first looks up if there is already a GdkWindow for that XID and re-uses it if so (gdk/x11/gdkwindow-x11.c:1008). So I don't think this approach will work. :( You must be doing something wrong since you should get one xid per windowed plugin instance. I've been using this method for years in both the mplayerplug-in plugin and the gecko-mediaplayer plugin. Take a look at either of those projects source code. I'm sure there is something there that will help you. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7D0BD5D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktWjNQACgkQ6w2kMH0L1dG7vACcDZNHS0dTEbXCTHD0IesjVmeF BCsAn3oewKsZFv/Dv6uV3vfKgR6k7iJl =uFlq -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: multithreaded gtk app
On Wed, 2010-01-20 at 17:05 +0100, Manu TM wrote: gdk_threads_leave; Just in case you posted actual code snippets, not mangled code: the quoted line (repeated in the else branch) is not a function call, and you'll probably get some problems from keeping the lock. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Bug 602733] Extended Input with Xinerama
On 11/25/2009 10:40 PM, gtk+ (bugzilla.gnome.org) wrote:
https://bugzilla.gnome.org/show_bug.cgi?id=602733
gtk+ | gdk | unspecified
Matthias Clasen mclasen changed:
What|Removed |Added
CC||mcla...@redhat.com
--- Comment #1 from Matthias Clasen mcla...@redhat.com 2009-11-25 21:40:52
UTC ---
This will have to be redone against the xi2 branch which we are going to merge
sometime soon. But I am dubious about the claims here.
[...] still behaves as if the tablet weren't
restricted to only a single screen, even though the normal cursor knows
better
and stays at the same screen.
What is restricting the 'normal cursor' to a single screen here ? And is the
'normal cursor' the core pointer, or the tablet ?
Finally, is your setup really two screens, or is it to monitors that form a
single screen ?
Once again I submit the patch for a working tablet (extended input
support) with GTK (e.g. in Inkscape and GIMP) when using Xinerama and
Screen Mode for the Input device.
Patch was made with git diff xinerama.diff, if there's something wrong
with that please let me know
--
Cheers,
Alex
diff --git a/gdk/x11/gdkinput-x11.c b/gdk/x11/gdkinput-x11.c
index 767b070..77f1ef0 100644
--- a/gdk/x11/gdkinput-x11.c
+++ b/gdk/x11/gdkinput-x11.c
@@ -454,11 +454,18 @@ gdk_input_translate_coordinates (GdkDevicePrivate *gdkdev,
if (gdkdev-info.mode == GDK_MODE_SCREEN)
{
- x_scale = gdk_screen_get_width (gdk_drawable_get_screen (window)) / device_width;
- y_scale = gdk_screen_get_height (gdk_drawable_get_screen (window)) / device_height;
-
- x_offset = - impl_window-input_window-root_x - priv-abs_x;
- y_offset = - impl_window-input_window-root_y - priv-abs_y;
+ int core_pointer_x, core_pointer_y, cur_monitor;
+ GdkRectangle mon_geometry;
+ GdkScreen *cur_screen;
+ gdk_display_get_pointer (gdk_drawable_get_display (window), cur_screen, core_pointer_x, core_pointer_y, 0);
+ cur_monitor = gdk_screen_get_monitor_at_point (cur_screen, core_pointer_x, core_pointer_y);
+
+ gdk_screen_get_monitor_geometry (cur_screen, cur_monitor, mon_geometry);
+ x_scale = mon_geometry.width / device_width;
+ y_scale = mon_geometry.height / device_height;
+
+ x_offset = - impl_window-input_window-root_x - priv-abs_x + mon_geometry.x;
+ y_offset = - impl_window-input_window-root_y - priv-abs_y + mon_geometry.y;
}
else/* GDK_MODE_WINDOW */
{
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: segfault in find_native_sibling_above_helper from gtk+2.18.6
i compiled gtk+2.18.6 for use with directfb on an arm target. As far as I know, there isn't really anybody supporting the directfb stuff, so if you compile it, you also debug it ;) Sure, you can file a bug, too. Mailing this list is probably not useful. --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
(GLib) How to remove a Child Watch source that is not needed any more?
Hi all, I use g_child_watch_source_new() to get notified when a spawned process exits. It works as expected, but if I ever need to stop taking care of it, this is, the parent process doesn't need to check if the child process is still being executed, I see that I cannot detach it from the main context properly with g_source_destroy(): the GSource still seems to be valid after that, and valgrind reports a FD leak for each Child Watch source that didn't get fired up when parent process exits. So, is there a safe and clean way to remove those Child Watch sources from the main context? Cheers, -Aleksander ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
dispose and finalize
Hi, what's the difference between dispose and finalize? And which members have to be freed in which of these functions? Thanks ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dispose and finalize
On Wed, 20 Jan 2010 17:56:18 +0100 Martin Kalbfuß wrote: what's the difference between dispose and finalize? And which members have to be freed in which of these functions? See http://library.gnome.org/devel/gobject/unstable/gobject-memory.html The difference in short: dispose: - g_object_unref() all GObject member variables - function must be safe against being called multiple times finalize: - free all other (non-GObject) members, close file descriptors etc Holger ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (GLib) How to remove a Child Watch source that is not needed any more?
Hi again, I use g_child_watch_source_new() to get notified when a spawned process exits. It works as expected, but if I ever need to stop taking care of it, this is, the parent process doesn't need to check if the child process is still being executed, I see that I cannot detach it from the main context properly with g_source_destroy(): the GSource still seems to be valid after that, and valgrind reports a FD leak for each Child Watch source that didn't get fired up when parent process exits. So, is there a safe and clean way to remove those Child Watch sources from the main context? I dug in the source code responsible for creating the Child Watch in GLib, and found that to implement the watch for the child process, GLib will eventually create a new thread performing a blocking read() in a pipe with the child process (child_watch_helper_thread). Thus, even if we do the g_source_destroy() for that GSource to detach it from the main context, the thread will still be there stuck in the blocking read() in the pipe, at least until the child process exits. Then the answer would be no to my question, right? Cheers, -Aleksander ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dispose and finalize
OK Thanks, So if I have a Garray member, I call g_array_unref in finalize, because it isn't a child of GObject. Correct? Am Mittwoch, den 20.01.2010, 17:24 +0100 schrieb Holger Berndt: On Wed, 20 Jan 2010 17:56:18 +0100 Martin Kalbfuß wrote: what's the difference between dispose and finalize? And which members have to be freed in which of these functions? See http://library.gnome.org/devel/gobject/unstable/gobject-memory.html The difference in short: dispose: - g_object_unref() all GObject member variables - function must be safe against being called multiple times finalize: - free all other (non-GObject) members, close file descriptors etc Holger ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
g_assert vs. g_return_if_fail
Hi, I don't understand the need for g_return_if_fail like functions. Why not use g_assert here? In pure C, I used either assert for programming errors or returned an error indicator for expected errors. But where to use g_return_if_fail? Thanks. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dispose and finalize
On Wed, 20 Jan 2010 18:20:39 +0100 Martin Kalbfuß wrote: So if I have a Garray member, I call g_array_unref in finalize, because it isn't a child of GObject. Correct? Actually, I would decrement the reference count of all reference counted objects in dispose. Speaking of GObject is probably an over-simplification. I am not sure if that's strictly required, but it sounds safer anyways. Holger ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dispose and finalize
20.01.10, 17:56, Martin Kalbfuß ma.kalbf...@web.de: Hi, what's the difference between dispose and finalize? And which members have to be freed in which of these functions? Thanks In dispose you should drop all references to other GObjects. In finalize you free other data (char *, GArray *, etc.) dispose can be invoked more than one time before finalize. See also [1], specifically last section. [1] http://library.gnome.org/devel/gobject/stable/gobject-memory.html -- Artur ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 01/20/2010 12:28 PM, Martin Kalbfuß wrote: Hi, I don't understand the need for g_return_if_fail like functions. Why not use g_assert here? In pure C, I used either assert for programming errors or returned an error indicator for expected errors. But where to use g_return_if_fail? g_assert aborts the process, g_return_if_fail() doesn't. It's a disastrous idea to g_assert() in a library for example. behdad Thanks. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 01/20/2010 02:03 PM, Martin Kalbfuß wrote: Thanks, But why is it a disastrous idea? When It's a clear programming error, why not abort the program with g_assert? Because that can cause user data loss. behdad Am Mittwoch, den 20.01.2010, 12:23 -0500 schrieb Behdad Esfahbod: On 01/20/2010 12:28 PM, Martin Kalbfuß wrote: Hi, I don't understand the need for g_return_if_fail like functions. Why not use g_assert here? In pure C, I used either assert for programming errors or returned an error indicator for expected errors. But where to use g_return_if_fail? g_assert aborts the process, g_return_if_fail() doesn't. It's a disastrous idea to g_assert() in a library for example. behdad Thanks. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
GtkFileChooser and set_filter after set_file
Hi, how can I set the active FileFilter in a GtkFileChooser when I set/select a file? I tried gtk_file_chooser_set_file (GTK_FILE_CHOOSER (dialog), file, NULL); gtk_file_chooser_set_filter (GTK_FILE_CHOOSER (dialog), filefilter); and some variants (select_file, adding the filter before setting it, setting the filter before setting the file, ...) For new files I use gtk_file_chooser_set_current_folder_file (GTK_FILE_CHOOSER (dialog), folder_file, NULL); gtk_file_chooser_set_current_name (GTK_FILE_CHOOSER (dialog), name); gtk_file_chooser_set_filter (GTK_FILE_CHOOSER (dialog), filefilter); and it works just fine. What did I miss? Thanks, Joerg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
Behdad Esfahbod píše v St 20. 01. 2010 v 13:18 -0500: On 01/20/2010 02:03 PM, Martin Kalbfuß wrote: Thanks, But why is it a disastrous idea? When It's a clear programming error, why not abort the program with g_assert? Because that can cause user data loss. behdad So there are two possibilities: g_assert when you want the application to abort, and g_return_if_fail when you don't. g_assert can be disabled compile-time for a release, right? In that case, it does nothing. So why not add a compile option to make g_return_if_fail fatal, and simply deprecate g_assert? What is the point of having it there? signature.asc Description: Toto je digitálně podepsaná část zprávy ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 21.01.2010 0:38, Jiří Zárevúcky wrote:
Behdad Esfahbod píše v St 20. 01. 2010 v 13:18 -0500:
On 01/20/2010 02:03 PM, Martin Kalbfuß wrote:
Thanks,
But why is it a disastrous idea?
When It's a clear programming error, why not abort the program with
g_assert?
Because that can cause user data loss.
behdad
So there are two possibilities: g_assert when you want the application
to abort, and g_return_if_fail when you don't. g_assert can be disabled
compile-time for a release, right? In that case, it does nothing.
So why not add a compile option to make g_return_if_fail fatal, and
simply deprecate g_assert? What is the point of having it there?
Myself, i've always viewed g_return_if_fail as a convenience macro that
i could use instead of if (!blah) { g_log_warning(bar); return foo; }.
And, AFAIK, it also logs warnings.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 01/20/2010 04:38 PM, Jiří Zárevúcky wrote: Behdad Esfahbod píše v St 20. 01. 2010 v 13:18 -0500: On 01/20/2010 02:03 PM, Martin Kalbfuß wrote: Thanks, But why is it a disastrous idea? When It's a clear programming error, why not abort the program with g_assert? Because that can cause user data loss. behdad So there are two possibilities: g_assert when you want the application to abort, and g_return_if_fail when you don't. g_assert can be disabled compile-time for a release, right? In that case, it does nothing. So why not add a compile option to make g_return_if_fail fatal, and simply deprecate g_assert? What is the point of having it there? Can you please first state the problem you are trying to solve? behdad ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
But shouldn't the function return GError in such a case? g_return_if_fail is like retunring an error without the ability to handle it. I'm still not sure when to use it. I assume g_assert is only useful in programs and internal library functions. Am Donnerstag, den 21.01.2010, 00:41 +0300 schrieb LRN: nd, AFAIK, it also logs warnings. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 01/20/2010 05:40 PM, Martin Kalbfuß wrote: But shouldn't the function return GError in such a case? g_return_if_fail is like retunring an error without the ability to handle it. I'm still not sure when to use it. g_return_if_fail() should be used to catch programmer error ONLY. There is no point in returning a GError in such cases. behdad I assume g_assert is only useful in programs and internal library functions. Am Donnerstag, den 21.01.2010, 00:41 +0300 schrieb LRN: nd, AFAIK, it also logs warnings. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
Behdad Esfahbod píše v St 20. 01. 2010 v 16:48 -0500: On 01/20/2010 04:38 PM, Jiří Zárevúcky wrote: Behdad Esfahbod píše v St 20. 01. 2010 v 13:18 -0500: On 01/20/2010 02:03 PM, Martin Kalbfuß wrote: Thanks, But why is it a disastrous idea? When It's a clear programming error, why not abort the program with g_assert? Because that can cause user data loss. behdad So there are two possibilities: g_assert when you want the application to abort, and g_return_if_fail when you don't. g_assert can be disabled compile-time for a release, right? In that case, it does nothing. So why not add a compile option to make g_return_if_fail fatal, and simply deprecate g_assert? What is the point of having it there? Can you please first state the problem you are trying to solve? behdad No problem. I'm just wondering why there are two methods that do the same thing just slightly differently, while one of them shouldn't be used. So I guess my question is: What are the use cases for g_return_if_fail and what are the use cases for g_assert? (GLib newbie here) signature.asc Description: Toto je digitálně podepsaná část zprávy ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 01/20/2010 05:04 PM, Jiří Zárevúcky wrote: Behdad Esfahbod píše v St 20. 01. 2010 v 16:48 -0500: On 01/20/2010 04:38 PM, Jiří Zárevúcky wrote: Behdad Esfahbod píše v St 20. 01. 2010 v 13:18 -0500: On 01/20/2010 02:03 PM, Martin Kalbfuß wrote: Thanks, But why is it a disastrous idea? When It's a clear programming error, why not abort the program with g_assert? Because that can cause user data loss. behdad So there are two possibilities: g_assert when you want the application to abort, and g_return_if_fail when you don't. g_assert can be disabled compile-time for a release, right? In that case, it does nothing. So why not add a compile option to make g_return_if_fail fatal, and simply deprecate g_assert? What is the point of having it there? Can you please first state the problem you are trying to solve? behdad No problem. I'm just wondering why there are two methods that do the same thing just slightly differently, while one of them shouldn't be used. So I guess my question is: What are the use cases for g_return_if_fail and what are the use cases for g_assert? (GLib newbie here) g_return_if_fail() should be used at the beginning of functions, to check that the input arguments are valid. Specially useful in libraries, where the calling code is not written by the author of library. g_assert() is used to check for a condition that must always be true, aka invariants. Should be avoided in libraries except for things that are very, very, very, very hard to fail. behdad ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
I understand when to use g_return_if_fail. But still not why. The essential question is, why not to use g_assert in libraries. I haven't understood the data loss problem. And is this the only reason? Why should a caller of a library function be able to ignore a programming error? I'm implementing a storage for ALLEGRO_BITMAP types, used both internally and as API for external code. Am Mittwoch, den 20.01.2010, 16:58 -0500 schrieb Behdad Esfahbod: On 01/20/2010 05:40 PM, Martin Kalbfuß wrote: But shouldn't the function return GError in such a case? g_return_if_fail is like retunring an error without the ability to handle it. I'm still not sure when to use it. g_return_if_fail() should be used to catch programmer error ONLY. There is no point in returning a GError in such cases. behdad I assume g_assert is only useful in programs and internal library functions. Am Donnerstag, den 21.01.2010, 00:41 +0300 schrieb LRN: nd, AFAIK, it also logs warnings. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
Hi Jiří, On Wed, 20 Jan 2010 23:04:34 +0100 you wrote: No problem. I'm just wondering why there are two methods that do the same thing just slightly differently, They're not the same thing - one of them gives up on a particular function, the other aborts the application. while one of them shouldn't be used. I don't believe anyone said that. Somebody did say that g_assert should not be used where g_return_if_fail is used, because they do different things. So I guess my question is: What are the use cases for g_return_if_fail and what are the use cases for g_assert? (GLib newbie here) You should use g_assert in code under development to make explicit the assumptions of that code. So if your function does not handle the case of SomeVariable being negative, because you cannot envisage a case where it could ever be negative, then it is appropriate to add g_assert ( SomeVariable = 0 ) at that point. If your assumption turns out to be wrong then it will become obvious during development. You should use g_return_if_fail to cope with bad arguments to functions when you don't have control of the caller. This is the case in library functions, of course, which is why Gtk widget implementations use it a lot. For example, in the gtk_label_set_text implementation there's several g_return_if_fail tests of the first argument being a pointer to a GtkLabel, and the second being some text. If the programmer using the library gets this wrong it's not up to the library to crash his program for him; that would be damned annoying at the very least. But if the check wasn't there and the programmer got it wrong then the library probably would crash with a mystery segfault. So writers of libraries should use g_return_if_fail liberally, because it protects the user of the library and provides more helpful responses to mistakes. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: State of Gtk+-2.18 On Windows
On Thu, 2009-10-01 at 05:08 +0300, Tor Lillqvist wrote: As I am currenlty unable to test, could someone please advise me on the state of Gtk+-2.18 on windows? Try it, there are binaries in http://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.18/ . You will need up-to-date dependencies too, in hopefully self-evident locations near to that. I just got around to trying this, in the process of building up to date PyGtk+ installers for windows (see https://bugzilla.gnome.org/show_bug.cgi?id=589671) It is worse than I thought. gtk-demo isn't close to working. Filed as https://bugzilla.gnome.org/show_bug.cgi?id=607603 John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
OK, Many thanks. That's a good reason not to use g_assert, in such a place. But when the caller should have the ability to handle the error, why not use GError? Isn't it exactly doing this? Indicate an error, but don't abort the program on it's own? Wrong input from a user is not a programming error. Also if your library is re-compiled with the option to remove assert then it won't have any checking any more ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_assert vs. g_return_if_fail
On 21.01.2010 3:14, Martin Kalbfuß wrote: OK, Many thanks. That's a good reason not to use g_assert, in such a place. But when the caller should have the ability to handle the error, why not use GError? Isn't it exactly doing this? Indicate an error, but don't abort the program on it's own? GError is for internal errors (errors that may or may not happen, i.e. I/O, or something that is beyond library's control, such as ACL). One of the things that Windows does wrong is that it uses the same mechanism (GetLastError()) for BOTH system errors (such as I/O failing) and programming errors (wrong arguments). It will often return the same error, arguments are wrong, and it's up to you to guess which arguments are wrong. With g_return_if_fail() you don't have to guess. Besides, i've seen a few cases when g_return_if_fail() actually returns and a message is logged, but application continues to function (because the function that failed was not critical, or there was code to handle afailure). From user's point of view, that's MUCH better than crashing. Also, when you're working with GObject, you may come across scripting languages repeatedly using your functions in strange ways. Crashing on them is certainly a bad idea. Wrong input from a user is not a programming error. Programming error is the lack of checking of the user input which is, by definition, unreliable (same could be said about data that came from the network). ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Custom TreeModel
Emmanuel Rodriguez emmanuel.rodrig...@gmail.com writes: Holding to the strings has the same issue as holding to the XmlNodes. I endup duplicating the model in memory and I don't know when you release them. Oh, if you set iters-persist per your first post then the iter has to be good for as long as the row exists. If you don't set that then iters only have to be good until the next change to the model. For no-persist a trick is to change your stamp on each change to the model, as a way to notice if the app passes in a stale iter. For iters-persist it's possible to change stamp when the last row is deleted, but that's not as important since iters last longer. Either way an application could certainly walk the whole model and take an iter to every single row ... thus the idea is to have something compact, like memory address, or row number, or pair of coordinates, etc. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
