Or I might be nit-picking... Eduardo
2009/9/12 Eduardo H. Silva <hoboprim...@gmail.com>: > 2009/9/11 Gary C Martin <g...@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 >>> palette. >> >> 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. > > Eduardo > >> >> Regards, >> --Gary >> >>> 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