I've dabbled with this a couple of times.  Once I even got working
code that was kinda fun, but I dropped it because I didn't like the
implementation.  All it did was display an image, no input was
available, but e.g.  clicking on foo.gif put foo.gif in an acme window
(this was before plumbing, and was in fact part of the inspiration
behind doing plumbing in the first place, so i could move button 3
rules out of acme code).

After some further thought, I decided the best plan was to represent a
window in acme as a published (via nameimage) image file in the draw
device.  Perhaps that image would not be the window itself, but its
backing store (to use old terminology), but the point is that external
programs could get access to the window much as they do in rio.  Such
windows would need auxiliary files to drive them, and would in the end
require a great deal of duplication of rio's functionality, which is
one of the reasons I didn't pursue it (too much work, too much
duplication) but I was hoping to find a way that some of acme's
structure could survive.  It seemed the best way to achieve that might
be to allow old programs (say, sam) to run in an acme window but not
to push acme very far to make that happen.  Instead, it would be more
productive to design new I/O mechanisms that allowed programs written
specifically for this environment to run there.  This might mean, for
instance, a special toolkit that allowed click-through for selection
and plumbing events.

It was all very vague, even after a couple of throwaway attempts,
but what was clear was that I didn't want to reproduce rio, I wanted
to make an acme-like feel possible for graphics, but I had only
rudimentary ideas about how to do that.

-rob