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