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

[Simon Schampijer]

On 09/08/2009 08:33 PM, Eben Eliason wrote:
> 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

Thanks Eben for the great clarification. Hiding the button, sounds good 
to me then as well.

Regards,
    Simon