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
