On 11/7/17, Marcel Taeumel marcel.taeumel@hpi.de wrote:
At the level of ToolBuilder, one would rather have to specify a "tab order" and whether such a feature is enabled for a particular view or not. It would be like one or two additional fields in PluggableWidgetSpec. No need to talk about implementation details such as "siblings" at that abstract spec level.
Good idea to capture (filter out) the TAB event at a higher level. Let's do more analysis on how this could be done.
We could rely on a default TAB order which is just the order in which the elements were added (not including the switches) [4]
Considering the actual implementation: there has been a "tabAmongFields", which might origin from Etoys. In the MorphicToolBuilder, I would simply add event filters for keyboard events at the level of PluggablePanelMorph and/or SystemWindow.
PluggablePanelMorph does not seem to be used at all. In particular not in the Browser which is the most interesting tool to have the TAB key cycling through the panes. [5]
So it is probably rather the SystemWindow class which is to be used.
You do not have to deal with implementation details in TextMorphs etc. If "tab" would be the key, "tab" would just not reach the TextMorph anymore. :-) ... off the top of my hat ... maybe like half a day work including tests. Not many new lines of code...
How is the method called to be used to filter out the TAB event?
specialKeyPressed: as well?
Regards
Hannes
Best, Marcel Am 07.11.2017 09:24:12 schrieb H. Hirzel hannes.hirzel@gmail.com: A modest but very useful enhancements would be to have the TAB key changing between panes in the Browser [1] as it is an often used tool.
The method PluggableListMorph specialKeyPressed: asciiValue [3]
shows what is currently interpreted. However all the keystrokes apply only locally to the list.
Next thing to find out is if it is possible in tools built with the ToolBuilder [2] framework how to get access to a sibling lists....
--Hannes
[4] Browser buildDefaultBrowserWith: builder "assemble the spec for a full system browser, build it and return the built but not opened morph" "this build-but-don't-open phase is factored out to support the prototypicalToolWindow facility"
| max windowSpec | max := self wantsOptionalButtons ifTrue:[0.42] ifFalse:[0.5].
windowSpec := self buildWindowWith: builder specs: { (0@0 corner: 0.25@max) -> [self buildSystemCategoryListWith: builder]. (self classListFrame: max) -> [self buildClassListWith: builder]. (self switchesFrame: max) -> [self buildSwitchesWith: builder]. (0.5@0 corner: 0.75@max) -> [self buildMessageCategoryListWith: builder]. (0.75@0 corner: 1@max) -> [self buildMessageListWith: builder]. (0@max corner: 1@1) -> [self buildCodePaneWith: builder]. }. self setMultiWindowFor:windowSpec.
^builder build: windowSpec
[5] PluggablePanelMorph http://wiki.squeak.org/squeak/2748