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

At Tue, 18 Oct 2011 10:53:36 +0200, Marijn wrote:
> -----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.

Ah, no... I was referring only to `window<%>'s, because I forgot that
this was probably about your gird with editors.

In the case of a `text%' within an `editor-canvas%', the
`editor-canvas%' does receive an `on-focus' call as you'd expect, and
the `editor-canvas%' then calls `on-focus' for its `text%'.

> 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. 

That's correct.

> 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.

Just to be clear (hopefully!), the direct `on-focus' call that I
described happens only at the window layer, while there is an explicit
downward chaining as you described at the `editor<%>'/`snip%' layer.