[Nautilus-list] Allowing view components to provide editing (UI and architecture issues)

[Maciej Stachowiak <mjs noisehavoc org>]

Hi folks,

I decided to start working on adding the ability to make components
editable and have a reasonable UI for saving and such. Since one of
the top usability concerns with Nautilus according to Sun's report is
the fact that the text view does not allow editing, I figure the best
solution is to make it allow editing.

Most of the work is simple - components that want to provide editing
and saving can just merge a "Save" item into the "File" menu. 

The one slightly tricky case is when a component has unsaved changes
and the Nautilus shell wants to trigger a location change or view
change. UI-wise, what you'd want is to present the user with a dialog
something like this:

+-------------------------------------------------------+
|             Unsaved changes                           |
+-------------------------------------------------------+
| The Text Viewer has unsaved changes for the file      |
| /tmp/hit-list.txt. Save before changing to the        |
| Microsoft Word Viewer?                                |
|                                                       |
|              [ Yes ] [ No ] [ Don't change views]     |
|                                                       |
+-------------------------------------------------------+

Or like this:

+-------------------------------------------------------+
|             Unsaved changes                           |
+-------------------------------------------------------+
|                                                       |
| The Text Viewer has unsaved changes for the file      |
| /tmp/hit-list.txt. Save before changing locations     |
| to "ftp://ftp.gnu.org/pub/gnu/gnobob";?                |
|                                                       |
|              [ Yes ] [ No ] [ Don't change views]     |
|                                                       |
+-------------------------------------------------------+

The wording in these dialogs is a very rough cut (Darin, Andy, or any
other usability experts lurking on this list, do you have suggested
improvements?) Also, I'm not sure if offering three options is best
here.

Anyway, to do this well requires some interaction between the nautilus
shell and the view. My proposed design for this is that the view keeps
Nautilus appraised at all times of whether or not it has unsaved
changes, and when Nautilus wants to change location or view and it
knows the current view has unsaved changes, it tells it to
save. Saving is asynchronous and has progress callbacks just like
loading. Here's some proposed IDL that puts this functionality in two
new interfaces, Nautilus::Editable and Nautilus::EditableFrame. I'm
aviding adding the new operations to Nautilus::View and
Nautilus::ViewFrame to avoid breaking compatibility even in theory,
although as far as I know all current Nautilus view components use
libnautilus so this would not be an issue.

module Nautilus {

	interface Editable : ::Bonobo::Unknown {
		oneway void save_to_location (in URI location);
	};

        interface EditableFrame : ::Bonobo::Unknown {
		oneway void report_save_underway ();
		oneway void report_save_progress (in float fraction_done);
		oneway void report_save_complete ();
                oneway void report_save_failed ();

                oneway void report_have_unsaved_changes (boolean have_unsaved_changes);
	}
};



There is one significant drawback to this approach, which is that the
Bonobo::PersistStream interface (used by most Nautilus views which are
not Nautilus::Views) has an incompatible approach to handling unsaved
changes. Instead of notifying some client when there are or are not
unsaved changes, the PersistStream interface provides an isDirty call
which returns a boolean value. This would cause problems for the
Nautilus adapter; it would either have to actively poll with this
isDirty call or risk unsaved changes.

A potential alternative is to add a call to the Editable interface to
explicitly request a report_have_unsaved_changes notification. The
down side to this is that Nautilus would have no way of knowing how
long to wait for the reply. The component could take forever making
this determination. I guess the way to handle this in the UI would be
just like other tasks expected to be fast but sometimes slow,
i.e. once it takes more than some timeout interval, pop up a dialog
that says "Checking for unsaved changes..." and has a "Cancel"
button. This approach could also help eliminate potential race
conditions with the report_have_unsaved_changes notification possibly
coming in just around the same time a view switch is initiated.

Another potential alternative is to convince the Bonobo maintainers to
make the PersistStream interface provide events via an EventSource,
although I am not sure this is doable for GNOME 1.x.

Any thoughts?

I'd especially love Darin's input.


Regards,

Maciej