Decision on file chooser error reporting
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Cc: gnome-release-team gnome org, language-bindings gnome org
- Subject: Decision on file chooser error reporting
- Date: Thu, 04 Mar 2004 15:47:02 -0500
I spent some time looking through all uses of GtkFileChooser in
GNOME modules, and reading people's mails, and the decision I
think we should take is:
We should add gboolean returns to file chooser functions that
can fail, but we will not added GError * arguments to existing
functions.
In the future, we'll have the option of adding additional API
to expose a GError * if there is demand.
Reasoning:
* I think at this point we need to really prioritize sticking
to the schedule. Is this "pandering" to the GNOME release
requirements? To some extent, yes. GNOME is a very important
user of GTK+. But even more so, it's pandering to everyone
who believes in the schedules that we put out.
* The two most convincing cases that were presented for wanting
error indication did not require reporting a string to
the user:
- Doing a compound operation such as "change to a directory
and select a file"
- Having a better-than-default fallback starting location
for opening the dialog
* Cases where a nice error message is desired are vanishingly
rare; I don't think there is much harm if a generic
"cannot change to directory %s" is used instead.
* While adding a GError * is clearly more consistent with what
we do elsewhere, it's not hugely more consistent. We do
have other functions that return gboolean on failure
without a GError parameter.
* There will be more API flaws discovered after we ship 2.4.0;
this is inevitable. I believe that GtkFileChooser is a
very good API as it stands now; it makes what people want
to do commonly easy, and what they want to do less commonly
possible.
Consequences:
- No applications will be affected. Adding gboolean return
values to functions is according to our unwritten GTK+
API/ABI standards, "sufficiently compatible".
- Language bindings will have the option of rev'ing for this
API change or not. If they want to expose the boolean return
to their users, they will need to rev, but they will still
work correctly without this change, and for most languages
could compatibly add the boolean return later.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]