Smalltalk › Cincom › VisualWorks

Re: vw7.7 & keyboard shortcuts

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Steven Kelly

Re: vw7.7 & keyboard shortcuts

RE: vw7.7 & keyboard shortcuts

Following on from a discussion on vw-dev, here’s my conclusion: 7.7’s decision to send keyboard events to the widget before the menu bar is a breaking change. Significant portions of most VW apps will fail to work, because most control keys specified in the menu bar will be ignored.

The change also makes building new applications much harder, probably to the extent that most people trying out VW for a GUI application would simply drop it. Even the “hello world” of GUI apps, Notepad, cannot be built in VW using the standard tools beginners could be expected to pick up.

I’ve attached a quick mockup of Notepad. Try typing a little and then pressing Ctrl-keys to access the commands in the menu. Some keys are handled properly (New & Open); a dialog showing the command name (menubarNew) will open to show that. Most keys don’t work (Save does nothing, Print does nothing or tries to evaluate the text as code, Find will do a find – but not the one specified in your application, Replace will delete the text, Goto will try and repeat the last find etc.). I could add more commands – e.g. Cut/Copy/Paste, which would all fail in the same way as Find – but I think you get the idea.

There is no normal way for the user to correct this for to be able to specify the desired control keys for this window: you have to change the behavior of all text widgets, or get into some serious low-level coding. That’s simply wrong. Of course it’s great that we have access to stuff like that, but we shouldn’t be forced to hack just to get something as simple as Ctrl+s working as a Save command.

I submit that the change was made with good intentions, and the design was plausible, but in fact the menu bar should have priority over the text widget’s keyboard mapping. Individual ApplicationModel windows often want to specify their own control keys to override default behavior; the other way round is less common. As Mark Plas said, “There hasn’t been a need for a widget to override the menu bar behavior. If a widget does something special with Ctrl-<key>, then Ctrl-<key> is also in the menu bar. In our applications it would be strange that the menu bar would say 'Ctrl-F' does 'Find' and in a specific widget 'Ctrl-F' would be overridden to mean 'Inspect'”.

All the best,

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Notepad.st (5K) Download Attachment

Travis Griggs-3

Re: vw7.7 & keyboard shortcuts

On Mar 17, 2010, at 7:22 AM, Steven Kelly wrote:

I submit that the change was made with good intentions, and the design was plausible, but in fact the menu bar should have priority over the text widget’s keyboard mapping. Individual ApplicationModel windows often want to specify their own control keys to override default behavior; the other way round is less common. As Mark Plas said, “There hasn’t been a need for a widget to override the menu bar behavior. If a widget does something special with Ctrl-<key>, then Ctrl-<key> is also in the menu bar. In our applications it would be strange that the menu bar would say 'Ctrl-F' does 'Find' and in a specific widget 'Ctrl-F' would be overridden to mean 'Inspect'”.

The change was made for more than academic reasons. The use case (for which we had multiple ARs) which was making the design problem an issue was the debugger. The menu bar wanted to define shortcuts for various actions that could run on various panes (ctrl-d as do it for example). But it was specifically coded to hit the main text pane. We could change it to find the focused text widget, determine if it was a text widget that could "do it" and then do it. But we'd have to do that for every single menubar item that became context specific. We didn't see any hint in Windows, OSX, or GTK that when you put a "cut" item in the menu bar, you have to have a top level function/method that hunts down the focused widget and determines the applicability.

What we did find was this document:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW11

About half way thru, there's a nice flow diagram and this statement:

"If the message isn’t handled by an object in the view hierarchy, NSApp then sends it to the menus in the menu bar."

I apologize for using an Apple reference, I know that many/most of VW end user applications are running on Windows. It's just that that was the first document we could find that painted the picture pretty clearly. I would dearly appreciate anyone who can point me to a link for Windows that is definitive and clear like that one. I have done research and reading, and all of the Windows docs I find leave me guessing that we got it right, but I end up having to make assumptions and having no quotable references.

I have read thru the following WPF documents:

http://msdn.microsoft.com/en-us/library/ms754010.aspx

http://msdn.microsoft.com/en-us/library/ms753391.aspx

http://msdn.microsoft.com/en-us/library/ms752308.aspx

http://msdn.microsoft.com/en-us/library/ms742806.aspx

And I *think* what I read there is that keypress response resolution starts at the focused widget, and moves outward to wider scopes (especially 3rd and 4th links). That's the way "bubble up" events work.

Part of the problem (I think) is that the work begun in 7.7 is evolutionary, and there are incomplete parts.

For example, it was noted that we may hit a text handling widget twice with the same key, because of the fallback line at the bottom of KeyboardProcessor>>processKeyboardEvent:.

