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
>