GNOME Bugzilla – Bug 154486
FileChooserDialog buttons should have reasonable default.
Last modified: 2006-04-02 19:34:20 UTC
When creating a FileChooserDialog, it really should default to having OK and Cancel buttons, since almost every single dialog wants those, and not no buttons as is the current default. So change the current definition from: gtk.FileChoose gtk.FileChooserDialog(title=None, parent=None, action=gtk.FILE_CHOOSER_ACTION_OPEN, buttons=None, backend=None)rDialog(title=None, parent=None, action=gtk.FILE_CHOOSER_ACTION_OPEN, buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, gtk.STOCK_OPEN, gtk.RESPONSE_OK), backend=None) to:
this is extremely annoying, since it breaks every glade applications which try to use FileChooserDialog...
Created attachment 36384 [details] [review] fix Problem is that tp_new was not being called, then I discovered a couple of other minor issues.
oops, wrong bug report! :P
I think this kind of requests should be reported to gtk+ not to pygtk product. Don't forget that pygtk wraps gtk+ widgets, cannot this bug be closed or at least moved to gtk?
Sorry, this can't be fixed. We are not allowed to break the API, and changing defaults is breaking the API.
Well, we can if we really want to, but we have to ask for permission from the release team. I think this particular change is a good one. It'll change the following code though, which I do not thing is very common: fc = gtk.FileChooser() fc.add_buttons(gtk.STOCK_OPEN, gtk.RESPONSE_OK) But that can also be fixed, by checking how many buttons there are in the dialog before adding.
Note: even if we get permission, we shouldn't change this within a stable series, only for 2.8 version.
doesn't seem to have happened for 2.8, either; I've reproduced the same problem on my instalation of pygtk2.8; this seems to cause problems for gazpacho, too, btw (there is a very similar bug WRT this filled for gazpacho)
Sorry, this can't be fixed without breaking the API. I'm closing this as WONTFIX.