[plt-scheme] middle ground between MrEd and gui/draw teachpacks?

Can you clarify what the actual task is?

At NU a bunch of students formed an outreach group on their own and 
organized a programming camp for local middle school kids. (Initially 
they planned on doing just girls. They went with co-ed.) They 
transformed our TeachScheme! (WPI/Brown's to be precise) camp for 
teachers into a camp for kids and by the end one of the kids wrote a 
solution for 8-queens, the "normal" ones write a simple simulation or a 
simple game using world.ss (which includes image.ss). The group is 
planning the same thing for this summer, and just showing off last 
summer's projects at a "summer fair" has generated twice the amount of 
interest as last year's ads. Is this what you have in mind?

-- Matthias



On Feb 9, 2005, at 11:34 AM, Matthew Flatt wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> At Wed, 9 Feb 2005 10:56:18 -0500, Prabhakar Ragde wrote:
>> 1) How hard would it be to integrate the canvas from draw.ss into a
>>    window created by gui.ss? The problem is that the canvas and GUI
>>    window are separate right now, and only one is "on top". It's
>>    awkward to have to keep raising one or the other.
>
> I can't think of a simple way. The "draw.ss" teachpack is built on the
> "graphics" collection, which always creates a new frame in a new
> eventspace, and I don't see a simple way to make it create the canvas
> in an existing window and eventspace.
>
> You could probably add a simplified canvas to "gui.ss". The simplified
> canvas could accept a callback to handle clicks, and an initial image,
> and it could support an operation for installing a new image. Then you
> could use the "image.ss" teachpack instead of the "draw.ss" teachpack
> to generate the image.
>
>> 2) Failing that, is it possible for me to write functions which bring
>>    one window or another to the top?
>
> My first thought was that you could use `get-top-level-windows' to find
> the drawing window, but that won't work because "draw.ss" puts its
> window in a separate eventspace. So, I'm not sure it's possible.
>
>> 3) Since this is a drawing program, I try to use (wait-on-mouse-click)
>>    to get, say, two positions to define a line. But this seems to
>>    queue up mouse events in advance. If I click several times on the
>>    canvas, and then press the "Draw" button which gets two clicks and
>>    draws the line, it will use past clicks, not future ones, and draws
>>    the line immediately.
>
> I think you could use `get-mouse-event' to flush old events (i.e., call
> it in a loop until you get #f).
>
> Matthew
>