[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