Another problem, brought to light by your example, is that we're just doing way too many default bindings in text editor. They should be the very most basic prebindings be default (copy, cut, paste (these only if we're not read only), maybe find and replace). And that's about it. IDE tools should be configuring their text editors with their particular bindings (doit, etc). There's AR for this (59638: "Pull Smalltalk specific key bindings from text editors") which I hope to have in 7.8 or 7.7.1, whatever it ends up being called.

Travis Griggs

Objologist

Light travels faster than sound. This is why some people appear bright until you hear them speak...

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: vw7.7 & keyboard shortcuts

In reply to this post by Steven Kelly

I agree with what you say, Travis – I remember agreeing with the theory back when this was discussed. But what about the practice? What’s your advice for the Notepad app? Should beginners really have to make per-widget changes to the keyboard dispatch mappings just to be able to allow the menu bar to receive events?

We have a few places similar to the debugger in our own app, and for over 15 years we’ve had the same simple piece of code that redirects the menu bar key to the focused widget. That’s been a solution that was easy and has stood the test of time. It’s a solution to a fairly rare problem; the problem exhibited by my Notepad example is far more common.

Cheers,

Steve

From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: 17 March 2010 20:05
To: VWNC NC
Subject: Re: [vwnc] vw7.7 & keyboard shortcuts

On Mar 17, 2010, at 7:22 AM, Steven Kelly wrote:

What we did find was this document:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW11

About half way thru, there's a nice flow diagram and this statement:

"If the message isn’t handled by an object in the view hierarchy, NSApp then sends it to the menus in the menu bar."

I have read thru the following WPF documents:

http://msdn.microsoft.com/en-us/library/ms754010.aspx

http://msdn.microsoft.com/en-us/library/ms753391.aspx

http://msdn.microsoft.com/en-us/library/ms752308.aspx

http://msdn.microsoft.com/en-us/library/ms742806.aspx

Part of the problem (I think) is that the work begun in 7.7 is evolutionary, and there are incomplete parts.

For example, it was noted that we may hit a text handling widget twice with the same key, because of the fallback line at the bottom of KeyboardProcessor>>processKeyboardEvent:.

Travis Griggs

Objologist

Light travels faster than sound. This is why some people appear bright until you hear them speak...

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michael Lucas-Smith-2

Re: vw7.7 & keyboard shortcuts

On 3/17/10 11:35 AM, Steven Kelly wrote:

I agree with what you say, Travis – I remember agreeing with the theory back when this was discussed. But what about the practice? What’s your advice for the Notepad app? Should beginners really have to make per-widget changes to the keyboard dispatch mappings just to be able to allow the menu bar to receive events?

No, the notepad example is a good one - the text editor over the years has become a dumping ground for behavior related to code editing, not text editing. This needs to be fixed and I believe Travis is taking steps to correct this. There isn't that much that the text editor should directly know about wrt to 'text editing'.. cut, copy, paste, undo, redo .. code editing is another matter, that's really up to the tools themselves to install whatever behavior they need on the editor or in their own menu bars.

So in short, in that notepad example, the text editor is at fault, not the keyboard processor.

Cheers,
Michael

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Holger Guhl

Re: vw7.7 & keyboard shortcuts

In reply to this post by Travis Griggs-3

It's attractive to have a clear model and why not adapt other worlds
standards.
But we need to keep consistency and backward compatibility. As far as I
can see we had the reverse direction for event dispatching all the time
(first menus and accelerators, then widgets). VisualWorks developers
might not enjoy the new clear picture if their code is about to break.
How about migrating a large GUI application? I have not yet thought this
to the end but I don't see any other chance than visiting and reviewing
each GUI and do *manual* testing. This is a challenge if you have some
dozen GUIs.
Some flaws sneak in very silently and are hard to detect. For example
the Workspace. Ctrl-S used to trigger the Save function. The first Save
will prompt for the target filename, the next can use the known file. I
am used to this behavior and expect changes be saved in the file. In VW
7.7 you lose changes! Try yourself, edit a bit, press Ctrl-S (which
accepts - due to preference on the text widget - changes to the model,
not the file) and close the window. Edits are lost without the typical
warning from #changeRequest, since the model is happy. OK, withdrawing
key bindings from widgets could solve that...
--

Holger Guhl
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund A 12812

Travis Griggs schrieb:

