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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Wed Feb 9 11:34:33 EST 2005

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



Posted on the users mailing list.