Issue 6657 in pharo: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based

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