[plt-scheme] Odd slider% behaviour?

There are indeed eventspace/thread limitations issues with sliders, at
least under Mac OS X and Windows. Worse, interactions with the DrScheme
eventspace can affect the results you get.

If I run your original program at the command line, then it works
better than the other two versions. The problem with the first version
in DrScheme is that a printout blocks until it communicates with
DrScheme, and a slider callback is limited to stay in the same
eventspace (and thread). Running from the command line, though, there's
no cross-eventspace communication for a printout, and so it appears
immediately.

You're probably aiming for something other than printouts, eventually,
so the slider may work ok in the end. More generally, this is the sort
of problem that we expect to fix with a new implementation of MrEd
(which is currently stalled, but I hope to have more hacking time this
fall than I had over the summer).

Matthew

At Wed, 2 Sep 2009 11:17:53 +1000, Andrew Reilly wrote:
> Hi again,
> 
> Please consider this simple GUI program that seems to be a
> minimal thing that demonstrates a problem that I'm having with
> the GUI that I'm working on:
> 
> #lang scheme/gui
> 
> (let ((f (new frame% (label "SLIDER TEST"))))
>   (new slider%
>        (parent f)
>        (label "foo")
>        (min-value 0)
>        (max-value 400)
>        (init-value 200)
>        (style '(horizontal horizontal-label plain))
>        (min-height 50)
>        (min-width 400)
>        (callback
>         (lambda (s e)
>           (printf "~a ~a ~a~%" (send s get-label) (send s get-value) (send e 
> get-event-type))
>           (flush-output))))
>   (send f show #t)
>   (yield 'wait))
> 
> Without the callback, the slider pops up and one can wiggle
> the control tab (thumb?) back and forth exactly as one might
> expect.  Motion is continuous and responds instantly when the
> mouse moves.  This is what I want to happen!
> 
> With the callback as shown (or the functionally similar thing in
> my main program), the tab does not track mouse movement.
> Instead, the tab will lurch from where it was to the location of
> the mouse when the button is released, in one step.  Also, the
> printouts show that the callback is called only twice for any
> mouse-down/mouse-up pair.  If this down/up click is a "click" on
> a location that isn't the tab, then the two events see a slider
> in the "before" position and then the "after" position.  If the
> down/up click is a "hold-and-slide" on the thumb, then the
> slider value of both events reflects the "after" position.
> 
> What I *really* want is a stream of events that correspond to
> the mouse movement in real-time, with the slider's thumb moving
> continuously while held.  Just like it does without the
> callback.  Is this possible?
> 
> I suspect that what I'm doing wrong is somehow mixing up the GUI
> and standard-output event spaces, and running into interlocks
> and/or timeouts somehow: there seems to be a significant lag
> between the GUI activity and the log on the IDE console.  Should
> I be putting the GUI into an indpendent thread, somehow?  If I
> have a callback that just does (void) instead of (printf ...),
> then the thumb continues to move smoothly.  I have yet to figure
> out an intermediate callback structure that allows me to *use*
> the real-time thumb movement...  (I'm trying to control a device
> at the other end of a TCP/IP socket.)
> 
> I understand that the MrEd (#scheme/gui) functionality is built
> on top of the WxWidgets library.  I've had a look at the slider
> documentation in wxWidgets, and there seems to be a whole family
> of "event types" that a slider can emit.  Do these show up
> somehow in the event object?  The control-event% documentation
> only admits to get-event-type -> 'slider (which is obvious in
> this context), and get-time-stamp -> integer?, which I don't
> really care about, I think.
> 
> Thanks in advance for any advice.
> 
> Cheers,
> 
> -- 
> Andrew
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme