[Sugar-devel] [RFA] Feature freeze break: Read

[Eben Eliason]

On Tue, Sep 8, 2009 at 2:19 PM, Simon Schampijer<simon at schampijer.de> wrote:
> On 09/08/2009 08:10 PM, Sayamindu Dasgupta wrote:
>> On Tue, Sep 8, 2009 at 10:00 PM, Gary C Martin<gary at garycmartin.com>  wrote:
>>> On 7 Sep 2009, at 23:13, Simon Schampijer wrote:
>>>
>>>> On 09/07/2009 08:37 PM, Sayamindu Dasgupta wrote:
>>>>> Hello,
>>>>> Attached is the patch for making Read support the new toolbar system
>>>>> (patch courtesy of Simon). While it is a bit long, most of the changes
>>>>> is moving around stuff.
>>>>>
>>>>> Known issue:
>>>>> a) The TOC combobox, the bookmark toggle and the Stop buttons
>>>>> occasionally "overflow", as detailed in the post:
>>>>> http://lists.sugarlabs.org/archive/sugar-devel/2009-September/019021.html
>>>>> There is no know workarounds yet.
>>>>>
>>>>> There seems to be no other regressions as per my brief testing.
>>>>>
>>>>> Thanks,
>>>>> Sayamindu
>>>> I have attached a new patch. It does move the TOC-combobox into a
>>>> secondary toolbar to overcome the space issue. One issue with this is, that
>>>> one uses the combobox and dismisses it, the secondary toolbar does not get
>>>> dismissed automatically as well (toc-list-open, toc-list). Aleksey any idea
>>>> if this triggers something is in the toolbarbox code itself?
>>>>
>>>> I have played with using the view-list icon for that option or the
>>>> bullet-list one from the Write activity (bullet-icon). Feedback welcome.
>>>>
>>>>  From testing, there is no regression.
>>>>
>>>> -----
>>>> General Feedback:
>>>>
>>>> Finally, would be nice to add a little text to the combobox, when there is
>>>> not TOC information, at the moment we have an unusable button (no-toc). Or
>>>> make it insensitive, or...
>>> If there is no TOC, the ToolbarButton (and one of the separators) should not
>>> be displayed at all. So you only see TOC ToolbarButton if the document has a
>>> TOC.
>>>
>>
>> In Read 73, the TOC button is not displayed if there is no support for
>> ToC, or if the document does not have a ToC.
>>
>> Thanks,
>> Sayamindu
>
> Actually, we could make the button insensitive as well. I like that more
> than hiding, because the general functionality is still there - can just
> not be used with this document (we do the same for the share button for
> example).

The question of making a control insensitive vs. hiding it entirely is
always a little tricky. Generally, the decision should be made based
on two things:

1. Can the control be enabled via some action on the part of the user
(making the appropriate selection, entering some text, changing focus,
adjusting another control, etc.)?
2. Does the control provide useful information in its disabled state?

If the answer is "yes" to either, the control should probably be shown
but made insensitive. If the answer is "no" to both, it should
probably be hidden.

I think we can answer yes to question two for the share button, which
indicates both that the current activity is private, and also that the
activity doesn't support sharing. Both are useful facts. I think I'd
probably answer no to both for the TOC, though. The absence of a table
of contents is a property of the book, which the user can't modify (it
would be different if it were editable!), and the only useful info the
insensitive control would provide is that, for *some* books, there is
some other feature available, but it wouldn't provide useful info in
the context of this particular activity.

Eben