> On Mar 17, 2010, at 7:22 AM, Steven Kelly wrote:
>
>> I submit that the change was made with good intentions, and the
>> design was plausible, but in fact the menu bar should have priority
>> over the text widget’s keyboard mapping. Individual ApplicationModel
>> windows often want to specify their own control keys to override
>> default behavior; the other way round is less common. As Mark Plas
>> said, “There hasn’t been a need for a widget to override the menu bar
>> behavior. If a widget does something special with Ctrl-<key>, then
>> Ctrl-<key> is also in the menu bar. In our applications it would be
>> strange that the menu bar would say 'Ctrl-F' does 'Find' and in a
>> specific widget 'Ctrl-F' would be overridden to mean 'Inspect'”.
>
> The change was made for more than academic reasons. The use case (for
> which we had multiple ARs) which was making the design problem an
> issue was the debugger. The menu bar wanted to define shortcuts for
> various actions that could run on various panes (ctrl-d as do it for
> example). But it was specifically coded to hit the main text pane. We
> could change it to find the focused text widget, determine if it was a
> text widget that could "do it" and then do it. But we'd have to do
> that for every single menubar item that became context specific. We
> didn't see any hint in Windows, OSX, or GTK that when you put a "cut"
> item in the menu bar, you have to have a top level function/method
> that hunts down the focused widget and determines the applicability.
>
> What we did find was this document:
>
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW11
>
> About half way thru, there's a nice flow diagram and this statement:
>
> "If the message isn’t handled by an object in the view hierarchy,
> |NSApp| then sends it to the menus in the menu bar."
>
> I apologize for using an Apple reference, I know that many/most of VW
> end user applications are running on Windows. It's just that that was
> the first document we could find that painted the picture pretty
> clearly. I would dearly appreciate anyone who can point me to a link
> for Windows that is definitive and clear like that one. I have done
> research and reading, and all of the Windows docs I find leave me
> guessing that we got it right, but I end up having to make assumptions
> and having no quotable references.
>
> I have read thru the following WPF documents:
> http://msdn.microsoft.com/en-us/library/ms754010.aspx
> http://msdn.microsoft.com/en-us/library/ms753391.aspx
> http://msdn.microsoft.com/en-us/library/ms752308.aspx
> http://msdn.microsoft.com/en-us/library/ms742806.aspx
>
> And I *think* what I read there is that keypress response resolution
> starts at the focused widget, and moves outward to wider scopes
> (especially 3rd and 4th links). That's the way "bubble up" events work.
>
> Part of the problem (I think) is that the work begun in 7.7 is
> evolutionary, and there are incomplete parts.
>
> For example, it was noted that we may hit a text handling widget twice
> with the same key, because of the fallback line at the bottom of
> KeyboardProcessor>>processKeyboardEvent:.
>
> Another problem, brought to light by your example, is that we're just
> doing way too many default bindings in text editor. They should be the
> very most basic prebindings be default (copy, cut, paste (these only
> if we're not read only), maybe find and replace). And that's about it.
> IDE tools should be configuring their text editors with their
> particular bindings (doit, etc). There's AR for this (59638: "Pull
> Smalltalk specific key bindings from text editors") which I hope to
> have in 7.8 or 7.7.1, whatever it ends up being called.
>
> --
> Travis Griggs
> Objologist

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: vw7.7 & keyboard shortcuts

In reply to this post by Steven Kelly

The set of default key bindings is excessive, true, but that's been so for years without causing this problem. Even if we cut out the code editing bindings, and pare the rest down to the default text behaviour you suggest, we still have the same problem for the remaining control keys: the text widget default system-wide behaviour (chosen by Cincom) will override the window-specific behaviour (chosen by the developer). And there's no easy way for the developer to change that. That's what I think is wrong.

Perhaps we need an order of processing like that which I suggested in vw-dev:

1) developer-specified per-widget key bindings in the focused widget

2) developer-specified per-window (=menu bar) key bindings

3) Cincom-specified base key bindings in the focused widget

4) Cincom-specified base key bindings for the window

There's not much in 4) at present, but Esc for dialogs probably counts, and maybe something like Alt+F4 for closing on Windows.

This approach would keep the nice clean theory of Travis's approach without breaking existing applications, and would make creating new applications easy and intuitive for beginners. It also adds a nice 'soft' degree of separation between the base code and developers' own code (in other words: to change things we could write our own methods, rather than having to override base code).

Cheers,

Steve

From: [hidden email] on behalf of Michael Lucas-Smith
Sent: Wed 17/03/2010 21:33
To: [hidden email]
Subject: Re: [vwnc] vw7.7 & keyboard shortcuts

On 3/17/10 11:35 AM, Steven Kelly wrote:

I agree with what you say, Travis – I remember agreeing with the theory back when this was discussed. But what about the practice? What’s your advice for the Notepad app? Should beginners really have to make per-widget changes to the keyboard dispatch mappings just to be able to allow the menu bar to receive events?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: vw7.7 & keyboard shortcuts

In reply to this post by Steven Kelly

I note that both the Mac and Windows pages explicitly say that some events are handled in order down the containment hierarchy, and others are handled up the containment hierarchy. In particular, the Mac Command keys (the equivalent of Windows Control keys, yes?) are handled down the hierarchy. Admittedly the menu bar isn't included in that hierarchy, being processed last if nobody else wants the event, but then the Mac concept of menu bar is different, being significantly more separated from the application window.

It's interesting too that Apple had to make a correction in 10.5, because the previous system was unreliable for specifying ctrl-keys for menu bar items. Since then, the ctrl-key event is passed first to the window for the menus, and only then to the container hierarchy. (Since I'm not a Mac programmer, correct my interpretation from here:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html#//apple_ref/doc/uid/10000060i-CH7-SW11)

In any case, I believe the situation for VW is significantly different than for Mac or particularly Windows apps in general. In Windows there is no high level mechanism for specifying events: you have to write low-level code like "key = $O and: [key modifiers includes: #Ctrl]". There's less provided as base behaviour by the "widget vendor", and more the expectation that every single key binding in every widget will be lovingly hand-crafted. Part of the power of VW is that we don't have to mess around at that low level - unless we want to.

Cheers,

Steve

From: [hidden email] on behalf of Travis Griggs
Sent: Wed 17/03/2010 20:04
To: VWNC NC
Subject: Re: [vwnc] vw7.7 & keyboard shortcuts

On Mar 17, 2010, at 7:22 AM, Steven Kelly wrote:

I submit that the change was made with good intentions, and the design was plausible, but in fact the menu bar should have priority over the text widget’s keyboard mapping. Individual ApplicationModel windows often want to specify their own control keys to override default behavior; the other way round is less common. As Mark Plas said, “There hasn’t been a need for a widget to override the menu bar behavior. If a widget does something special with Ctrl-<key>, then Ctrl-<key> is also in the menu bar. In our applications it would be strange that the menu bar would say 'Ctrl-F' does 'Find' and in a specific widget 'Ctrl-F' would be overridden to mean 'Inspect'”.

What we did find was this document:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW11

About half way thru, there's a nice flow diagram and this statement:

"If the message isn’t handled by an object in the view hierarchy, NSApp then sends it to the menus in the menu bar."

I have read thru the following WPF documents:

http://msdn.microsoft.com/en-us/library/ms754010.aspx

http://msdn.microsoft.com/en-us/library/ms753391.aspx

http://msdn.microsoft.com/en-us/library/ms752308.aspx

http://msdn.microsoft.com/en-us/library/ms742806.aspx

Part of the problem (I think) is that the work begun in 7.7 is evolutionary, and there are incomplete parts.

For example, it was noted that we may hit a text handling widget twice with the same key, because of the fallback line at the bottom of KeyboardProcessor>>processKeyboardEvent:.

Travis Griggs

Objologist

Light travels faster than sound. This is why some people appear bright until you hear them speak...

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Richard Kulisz

Re: vw7.7 & keyboard shortcuts

In reply to this post by Michael Lucas-Smith-2

> steps to correct this. There isn't that much that the text editor
> should directly know about wrt to 'text editing'.. cut, copy, paste,
> undo, redo ..

Oh really? Perhaps you refer to a craptastic text editor but a half-way decent one will have all of the following:

representation - basic
- a browseable logarithmic sequence of deltas
- visual annotation in-text of the nearest deltas (eg, strike-through for deleted text) lingering for a few seconds
- automatic paragraph numbering
- optional automatic renumbering of paragraph number references when you add, delete and join paragraphs and non-intrusive resolution queries when you split paragraphs

navigation
- play forward and backward the deltas - as any sequence ought be able to
- speed up / slow down playing (also determines how long things like strike-through of deleted text lingers during normal editing, which is of course a play mode)
- goto <insert version number>
- goto <inserrt paragraph number>

filtering (replaces so-called "searching")
- colour highlighting of filtered words
- multiple filters with results in multiple colours
- browseable stack of filters
- goto next/previous highlit section of any colour, of a specific colour, with multiple colours near each other

