[squeak-dev] Keyboard navigation in browsers?
Marcel Taeumel
marcel.taeumel at hpi.de
Wed Nov 8 10:03:15 UTC 2017
Hi Hannes,
just open SystemWindow >> #filterEvent:for: and add your tabbing logic. Access the currently focused morph via "anEvent hand keyboardFocus", compute a list of focus targets in the window via "self paneMorphs", unpack pluggable panels, choose the next focus holder, set the focus via "anEvent hand newKeyboardFocus: ...", and cancel event handling via "anEvent ignore".
Of course we need PluggablePanelMorph for layout composition. The entire lower area in the browser is a panel. :)
Best,
Marcel
Am 08.11.2017 10:40:08 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
On 11/7/17, Marcel Taeumel 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 :
> 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 at 0 corner: 0.25 at max) -> [self buildSystemCategoryListWith: builder].
(self classListFrame: max) -> [self buildClassListWith: builder].
(self switchesFrame: max) -> [self buildSwitchesWith: builder].
(0.5 at 0 corner: 0.75 at max) -> [self buildMessageCategoryListWith: builder].
(0.75 at 0 corner: 1 at max) -> [self buildMessageListWith: builder].
(0 at max corner: 1 at 1) -> [self buildCodePaneWith: builder].
}.
self setMultiWindowFor:windowSpec.
^builder build: windowSpec
[5] PluggablePanelMorph http://wiki.squeak.org/squeak/2748
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171108/26d3357a/attachment.html>
More information about the Squeak-dev
mailing list
|