GNOME Bugzilla – Bug 771959
gtk_init_with_args fails when no display is found / does not comply with its documentation
Last modified: 2017-08-07 17:37:12 UTC
The documentation for gtk_init_with_args: "This function does the same work as gtk_init_check()." However, contrary to gtk_init_check, gtk_init_with_args fails when no display can be found. I'm not sure whether this is a documentation bug or an implementation bug. If it's an implementation bug, it can probably be solved quite easily: the function currently contains the following line: "gtk_group = gtk_get_option_group (TRUE);", the argument for gtk_get_option_group should be FALSE. Furthermore, the function currently returns the return value of g_option_context_parse, while the documentation states: "Returns TRUE if the windowing system has been successfully initialized, FALSE otherwise". I wouldn't mind writing a patch, but as I already mentioned, I'm not sure whether this is a case of buggy documentation or buggy implementation.
The documentation should probably say: This function does the same work as gtk_init().
(In reply to Matthias Clasen from comment #1) > The documentation should probably say: This function does the same work as > gtk_init(). That makes it easy then. I'm not sure if I'm getting the line width style right, but I made a small patch to fix the documentation. I'm not quite sure how to describe the return value, it can mean multiple things right now I believe but usually whether parsing succeeded or not so I went with that. Should it describe the odd case scenarios as well? (e.g. if gtk_initialized is true). Maybe "TRUE if GTK+ was already initialized or if parsing succeeded, FALSE if initialization failed or parsing errors occurred"? Sorry for blowing up a trivial issue.
Created attachment 336280 [details] [review] Patch proposal As mentioned in the comment I made earlier (https://bugzilla.gnome.org/show_bug.cgi?id=771959#c2)
I decided to go the other way instead, and make the function do what the docs say.
Found this via bug 783624. (In reply to Steef Hegeman from comment #0) > The documentation for gtk_init_with_args: "This function does the same work > as gtk_init_check()." > > However, contrary to gtk_init_check, gtk_init_with_args fails when no > display can be found. > > I'm not sure whether this is a documentation bug or an implementation bug. > If it's an implementation bug, it can probably be solved quite easily: the > function currently contains the following line: "gtk_group = > gtk_get_option_group (TRUE);", the argument for gtk_get_option_group should > be FALSE. I don't understand why that should be so. With gtk_get_option_group (TRUE), the following g_option_context_parse call will try to parse the commandline arguments, and try to open a display. If any of those two things fail it will return FALSE and set the error. At least that's my understanding from the reading gtk/gtkmain.c and glib/goption.c. This seems correct to me. > Furthermore, the function currently returns the return value of > g_option_context_parse, while the documentation states: "Returns TRUE if the > windowing system has been successfully initialized, FALSE otherwise". That's a good point. :) gtk_init_check and gtk_init_with_args should return TRUE only when both the commandline is valid and a display could be opened. The documentation seems to suggest that the outcome of parsing the commandline doesn't matter, but that's not true. It doesn't match with the implementation or the behaviour people have gotten used to.
Created attachment 356124 [details] [review] docs: gtk_init_check will also fail if the commandline was invalid
Created attachment 356125 [details] [review] docs: gtk_init_with_args will also fail if the commandline was invalid
*** Bug 783624 has been marked as a duplicate of this bug. ***
Created attachment 356128 [details] [review] main: Set the error if gtk_init_with_args fails
All this is strictly gtk-3-22 material. gtk_init_with_args is gone, and gtk_init_check doesn't handle commandline arguments anymore.
Review of attachment 356124 [details] [review]: ok
Review of attachment 356125 [details] [review]: sure
Review of attachment 356128 [details] [review]: ok