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 > Sugaremail@example.com > http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ Sugar-devel mailing list Sugarfirstname.lastname@example.org http://lists.sugarlabs.org/listinfo/sugar-devel