Rick Yorgason wrote:
> Simon Large wrote:
>> 3. The dual slider control is very clever, but in Rick's words it
>> seems over-engineered. Why would you want to toggle between 2 custom
>> blend values? I would be tempted to remove the two setpoints and just
>> use the button to select between 0% 50% and 100% blend points
>> (equivalent to up/right/down arrow keyboard shortcuts).
>
> I really don't like the triple-toggle. It is *much* easier to detect
> and compare differences when there's only two states, and I'm fairly
> certain research on human sight backs me up here. Actually, the thing I
> like the most about the new slider is that we can show the image at 50%
> initially, which is an immediate indication to the user as to what the
> overlap mode does, and then toggle back and forth between the two
> extremes with the button, which are the two most useful positions on the
> slider.
>
> There's also some use to being able to toggle between 50% and one
> extreme, since 50% is the closest you can get to a 'merged' image. The
> up/left/down keys allow that, and so does the new control. The benefit
> to giving the new control as an option is that users are far more likely
> to discover what the markers do when they play with them (since there
> *is* a visual cue) than they are to press random keys on their keyboard
> until they find one that does something.
OK, you convinced me. I'll document it as is :-)
The shortcuts aren't indicated on the menus, and those arrow keys don't
belong in the menus anyway. If someone can list the available shortcut
keys, I will add those to the doc too. No point in having them if no-one
knows what they are ;-)
>> 4. On a slow PC like my laptop, when dragging the blend point the
>> system seizes up periodically to redraw. I would prefer the redraw to
>> happen when I release the left mouse. Others may disagree - this
>> laptop is about 5 years old, and it is probably not a problem on a
>> modern machine.
>
> Well, there is a 50ms delay before it refreshes while you're sliding.
> Just pretend you're Keanu Reeves don't stop moving >:)
>
> I dunno, 50ms is what it was at before I started looking at the code. We
> could raise the timeout, but if we raised it as high as 1 second I think
> it would feel unresponsive.
>
> Getting rid of it completely isn't something I can get behind either,
> because I do like to test the alpha value before committing to it. It
> wouldn't be *so bad* now with the new alpha control, because you can now
> simply click anywhere in the gauge to set the value, rather than having
> to slide, so it wouldn't be as slow to test values out as it would with
> the old slider, but even then it seems like it would be a little
> uncomfortable.
>
> We could add an option not to update the alpha until the value is
> changed, but I think it would be confusing to most users. Ideally, it
> would be best to simply make it not slow!
>
> The blending will be done differently in the future when we add
> different blending modes, though, so there's no point in optimizing just
> yet. (Not that I would look forward to learning SIMD instruction sets
> and then writing the same code five times for C++, MMX, 3DNow!, SSE, and
> SSE2.)
>
> By the way, what are the specs on your laptop?
800 MHz PIII 384MB RAM.
I'm really not that worried about it. Just that if it was something
simple, it would be worth changing. But there are far more important
things to spend time on.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Feb 9 18:10:04 2007