GNOME Bugzilla – Bug 345822
value of "name" attribute of gtk.AboutDialog not getting set
Last modified: 2011-02-04 16:11:01 UTC
After setting the "name" property of an instance of gtk.AboutDialog, the value is not reflected in the value of the "name" attribute of the python object. This works fine for normal dialogs, so it may have something to do with the fact that by default, AboutDialog.get_name returns the value of g_get_application_name() if AboutDialog.set_name has been called. Note that AboutDialog.get_name works fine. Eg: mjg@continuity:~/data/projects/vee.net/mechanistic$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gtk >>> >>> dialog = gtk.Dialog() >>> dialog.set_name('foo') >>> dialog.get_name() 'foo' >>> dialog.name 'foo' >>> >>> dialog = gtk.AboutDialog() >>> dialog.set_name('foo') >>> dialog.get_name() 'foo' >>> dialog.name >>> If someone can point me vaguely in the right direction, I'll have a go at fixing this (after my exam on Wednesday).
gtk_about_dialog_set_name/gtk_about_dialog_get_name work on a data item that is completely different from gtk_widget_set_name/gtk_widget_get_name. widget.name calls gtk_widget_get_name. This is one more case of the C libraries forgetting about object orientation issues; you shouldn't redefine a method in a subclass with different semantics. I think this is unfixable (remember we can't break API even if it is wrong).
Apologies for a possibly lame suggestion (I'm not really sure how the bindings are implemented), but would it be possible for the binding's implementation of set_name on gtk.AboutDialog to call both gtk_about_dialog_set_name and gtk_widget_set_name?
""" gtk.AboutDialog.set_name(): The set_name() method sets the "name" property to the string contained in name. The "name" property is used as the program name in the about dialog. If name is None, it defaults to g_get_application_name(). gtk.Widget.get_name(): The set_name() method sets the "name" property of the widget to the string specified by name. Widgets can be named, which allows you to refer to them in a GTK resource file. """ So definitely not, the two functions have very different semantics.
Ahh right, I was operating under the assumption that AboutDialog was overriding the name, not overloading it. So I'll see if I can work around this, but is it worth it if I filed a bug against the actual gtk GtkAboutDialog class? Maybe gtk_about_dialog_set_name/gtk_about_dialog_get_name should be deprecated and a non-brokenly-named replacement added?
It is way too late for gtk+ 2.10, but maybe deprecating/renaming to gtk_about_dialog_set_program_name/gtk_about_dialog_get_program_name is the way to go...
Note that dialog.name is not intended to work that way; it's an attribute of gtk.Widget (which maps internally to a property), not a property. Even when the collision is fixed, dialog.name will not work as you want; you want dialog.props.name, which does work correctly with gtk.AboutDialog.set_name/gtk.AboutDialog.get_name. There is an unambiguous way to access either of the properties in Python, by using the unbound methods: >>> dialog = gtk.AboutDialog() >>> dialog.props.name = "name for about dialog" >>> dialog.props.name 'name for about dialog' >>> gtk.Widget.set_name(dialog, "foobar") >>> dialog.props.name 'name for about dialog' >>> dialog.name 'foobar' >>> dialog.get_name() 'name for about dialog' >>> gtk.Widget.get_name(dialog) 'foobar' So this bug is not quite as severe as it's made out to be. AboutDialog works as intended; gtk.Widget doesn't, but widget names are rarely used and can still be accessed when needed.
I should also say, contrary to Matthias's message to gtk-devel-list, this is present since GTK+ 2.6, when the AboutDialog was introduced. The above code is running on GTK+ 2.8. It's not new in 2.10.
It would be nice to make the property of GtkAboutDialog to be a proxy of the widget property, g_object_set("name") will fail otherwise, since it just sets the about dialog property and not the widget property. It's specially important for ui builders which uses the name quite extensivly. A possible workaround is to call gtk_widget_set_name instead of setting the properly.
(In reply to comment #2) > Apologies for a possibly lame suggestion (I'm not really sure how the bindings > are implemented), but would it be possible for the binding's implementation of > set_name on gtk.AboutDialog to call both gtk_about_dialog_set_name and > gtk_widget_set_name? this is a very bad idea, broken gtk APIs shouldn't be worked around in a single langauge binding. that just gets us 2 problems instead of fixing the 1 we currently have.
(In reply to comment #1) > gtk_about_dialog_set_name/gtk_about_dialog_get_name work on a data item that is > completely different from gtk_widget_set_name/gtk_widget_get_name. widget.name > calls gtk_widget_get_name. > > This is one more case of the C libraries forgetting about object orientation > issues; you shouldn't redefine a method in a subclass with different semantics. while your comment about changing semantics is correct, this is unrelated to the implementation being a C library. you can shoot yourself this way with almost every OO language. > I think this is unfixable (remember we can't break API even if it is wrong). > we can deprecate and that is the only sane thing to do here. i.e. GtkAboutDialog::name, gtk_about_dialog_get_name, gtk_about_dialog_set_name all have to be deprecated and at the same time substitutes (say using ::app-name and _app_name) should be supplied. anyone care to cook up a patch for this?
> we can deprecate and that is the only sane thing to do here. > i.e. GtkAboutDialog::name, gtk_about_dialog_get_name, gtk_about_dialog_set_name > all have to be deprecated and at the same time substitutes (say using > ::app-name and _app_name) should be supplied. That's not enough, since setting the name property of a GtkAboutDialog will still just set the deprecated property and not the "real" name property on GtkWidget.
(In reply to comment #11) > > we can deprecate and that is the only sane thing to do here. > > i.e. GtkAboutDialog::name, gtk_about_dialog_get_name, gtk_about_dialog_set_name > > all have to be deprecated and at the same time substitutes (say using > > ::app-name and _app_name) should be supplied. > > That's not enough, since setting the name property of a GtkAboutDialog will > still just set the deprecated property and not the "real" name property on > GtkWidget. right. i think we can either deprecate GtkAboutDialog::name for 2.12 and in 2.14 remove this property so GtkWidget::name is accessible again. or we act more rigorously and just deprectae _set_name/_get_name and remove GtkAboutDialog::name right away for 2.12. Matthias do you have any preference on this? (as usual, i personally prefer the more rigorous fix)
Created attachment 88160 [details] [review] deprecates _set_name() and makes "name" --> "program-name" This patch basically deprecates the _set_name() apis, adds a _set_program_name() api, makes the effected property become "program-name" and thus reexposes the gtkwidgetclass level "name" property.
Ok, since GtkAboutDialog falls back to g_get_application() name, I think the rigorous approach is probably ok. Of course, we should put it prominently in the release notes.
Created attachment 88166 [details] [review] same patch with header file included (oops) ok that other, albiet trivial patch forgot to include the changes made to the header file, so attaching this new one, umm are there objections to me committing this one ?
A few more things: - Please add deprectation guards around the deprecated functions in the header - Please add some blurb for the release notes in README.in (just add a section "Release notes for 2.12" before the 2.10 section) - Deprectation notes can be versioned too, nowadays, and we should do that. I believe the syntax is something like Deprecated:2.12: blablal
Created attachment 88171 [details] [review] take 3 Ok changes made complete with changelog entry.
Thanks, looks good to commit.
Ok done, closing this one.