Status: New
Owner: ---- Labels: Type-Enh Target-Spec Milestone-2.0 New issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 The title say it all : instead of having specific keystroke, nextfocusblock and previousfocusblock in Spec-Core models, wouldn't it be better to have that as Keymapping shortcuts ? It would also remove ListModel internal implementation of shortcut handling, and open all models to the possibility of adding shortcuts to Spec-based applications. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-2.0 Milestone-3.0 Comment #1 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 I guess not for 2.0? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #2 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 It would be good to have it in 2.0. Positive side effect: Spec focus navigation would work as intended in 2.0 ;) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-3.0 Milestone-2.0 Comment #3 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 But who will do it? Will be not release 2.0 until it is finished? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #4 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Good point. What would be the deadline for providing a slice ? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-2.0 Comment #5 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 We want to release as soon as possible. Originally we said beginning of Feb. But in general, issues that "would be nice if finished" are exactly the ones that don't need to be tagged 2.0... only show stoppers should be. Because else we will move the release further in the future. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: FixReviewNeeded Comment #6 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Slice in the inbox _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: Milestone-2.0 Comment #7 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 (No comment was entered for this change.) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: MonkeyIsChecking Comment #8 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657#c8 The Monkey is currently checking this issue. Please don't change it! _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: ValidatedByTheMonkey Labels: CheckedIn20531 Comment #9 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657#c9 This Issue has been checked by Ulysse the Monkey 6390 tests passed in 00:01:21s: =============================== CollectionsTests-Arrayed (553) CollectionsTests-Atomic (12) CollectionsTests-Sequenceable (912) CollectionsTests-SplitJoin (27) CollectionsTests-Stack (16) CollectionsTests-Streams (37) CollectionsTests-Strings (611) CollectionsTests-Support (12) CollectionsTests-Unordered (1954) CollectionsTests-Weak (739) CompilerTests (181) KernelTests-Chronology (593) KernelTests-Classes (69) KernelTests-Exception (2) KernelTests-Methods (179) KernelTests-Numbers (277) KernelTests-Objects (86) KernelTests-Pragmas (3) KernelTests-Processes (38) SUnit-Core-Extensions (3) SUnit-Core-Utilities (3) SUnit-Tests-Core (78) Spec-Tools-Senders-Tests (5) ---------------------------------------------------------- Loaded Source: SLICE-Issue-6657-ENH-Spec-Request--make-nextFocus--previousFocus-Keymapping-based-BenjaminVanRyseghem.1 from http://ss3.gemstone.com/ss/PharoInbox Tested using Pharo-2.0-20531-a on NBCoInterpreter NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Nov 27 2012 NBCogit NativeBoost-CogPlugin-IgorStasenko.15 uuid: 44b6b681-38f1-4a9e-b6ee-8769b499576a Nov 27 2012 https://git.gitorious.org/cogvm/blessed.git Commit: 40ac7e7bdec6fef0e934d2c019b86db996053912 Date: 2012-11-19 18:54:49 +0100 By: Mariano Martinez Peck <[hidden email]> Jenkins build #146 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Cc: [hidden email] [hidden email] Labels: -Type-Enh Type-FirstImpressionsCount Comment #10 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Currently, focus navigation is broken in Spec. For example, navigating to the text widget via tab, if the widget is a text widget, the tab character is inserted into it. Yuck! Not the impression we want for people building business on Pharo. I'll take a look at the slice... _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #11 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Did you try the slice? Did you have a look at issue 7294? Because in that issue looks really similar to this one, no? And as I said in the issue 7294, for me it's fixed, no? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #12 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 I looked through the changes and I'm porting a few UIs to test them... Looks good so far. This is definitely related to Issue 7294... I'll confirm that this fixes it... _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #13 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Cool :) Keep me in touch, because this bug definitely should be fixed for 2.0 :D _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #14 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Agreed :) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: FixToInclude Comment #15 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Okay, the fix looks good. It indeed fixes Issue 7294. There is only one problem... #isEventForNextFocusBlock: was a great hook for additional behavior. For example, I used it to accept text [1], and was thinking about using it for validation in the future. The feature is orthogonal, but this fix removes the hook. Given the choices, I think we're definitely better-off integrating this, but I'd like some kind of hook for losing focus, where you can perform some action and decide whether to give up the focus or not (I guess ret. true/false). _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #16 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 What do you mean by "additional behavior"" ? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #17 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 "For example, I used it to accept text" (on focus loss). Also, as above, for validation. I don't want to let the user get through my whole 10-field dialog and then complain that the first field was not filled out correctly. It'd be great to say something like: textField onNavigation: [ textField isValid ifFalse: [ self error: 'must be valid date' ]. textField isValid "return false to keep focus" ]. #onNavigation: was intended to capture "only within this UI", as opposed to #onLosingFocus:, so we don't create a system-model widget _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #18 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Sean, I think this would not have worked very well with the #isEventForNextFocusBlock: approach, because your user would have been able to switch focus within the dialog with the mouse (and escape the check). But I can see user sequences where onLosingFocus: would not work very well. To make it really polished, I would prefer a GUI with autoAccept and a red /change in color to flag an incorrect entry instead of a disrupting/annoying dialog box. And there, autoAccept + onLosingFocus: would work nicely. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #19 on issue 6657 by [hidden email]: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Ok, you used to use this to check validity. You can still do something like myTextModel on: Character tab do: [ self validation ifTrue: [ self giveNextFocusTo: myTextModel widget ]]. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Free forum by Nabble | Edit this page |