jiayouxjh / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Palette Undo is unreliable #354

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Palette undo-function: Make a change and click undo - the palette is
restored - Make another change and click undo and the palette is NOT
restored but set into the state of the first change!? Perhaps you know this
and think it's just one of those novel GrafX behaviours...but trust me, to
everyone else it's a bug! ;-)
(Reported by DawnBringer)

(Yes it's a bug - Yves)

Original issue reported on code.google.com by yrizoud on 7 Jun 2010 at 6:01

GoogleCodeExporter commented 9 years ago
Details:
Bug 1: As described: Select a color or a range. Perform changes using only RGB 
sliders (any number of times), then Undo, then RGB changes again, then Undo. 
Effect: you end up with the change 1, the one you undid.

Bug 2: Select a color or a range. Perform changes using only RGB sliders (any 
number of times). Select any oter color or ranges. Undo : No effect. You 
actually reset the undo buffer each time you move the cursor to another 
color/range.

Original comment by yrizoud on 7 Jun 2010 at 10:44

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

GoogleCodeExporter commented 9 years ago
What should we do ? Create the undo buffer on palette window opening and never 
change it ? This is dangerous, as you may spend hours tuning the palette in 
this window, make a single wrong change and you have to start over.

Use the regular undo stack ? Waste of pages memory.

Own undo stack for the palette ? Overkill ?

Reset the undo buffer on actually changing the palette, instead of selecting a 
range ? This solves "2", but not "1"...

Original comment by pulkoma...@gmail.com on 18 Feb 2011 at 12:34

GoogleCodeExporter commented 9 years ago
Working on it.

Original comment by yrizoud on 1 Mar 2011 at 6:11

GoogleCodeExporter commented 9 years ago
Fixed in r1744 to r1746.
At first I designed the thing as a nice state machine, but the resulting code 
was bloated and unreadable. When factorized down to two booleans and the 
minimum number of "if", it's much easier to understand and keep bug-free.

Original comment by yrizoud on 5 Mar 2011 at 4:34