Color selector

[david powell]

actualy i seem to like them at the moment , size is a problem though 
for those with low res desktops 

from a user point of view speed of being able to do a task is more important 

in other words having to hit 3 or 4 different buttons to get the desired 
result repeatedly is not good 

maybe what would be a good idea is to have a flip tool view /drawing view 

the tool view would let you have almost all the screen aria for colour / brush 
and style options , letting you just filp to it change something and filp 
back 

although the use of combo boxes makes everything visible all the time its at 
the expence of using large amounts of screen real estate , 

although i like the current interface looks from a user point of view working 
full screen and swiching to a tool view to change something is a faster 
working method for imaging  

with a flip screen its also faster to find the property you want to adjust 
be it colour or brush shape and opacity , then flip back ,, 

now obviously there needs to be a quick and obvious way to flip
but it would also remove the problem your discussing about the size of the 
current one , 

i do find the current system leaves little on screen drawing area  even on 
this 24" 1920*1200 lcd monitor remebering the average pc atm is 1240*1024

i also tend to work on photographs at 3696*2464 ~9M pixels 


i seem to remeber it was neopaint and a few others  back in the early 80's 
that used a flip screen view setup as an option ,, because of screen space 
problems 


secondly this would provide some other usefull advantages both from usibilay 
and speed 

usabilaty /.

haveing options on display aids the user in finding them , hide them in some 
sub menu and some users may never even find they exist 

it also saves the user having to search though nearly all the menus to find 
the option ( remeber a lot of people would use this occasionaly  so may have 
to relearn where they are each time )

blender if you have tried it is a pita , takes you 2 months to learn all the 
commands and if you have to leave it for a while you find you spend another 
few trying to relearn it , not to mention an almost imposible to figure out 
GUI , that program would be good with a new front end 
anyway 

speed/.  

when drawing and yes 3 to 4 hrs maybe more in one go , the fact that 
you know what option you want to change , but  say 

you want to change the brush shape/ size ,, and the opacity  , draw a bit , 
change the colour , and drawing mode , then revert back , eather 
you have to use quite a lot of screen space or end up having to search though 
menus for them  
so that requires quite a few mouse clicks and time spent searching menus 

it also allows for all the options to be set and room for more functions 
like 
saved brush presets 
colour mixing 
stroke control :)

i used to do a lot of autocad work , using a tablet with a option  template on 
the tablet could save over 50% of the time doing the same drawing using a 
mouse and menus 

Dave(AchiestDragon)

On Thursday 18 October 2007 4:55 pm, Cyrille Berger wrote:
> Hi,
>
> We had a little discution on irc (involving Boudewijn, Casper and me) this
> afternoon on the color selector. The starting point is that the current
> trunk docker is a little bit big, and I am not sure that all of it (like
> CMYK combo box, or any combo box at all) is needed in the docker. But,
> clearly, a lot still need to be discussed.
>
> * As Casper pointed it out, we should start by defining the purpose of a
> docked
> colorchooser ? What's the goal ? And what's need ?
>
> The main use case we saw for this docker is someone drawing, then selecting
> a color, then drawing, then selecting a color, then drawing, then...
>
> * some other random thought that were raised during the discution:
>  - Color selection should happen in percentage or double (that said color
> selection for HDR imaging is still an open discution)
>
> About the dialog:
>  - hsv in the big color dialog is a good thing
>  - we cannot do without cmyk but it should be more related to the current
> CMYK color space if the current paint device is in a CMYK, not to some
> random default
>
> About the docker(s):
>  - a smaller hsv-based color selector with history for the default docker
> (with a square, circle or triangle color area ?)
>  - the big color selector can stay as a docker, but should not be the
> default one
>  - and we need a third docker with a color selector dedicated to the
> current color space (especially for special case like YCbCr), with sliders
> for each of the components
>
> So if you have opinion or thoughts on the subject, or use cases, we are all
> open to hear them !

-- 
-----------------------------
my personal website 
http://www.achiestdragon.org
-----------------------------
                       )/_
             _.--..---"-,--c_
        \L..'           ._O__)_
,-.     _.+  _  \..--( /          
   `\.-''__.-' \ (     \_
     `'''       `\__   /\
                 ')