sorts (named so for a reason I won't get into)
- show the last X deltas

zooming - advanced representation
- zooming into a filter ought to bring up a list of all matches (so-called "search results") with line numbers and context
- this is necessary for mass-edit (so-called "search and replace")

then there's multiple selections, leftBound / rightBound / yank (ever had to select *almost* all text?), and also the unique dynamics necessary to make all these menus and options work intuitively without having to memorize any so-called "shortcuts" or mouse through any menus. Yes I freely admit I'm divulging all of these great ideas because there's no hope you can get them to work in a way users will tolerate.

and then there's actions which I won't go into but it's what printIt and doIt are as well as mass-edit, allUppercase.

Note that I'm not talking about so-called "word processors" that pretty-print crap for paper. If I had, I would have mentioned that with the web's ascendancy even page numbering for paper is obsolete and only paragraph numbering is tolerable (used on at least one beautiful website http://chinaperspectives.revues.org/document647.html and in a modified form in all serious math books). Same for footnotes vs sidenotes. Nor am I talking about annotators or notetakers or threaders or communicators. I'm talking about rudimentary text editing for flat text here. Just you know, non-braindead.

Come on, I dare you to tell me you don't want useable infinite-level undo / redo.

And I double-dare you to tell me that an object-oriented user-interface isn't superior to the pseudo-imperative crap we suffer under today. Just know there's a special hell for people who love Smalltalk but disdain OO.

Punch through that box you're stuck in Michael. And then burn it and scatter the ashes.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

thomas.hawker

Re: vw7.7 & keyboard shortcuts

In reply to this post by Steven Kelly

The one thing I think that’s missed here (but I could be brain-fried) is configurability. I hate the thought of introducing yet another policy object, yet I think this fits the pattern well. We could have a “compatible” resolution policy, then a “modern” resolution policy, or anything an application might want as special case – such as process Ctrl keys first this way, Alt keys first that way, everything else some other way.

Classic Smalltalk GUIs, even trivial ones, do not seem to benefit from the reinterpretation of the rules, and the manner in which this has manifested implies that most or all of us were ill-prepared and didn’t expect it (read that “blindsided” even if the changes were in place months before). My company’s enterprise application would fail dramatically and it would require an intensive effort to fix this behavior change. Someone mentioned tens of applications – we have hundreds of windows and thousands of UI classes, resulting in extremely complex presentations for our business. Changing the whodunit behavior just is not viable; we need an easy way to select how we want it to work.

Cheers!

Tom Hawker
Senior Framework Developer
Home	+1 (408) 274-4128	The Environment: *We take it personally*
Office	+1 (408) 576-6591
Mobile	+1 (408) 835-3643

From: [hidden email] [mailto:[hidden email]] On Behalf Of Steven Kelly
Sent: Wednesday, March 17, 2010 2:23 PM
To: Michael Lucas-Smith; [hidden email]
Subject: Re: [vwnc] vw7.7 & keyboard shortcuts

Perhaps we need an order of processing like that which I suggested in vw-dev:

1) developer-specified per-widget key bindings in the focused widget

2) developer-specified per-window (=menu bar) key bindings

3) Cincom-specified base key bindings in the focused widget

4) Cincom-specified base key bindings for the window

There's not much in 4) at present, but Esc for dialogs probably counts, and maybe something like Alt+F4 for closing on Windows.

Cheers,

Steve

From: [hidden email] on behalf of Michael Lucas-Smith
Sent: Wed 17/03/2010 21:33
To: [hidden email]
Subject: Re: [vwnc] vw7.7 & keyboard shortcuts

On 3/17/10 11:35 AM, Steven Kelly wrote:

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andre Schnoor

Re: vw7.7 & keyboard shortcuts

In reply to this post by Steven Kelly

Am 17.03.2010 um 22:23 schrieb Steven Kelly:

Perhaps we need an order of processing like that which I suggested in vw-dev:
1) developer-specified per-widget key bindings in the focused widget
2) developer-specified per-window (=menu bar) key bindings
3) Cincom-specified base key bindings in the focused widget
4) Cincom-specified base key bindings for the window

I am puzzled how the actual people who, at the end of the day, pay all our bills can always be forgotten? What about the /user/ ?

It is rather common for bigger applications that end users have the option to customize key bindings. They are missing from the top of your list ;-)

Otherwise I agree.

To a more or lesser extent, key binding is a user preference. IMO there should be not a single hard-wired key binding. All keys should be bound by exchangeable and customizable mappings that are linked along a responder chain up the controller hierarchy.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-3

Eating Crow (was: vw7.7 & keyboard shortcuts)

I apologize for the subject title, but it seems to fit well; from
Wikipedia:

'Eating crow (archaically, eating boiled crow) is an English-language
idiom meaning humiliation by admitting wrongness or having been proven
wrong after taking a strong position. Eating crow is presumably foul-
tasting in the same way that being proven wrong might be emotionally
hard to swallow. Eating crow is of a family of idioms having to do
with eating and being proven incorrect, such as to "eat dirt", to "eat
your words", and to "eat your hat" (or shoe).'

So I sat down Friday and determined to move beyond the maze of twisty
keyboard binding/resolution documents and just try it. I have been
able to write both a simple Windows MFC and OSX Cocoa app. At the end,
I didn't feel so bad for the VisualWorks learning curve anymore.
Truly, the rest of the world has been catching up with Smalltalk, if
at times, in ways we wish they hadn't. That aside, here's my findings:

1) Windows MFC

The app is a simple app. It has one text edit box. It has one menu
bar, with one menu item that does nothing. If the menu item has no
shortcut key, then I can enter text in the text box, and use ctrl-x to
cut the text out. IF I attach ctrl-x to the menu item, then even when
I have typed text in the text box and have the box focused, I can no
longer use ctrl-x to cut text. The window menu bar is taking precedence.

2) OSX Cocoa

The app is as above. In this case, I have to have the menu item
present, with shortcut binding, if I want to use cmd-x to cut at all.
I imagine, that as documented, if I figured out how to make a custom
view and used the event handling APIs to look for cmd-x, I could
implement a local override of the menu. But Steven's well put question
was "how are *normal* people supposed to do this." It would appear on
OSX, that normal people are expected to put most of their shortcuts on
menu items. Two things that makes it easier in that architecture to
enforce that. One is that they have a first class specification of the
focused widget as the menu item responder. IOW, you can specify for an
OSX menu item, not only the method to be sent, but the target, where
one of the logical targets is "whatever the active keyboard focused
widget is." The second is message eating nil. When DNUs on any object
return nil, it's not a big deal to have a menu item that will send the
message cut: to whatever is focused and if it doesn't know how, who
cares, oh well. You don't have to write code that determines whether
it can safely send the message. That all said, the fact that most
keyboard shortcuts are mapped thru the menu, rather than the widgets
in practice, makes the point that child widgets could override
somewhat irrelevant.

Conclusion. We got it wrong. We got it upside down. We got it backwards.

Past my sig, is patch for VW7.7 for its
KeyboardProcessor>>processKeyboardEvent:. Provided no "melt down"
feedback from anyone here, I'll notify support of the patch and put it
in a more formal setting.

For those following VW7.8 builds, you might be able to use this patch
there, but this will likely be included in a possibly different form
as part of AR 59581.

--
Travis Griggs
Objologist
"Dying men never wish they'd spent more time at the office"

processKeyboardEvent: aKeyboardEvent
"Search downwards from parent to child along the view tree path that
gets us to the current keyboard consumer, for an object that will
handle aKeyboardEvent and allow it to do so."

| stack part |
menuBar
ifNotNil:
[:theMenuBar |
"Conceptually, the menuBar sits as the top most component in view
tree, though it is not actually modeled such. so we start there."
((self isShortcutKeyboardEvent: aKeyboardEvent) and: [theMenuBar
processShortcutKeyEventInMenuBar: aKeyboardEvent]) ifTrue: [^self]].

"Now walk the chain downwards."
stack := OrderedCollection new.
part := self currentConsumer view.
[part isNil] whileFalse:
[stack addFirst: part.
(part container isKindOf: VisualPart) ifFalse: [part := nil]
ifTrue: [part := part container]].
stack do: [:each | (each handlerForKeyboardEvent: aKeyboardEvent)
ifNotNil: [:theHandler | ^theHandler handleEvent: aKeyboardEvent]].

"Finally, older widgets will not yet have implemented
handlerForKeyboardEvent: correctly to catch every keystroke they want
to capture.
We pass the event to the current consumer anyway. This only happens
when we didn't catch it as above."
self currentConsumer ifNotNil: [:theCurrentConsumer |
theCurrentConsumer handleEvent: aKeyboardEvent]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mark Plas

Re: Eating Crow (was: vw7.7 & keyboard shortcuts)

Hi Travis,

I've tried your patch in our application, but it sometimes crashes on this line:

part := self currentConsumer view.

There are cases where there isn't a currentConsumer and then it crashes on MNU #view. It requires a nil test (just like what happens at the bottom of the method).

Apart from this it seems to work fine and I can now remove the patch from Steven Kelly that checks for #ignoreInputKey: in DispatchTable>>maps:meta:.

Thanks for your effort!

Mark

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: maandag 22 maart 2010 18:14
To: VWNC NC
Cc: VW-Dev DEV
Subject: Eating Crow (was: vw7.7 & keyboard shortcuts)

I apologize for the subject title, but it seems to fit well; from
Wikipedia:

'Eating crow (archaically, eating boiled crow) is an English-language
idiom meaning humiliation by admitting wrongness or having been proven
wrong after taking a strong position. Eating crow is presumably foul-
tasting in the same way that being proven wrong might be emotionally
hard to swallow. Eating crow is of a family of idioms having to do
with eating and being proven incorrect, such as to "eat dirt", to "eat
your words", and to "eat your hat" (or shoe).'

So I sat down Friday and determined to move beyond the maze of twisty
keyboard binding/resolution documents and just try it. I have been
able to write both a simple Windows MFC and OSX Cocoa app. At the end,
I didn't feel so bad for the VisualWorks learning curve anymore.
Truly, the rest of the world has been catching up with Smalltalk, if
at times, in ways we wish they hadn't. That aside, here's my findings:

1) Windows MFC

The app is a simple app. It has one text edit box. It has one menu
bar, with one menu item that does nothing. If the menu item has no
shortcut key, then I can enter text in the text box, and use ctrl-x to
cut the text out. IF I attach ctrl-x to the menu item, then even when
I have typed text in the text box and have the box focused, I can no
longer use ctrl-x to cut text. The window menu bar is taking precedence.

2) OSX Cocoa

The app is as above. In this case, I have to have the menu item
present, with shortcut binding, if I want to use cmd-x to cut at all.
I imagine, that as documented, if I figured out how to make a custom
view and used the event handling APIs to look for cmd-x, I could
implement a local override of the menu. But Steven's well put question
was "how are *normal* people supposed to do this." It would appear on
OSX, that normal people are expected to put most of their shortcuts on
menu items. Two things that makes it easier in that architecture to
enforce that. One is that they have a first class specification of the
focused widget as the menu item responder. IOW, you can specify for an
OSX menu item, not only the method to be sent, but the target, where
one of the logical targets is "whatever the active keyboard focused
widget is." The second is message eating nil. When DNUs on any object
return nil, it's not a big deal to have a menu item that will send the
message cut: to whatever is focused and if it doesn't know how, who
cares, oh well. You don't have to write code that determines whether
it can safely send the message. That all said, the fact that most
keyboard shortcuts are mapped thru the menu, rather than the widgets
in practice, makes the point that child widgets could override
somewhat irrelevant.

Conclusion. We got it wrong. We got it upside down. We got it backwards.

Past my sig, is patch for VW7.7 for its
KeyboardProcessor>>processKeyboardEvent:. Provided no "melt down"
feedback from anyone here, I'll notify support of the patch and put it
in a more formal setting.

For those following VW7.8 builds, you might be able to use this patch
there, but this will likely be included in a possibly different form
as part of AR 59581.

--
Travis Griggs
Objologist
"Dying men never wish they'd spent more time at the office"

processKeyboardEvent: aKeyboardEvent
"Search downwards from parent to child along the view tree path that
gets us to the current keyboard consumer, for an object that will
handle aKeyboardEvent and allow it to do so."

| stack part |
menuBar
ifNotNil:
[:theMenuBar |
"Conceptually, the menuBar sits as the top most component in view
tree, though it is not actually modeled such. so we start there."
((self isShortcutKeyboardEvent: aKeyboardEvent) and: [theMenuBar
processShortcutKeyEventInMenuBar: aKeyboardEvent]) ifTrue: [^self]].

"Now walk the chain downwards."
stack := OrderedCollection new.
part := self currentConsumer view.
[part isNil] whileFalse:
[stack addFirst: part.
(part container isKindOf: VisualPart) ifFalse: [part := nil]
ifTrue: [part := part container]].
stack do: [:each | (each handlerForKeyboardEvent: aKeyboardEvent)
ifNotNil: [:theHandler | ^theHandler handleEvent: aKeyboardEvent]].

"Finally, older widgets will not yet have implemented
handlerForKeyboardEvent: correctly to catch every keystroke they want
to capture.
We pass the event to the current consumer anyway. This only happens
when we didn't catch it as above."
self currentConsumer ifNotNil: [:theCurrentConsumer |
theCurrentConsumer handleEvent: aKeyboardEvent]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly

Re: Eating Crow (was: vw7.7 & keyboard shortcuts)

In reply to this post by Travis Griggs-3

Thanks Travis, the patch (with the addition of Mark's currentConsumer
nil check) works well for getting the menu item shortcuts working again.

If we ignore menus: Compared to the base 7.7 version of the method,
which processed keys only in the currentConsumer, this version now
processes them in the container chain of the currentConsumer, with the
outermost container first. Do you have an example case where this is the
desired behavior?

Does your patch include the correction from AR58749, which re-enabled
processing of underlined widget label characters as Alt shortcuts? It
seems not to: load AR58749 then your change, and try out the attached
window. The button shortcut keys only seem to work if the button in
question already has focus. The group box shortcut keys should pick the
first button in that group, but never seem to do anything (presumably
because the group box can never have focus, nor is it ever (sadly) truly
the container of another widget - the Composite is the container).

How shortcut keys ought to work is interesting. Obviously if there are
no duplicate key mappings, they ought to work globally in the window (as
AR 58749 did). To work in all cases, including when there are
duplicates, I'd imagine you should look at the current widget first,
then go up to the immediate container and try ALL of the widgets it
contains (probably in breadth-first order), then up to the next
container and so on.

Steve

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
On

