IMO, example 2 can be remedied inside redex (by pausing briefly before actually triggering the updates), but the first one is probably because of a more complex interaction of gui callbacks and probably trickier to track down.
Robby On Thu, Aug 12, 2010 at 6:12 PM, Everett <[email protected]> wrote: > Observation of DrRacket and PLT Redex leads me to believe that when > updating something displayed in the GUI each change is immediately > reflected (in a nice functional manner), even if a batch of changes is > being performed, thus wasting time drawing the GUI on intermediate > results. The effect is a less usable GUI. > > Example 1: > Have two tabs open in DrRacket. Click the other one. You can see the > scroll bar adjust first, showing the corresponding location in the > current file, then the contents adjust second showing the right file. > > Example 2: > In PLT Redex traces graph, move the font-size slider. The whole GUI > freezes up until it has redrawn, even though I wasn't done moving the > slider. The result is that I have to move the slider one font size (or > few font sizes) at a time. > > Possible solutions: > - For the slider: a timeout after user input stops before actually > changing the value. > - For the tabs: The ability to give a list of changes before updating > the GUI > - Functions to turn on/off updating and use them around a group of > changes or when dragging a slider. > - Some other kind of double-buffering feature at least, so it isn't as > slow and as visible. > > > Or am I wrong about the cause (and thus solutions) of these GUI > problems? > > > Thanks, > -Everett > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
