[racket] how to add text-field-style behavior to rectangles drawn on a canvas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/18/11 01:39, Matthew Flatt wrote:
> At Mon, 17 Oct 2011 16:33:26 +0200, Marijn wrote:
>> Is it correct, that when you click the title bar of a window
>> frame to select it, this causes the on-focus method of that frame
>> to be called.
> 
> That's not what's supposed to happen. The `on-activate' method of
> the frame should be called, though.
> 
>> Further that on-focus method should check which sub-window had
>> the focus before and call that subwindow's on-focus method to
>> restore focus. This will recursively restore the focus.
> 
> No, the `on-focus' call should go directly to the window that has
> the focus relative to the frame.
> 
> I see that what I think should happen isn't what happens on Gtk.
> The frame gets `on-focus' when one of its subwindows gets the
> focus, and `on-activate' has problems. I'll work on that.
> 
>> Conversely when you click the title bar of a different window
>> frame B to deselect window A, then A's on-focus method is also
>> called with as sole argument #f. The same recursive process as
>> above is used to remove focus from any subwindows.
> 
> Only the window with the focus is supposed to get the `on-focus'
> call as focus leaves, while the frame should receive
> `on-activate'.

So in case of a canvas%-derived class (let's call it a grid%) that
displays a number of editor%s, when the user clicks in the region
displaying one of the editors how would the editor's on-focus method
get called? From what you write above I would infer that the grid%s
on-focus doesn't get called at all, but that the window system somehow
knows to call the right editor's on-focus method. I had thought that
the window system would just see a canvas% with some drawings in it
and that to it the only candidate to get an on-focus call would be the
canvas%. Then it would be the canvas%s responsibility to make sure the
correct editor gets the focus and that exactly one editor has the
focus at each point in time that the frame is active. When the frame
gets deactivated no editor should have the focus and consequently no
carets should be visible. AFAI have tested the standard gui editor and
display elements that come with racket work properly wrt
caret-visibility on a gtk system, only I seem to have some
misconceptions about how that works.

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6dPpAACgkQp/VmCx0OL2yUiACfTpViXK7hPuevNS/A/UkyGZ0f
9EwAn0HV+/xZWzm8aZPE25ApdTvcjcNo
=q6sx
-----END PGP SIGNATURE-----