Should the toolbar icon for the colors palette have a down arrow like
with the other toolbar button icons? After all, it doesn't execute a
primary action of its pallete when clicking, instead it reveals its
palette.

Eduardo

2009/9/10 Gary C Martin <g...@garycmartin.com>:
> On 10 Sep 2009, at 12:01, Aleksey Lim wrote:
>
>> On Thu, Sep 10, 2009 at 12:54:48PM +0200, Simon Schampijer wrote:
>>>
>>> Hi,
>>>
>>> currently the ColorButton is not fully clear in it's behavior (see
>>> http://dev.sugarlabs.org/ticket/388). Click outside the palette to close
>>> it etc. Benjamin suggested to have an ok/cancel button to make the end
>>> of the selection clear http://dev.sugarlabs.org/ticket/388#comment:7
>>>
>>> Do others agree? Other thoughts?
>>
>> Another option is that picker should contain only predefined
>> colors(and maybe one custom) by default and having
>> click-to-close behaviour. Then if users want to make(change) custom
>> color, they click "add.."(or so) button and palette opens right panel
>> and click on predefined color will just change custom color.
>>
>> btw having select-to-close behavior(at least by default) we will keep
>> things consistent, e.g. to select suboptions from palette menus, user
>> needs only one click.
>
> Is it possible to emit the colour change event as soon as a colour is
> clicked? Or, perhaps emit as soon as the mouse leaves the palette area?
>
> I tried some quick mockups, the OK/Cancel doesn't feel very Sugar UI like
> (no other palettes use this behaviour). The click a colour to dismiss, with
> the addition of a 'custom colour' icon seems more natural, but looses a
> current nice feature where by you can pick a preset colour, see the sliders
> move, and then adjust them if you want to tweak. It also seems a little odd
> seeing both the toolbar icon and the custom icon changing colour at same
> time (see attachment below), though I guess in this case the toolbar icon
> could only change once you make a choice (and as you move a cursor around a
> document with colours).
>
> Anyway, all this makes me think that solving the issue by emitting colour
> change events early (i.e. not just when palette closes) would be a cleaner
> solution (more like a bug fix for a current unintended behaviour rather than
> redesigning an already good UI to avoid it).
>
> Regards,
> --Gary
>
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to