[racket] Puzzled

Hi,

Thanks for the explanation. It makes sense now. Before it was just odd.

I was planning to reuse slider% to make a slider that will snap to a set
of discrete values (not necessarily with a fixed distance between them).

Would the simplest implementation strategy be to implement it from scratch
(using a canvas to draw the line and handle) rather than reuse slider% ?

/Jens Axel

2012/4/2 Matthew Flatt <mflatt at cs.utah.edu>:
> Sorry for the delay! I see that the same question went unanswered in
> 2011, too, although the answer is available from September 2009:
>
>  http://lists.racket-lang.org/users/archive/2009-September/035316.html
>
> That old message's prediction that a new `racket/gui' (formerly MrEd)
> would solve the problem turned out to be overly optimistic. The
> mismatch between eventspaces and GUI toolkits turns out to be deep
> enough that the completely reimplemented `racket/gui' is only a little
> better than the old implementation.
>
>
> To recap, the problem is that the underlying GUI toolkit (Cocoa, Gtk,
> or Win32) takes control when the slider is clicked, and the toolkit
> does not return control until the slider is released. The `racket/gui'
> library's handling of callbacks is obligated to stay within the same
> Racket thread as when the slider was initially clicked, because nested
> toolkit calls may depend on the enclosing dynamic context for various
> reasons. Consequently, if a slider callback (or some indirect callback,
> such as `on-subwindow-event') synchronizes in such a way that other
> Racket thread must first proceed, then the continuation of the callback
> is delayed by `racket/gui', and control is returned immediately to the
> underlying toolkit. When the toolkit relinquishes control after
> handling the click, any delayed callbacks can be completed.
>
> In the case of printing output that will appear in DrRacket,
> synchronization is required with DrRacket's GUI thread. That's why
> printing makes your example get stuck.
>
>
> (A reader who hasn't heard of this problem may now be tempted to
> suggest a workaround that involves multiple OS level threads, or
> something like that. All I can say is that I haven't been able to make
> anything like that work, despite two serious attempts.)
>
>
> At Mon, 2 Apr 2012 22:37:11 +0200, Jens Axel Søgaard wrote:
>> The following program shows a slider.
>> Why does the slider stop working, when I uncomment the display line?
>>
>> #lang racket
>> (require racket/gui)
>>
>> (define integer-slider%
>>   (class* slider% ()
>>     (super-new)
>>     (inherit get-value)
>>     (define down? #f)
>>     (define/override (on-subwindow-event receiver event)
>>       (begin0
>>         (super on-subwindow-event receiver event)
>>         ; (display (get-value)) (display " ")
>>         ))))
>>
>> (define frame (new frame% [label "Example: How to use real-slider%"]))
>> (define real-slider
>>   (new integer-slider%
>>        [parent frame] [label "x:"]
>>        [min-value 1] [max-value 100] [init-value 50]))
>>
>> (send frame show #t)
>>
>>
>> --
>> Jens Axel Søgaard
>>
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users



-- 
--
Jens Axel Søgaard