> Behalf Of Travis Griggs
> Sent: 22 March 2010 19:14
> To: VWNC NC
> Cc: VW-Dev DEV
> Subject: Eating Crow (was: vw7.7 & keyboard shortcuts)
>
>
> I apologize for the subject title, but it seems to fit well; from
> Wikipedia:
>
> 'Eating crow (archaically, eating boiled crow) is an English-language
> idiom meaning humiliation by admitting wrongness or having been proven
> wrong after taking a strong position. Eating crow is presumably foul-
> tasting in the same way that being proven wrong might be emotionally
> hard to swallow. Eating crow is of a family of idioms having to do
> with eating and being proven incorrect, such as to "eat dirt", to "eat
> your words", and to "eat your hat" (or shoe).'
>
>
> So I sat down Friday and determined to move beyond the maze of twisty
> keyboard binding/resolution documents and just try it. I have been
> able to write both a simple Windows MFC and OSX Cocoa app. At the end,
> I didn't feel so bad for the VisualWorks learning curve anymore.
> Truly, the rest of the world has been catching up with Smalltalk, if
> at times, in ways we wish they hadn't. That aside, here's my findings:
>
> 1) Windows MFC
>
> The app is a simple app. It has one text edit box. It has one menu
> bar, with one menu item that does nothing. If the menu item has no
> shortcut key, then I can enter text in the text box, and use ctrl-x to
> cut the text out. IF I attach ctrl-x to the menu item, then even when
> I have typed text in the text box and have the box focused, I can no
> longer use ctrl-x to cut text. The window menu bar is taking

precedence.

>
> 2) OSX Cocoa
>
> The app is as above. In this case, I have to have the menu item
> present, with shortcut binding, if I want to use cmd-x to cut at all.
> I imagine, that as documented, if I figured out how to make a custom
> view and used the event handling APIs to look for cmd-x, I could
> implement a local override of the menu. But Steven's well put question
> was "how are *normal* people supposed to do this." It would appear on
> OSX, that normal people are expected to put most of their shortcuts on
> menu items. Two things that makes it easier in that architecture to
> enforce that. One is that they have a first class specification of the
> focused widget as the menu item responder. IOW, you can specify for an
> OSX menu item, not only the method to be sent, but the target, where
> one of the logical targets is "whatever the active keyboard focused
> widget is." The second is message eating nil. When DNUs on any object
> return nil, it's not a big deal to have a menu item that will send the
> message cut: to whatever is focused and if it doesn't know how, who
> cares, oh well. You don't have to write code that determines whether
> it can safely send the message. That all said, the fact that most
> keyboard shortcuts are mapped thru the menu, rather than the widgets
> in practice, makes the point that child widgets could override
> somewhat irrelevant.
>
> Conclusion. We got it wrong. We got it upside down. We got it

backwards.

>
> Past my sig, is patch for VW7.7 for its
> KeyboardProcessor>>processKeyboardEvent:. Provided no "melt down"
> feedback from anyone here, I'll notify support of the patch and put it
> in a more formal setting.
>
> For those following VW7.8 builds, you might be able to use this patch
> there, but this will likely be included in a possibly different form
> as part of AR 59581.
>
> --
> Travis Griggs
> Objologist
> "Dying men never wish they'd spent more time at the office"
>
> processKeyboardEvent: aKeyboardEvent
> "Search downwards from parent to child along the view tree path
> that
> gets us to the current keyboard consumer, for an object that will
> handle aKeyboardEvent and allow it to do so."
>
> | stack part |
> menuBar
> ifNotNil:
> [:theMenuBar |
> "Conceptually, the menuBar sits as the top most
> component in view
> tree, though it is not actually modeled such. so we start there."
> ((self isShortcutKeyboardEvent: aKeyboardEvent)

and:

> [theMenuBar
> processShortcutKeyEventInMenuBar: aKeyboardEvent]) ifTrue: [^self]].
>
> "Now walk the chain downwards."
> stack := OrderedCollection new.
> part := self currentConsumer view.
> [part isNil] whileFalse:
> [stack addFirst: part.
> (part container isKindOf: VisualPart) ifFalse:
> [part := nil]
> ifTrue: [part := part container]].
> stack do: [:each | (each handlerForKeyboardEvent:

aKeyboardEvent)

> ifNotNil: [:theHandler | ^theHandler handleEvent: aKeyboardEvent]].
>
> "Finally, older widgets will not yet have implemented
> handlerForKeyboardEvent: correctly to catch every keystroke they want
> to capture.
> We pass the event to the current consumer anyway. This only
> happens
> when we didn't catch it as above."
> self currentConsumer ifNotNil: [:theCurrentConsumer |
> theCurrentConsumer handleEvent: aKeyboardEvent]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

GroupTest.st (2K) Download Attachment