Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Patches-3009998 ] Binding procedure reform
|
From: SourceForge.net <no...@so...> - 2010-06-16 16:39:09
|
Patches item #3009998, was opened at 2010-06-01 09:31 Message generated for change (Comment added) made by jenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312997&aid=3009998&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 01. Bindings Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Joe English (jenglish) Assigned to: Joe English (jenglish) Summary: Binding procedure reform Initial Comment: Attached patch winscrollbar-bindproc replaces the TkBindEvalProc ScrollbarBindProc with an ordinary event handler. (Description to follow). ---------------------------------------------------------------------- >Comment By: Joe English (jenglish) Date: 2010-06-16 09:39 Message: ... and if there are no further comments in the next day or two I plan to commit the patch, before it goes stale. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-06-16 09:37 Message: Notes from tcl-core mailing list: [ ~2 Jun 2010] Jeff Hobbs asked: > I read the comments, but I wanted to just check that in testing of this > patch, should we expect/see _any_ difference in UX? Confirmed: the patch should cause _no_ discernable difference in user interaction with Tk scrollbars. (There may be some program-visible differences, but -- I believe -- only under very unusual circumstances.) [ ~7 Jun 2010]: One programmer-visible change I thought of: At present, under Unix and Windows -- but not Cocoa -- it's possible to completely override scrollbar behavior by changing [bindtag]s. With the patch, this will no longer be possible under Windows or Carbon either, since the built-in behavior is more deeply baked in. (I don't think this is _too_ big a deal; as above, this is already how things work under Cocoa, and if anyone needs this type of thing it's still possible with the ttk::scrollbar.) ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-06-01 10:05 Message: For further background, see Tk bug#3006842. A workaround for that bug has been committed, but the intent of this patch series is to fix the underlying problem by removing the internal routine TkCreateBindingProcedure() altogether. It's quirky (see e.g. header comment in Tk_DeleteAllBindings()), little-used, and adds significant hairiness to tkBind.c. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-06-01 09:55 Message: Second patch in series carbonscrollbar-bindproc.patch does something similar for the obsolete Carbon-native scrollbar: it replaces TkCreateBindingProcedure() with an ordinary event handler. This is the last place in the Tk core (besides the test suite) that calls the internal routine TkCreateBindingProcedure(). The only other place it has ever been used in the core was in win/tkWinMenu.c starting in release 8.0; that usage has since been replaced with ordinary binding scripts: 2003-04-14 Mo DeJong <md...@us...> * win/tkWinMenu.c (MenuKeyBindProc, TkWinMenuKeyObjCmd) (TkpInitializeMenuBindings): Rename MenuKeyBindProc to TkWinMenuKeyObjCmd and convert it into a Tcl command named tk::tkWinMenuKey. Bind keyboard accelerator actions to this Tcl command instead of using a native C binding. This makes it possible to extend the existing binding with Tcl code and makes the Windows version work just like the unix version. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-06-01 09:48 Message: Notes: win/tkWinScrlbr.c is the only place where the TK_DEFER_MODAL / ClassProcs.modalLoopProc() machinery has ever been used in Tk. carbon/tkMacOSXScrlbr.c (formerly macosx/tkMacOSXScrlbr,c, formerly mac/tkMacScrlbr.c) has similar environmental constraints as the Windows-native scrollbar, but it calls the tracking loop directly from ScrollbarBindProc. I can't tell what the current macosx scrollbar implementation is doing, but all of the other Windows and Carbon native controls that require a modal loop enter it directly from a command procedure, event handler, or (in one case, see next patch) a binding procedure. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-06-01 09:38 Message: Current control flow in response to a ButtonPress event is: - Tk_HandleEvent() calls TkBindEventProc calls Tk_BindEvent, - which queues and later calls ScrollbarBindProc (binding procedure on "Scrollbar" bindtag) - which sets the TK_DEFER_MODAL flag and returns. - Later, Tk_BindEvent sees that TK_DEFER_MODAL has been set - and calls winPtr->classProcsPtr->modalProc() - which is ModalLoopProc in win/tkWinScrlbar.c, - which passes (what it assumes is a) ButtonPress event to TkWinResendEvent - which reformats it as a Windows message and passes it to the Windows L"ScrollBar" WndProc, - which enters a modal loop. After the patch, the control flow is: - Tk_HandleEvent() calls WinScrollbarEventProc (registered event handler), - which calls ModalLoop() directly - which passes the ButtonPress event to TkWinResentEvent ... - which proceeds as before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312997&aid=3009998&group_id=12997 |