[Sugar-devel] [Design] ColorButton
Eduardo H. Silva
hoboprimate at gmail.com
Sat Sep 12 11:34:09 EDT 2009
2009/9/11 Gary C Martin <gary at garycmartin.com>:
> On 11 Sep 2009, at 00:30, Eduardo H. Silva wrote:
>> 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
> No, down arrows indicate the new lockable secondary toolbars (one click to
> lock open, one click to lock closed, hover for temporary quick use like a
> palette). Locking open secondary toolbars resizes the activity canvas area,
> normal toolbar palettes do not.
> FWIW: it has been agreed (I think) that any icons that have _NO_ default
> primary function (i.e. they just hold palettes) should instantly, and fully
> expose on a single left click (as they already do for a single right click).
> As their primary function is to display their palette. Maybe we can solve
> this for 0.88. This would solve things like providing instant feedback on
> buddy icons, such as accessing the large self buddy icon in the home view
> for getting to settings, shutdown etc.
But shouldn't something be done visually to differentiate those icons
which open palettes when clicked, from those which act their primary
action? The user won't know beforehand what will the result of
clicking be otherwise.
>> 2009/9/10 Gary C Martin <gary at 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:
>>>>> currently the ColorButton is not fully clear in it's behavior (see
>>>>> http://dev.sugarlabs.org/ticket/388). Click outside the palette to
>>>>> 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,
>>> 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
>>> move, and then adjust them if you want to tweak. It also seems a little
>>> 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
>>> 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
>>> solution (more like a bug fix for a current unintended behaviour rather
>>> redesigning an already good UI to avoid it).
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel