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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
