Re: [Nautilus-list] Nautilus user testing at MIT

["John Sullivan" <sullivan eazel com>]

Sorry about the slow response on this one, I kept meaning to go check the
behavior but didn't get around to it until just now.


on 1/4/01 9:41 AM, Calum Benson at calum benson ireland sun com wrote:

> John Sullivan wrote:
> 
>> I don't think we are disagreeing here, but I'm not quite sure. In the
>> version that the users were tested on, they could change the text in a text
>> document viewed in Nautilus by typing or deleting, which was a bug because
>> no changes could be saved. This has since been corrected so that you can't
>> change the text by typing or deleting. Therefore we are "stopping them
>> before they try" and not forcing them to do something wrong and then redo
>> the operation.
> 
> Perhaps presenting the read-only view on a grey (or at least non-white)
> background would emphasise the read-only nature of the document-- as is
> conventional with text fields etc.?  At the moment it still *looks* very
> editable until you try.

I agree with the sentiment, but I'm not sure about the proposal. This view
presents large amounts of text intended for reading. Changing the background
color to the "uneditable text" color would make it harder to read. Typically
an "uneditable text" color is used to distinguish small amounts of text that
are temporarily uneditable for some reason -- in that case, noticing that
the text is uneditable is of an importance on par with reading the text. I
don't think that's the case here. However, I do agree that it would be nice
if it were somehow clear that the text is not editable, as long as such an
indication didn't hurt the overall usability for some other reason (as I'm
afraid a colored background would).

> Incidentally, this thread prompted me to play with it a bit, and I
> notice there's no contextual menu in the text doc viewer on the version
> of Nautilus I'm running (0.5.0), which was the first place I looked when
> I tried to copy some text.  (Even more annoyingly, my selection was
> deselected as soon as I clicked the right mouse button to look for
> it...)  A bug, a feature, or something that's since been fixed...?

The lack of context menu is a missing feature. It's worth doing, but not
high enough priority for us to do before 1.0. It would be helpful if you
would submit a bug report about it to bugzilla.eazel.com.

I'm not sure of the exact origin of the right-click-deselects behavior, but
it could be considered a bug (and so it would be worthwhile to write up a
bugzilla report for it). Note that left-click also deselects any selected
text, just as in any other text viewer/editor. If we were using right-click
for a context menu, then it would incontrovertibly be a bug that it
deselects the text. Currently, I notice that right-button dragging makes a
selection without making the selection active, behavior that strikes me as
useless and confusing. Probably the view inherited this behavior from some
other widget, but I'm not sure.

John