[Cuis-dev] PluggableListMorph siblings navigation and scrolling

[Luciano Notarfrancesco]

Hi,
After we changed the browser to show system categories as a tree (or forest
actually) we partially lost the feature to navigate between the lists with
the arrow keys. This is because HierarchicalListMorph uses the left-right
arrow keys to navigate the tree.
I've been experimenting with ideas to add back this feature, and this is
what I have so far. It's just an experiment, I'd like to know what other
people think about this change.

Basically, I got rid of the "left/right siblings concept" and instead I use
the right-left arrows (or TAB and SHIFT-TAB) to navigate between all morphs
in the active window that handle keyboard focus. This simplifies the code
in PluggableListMorph and the methods that use it, since they don't need to
explicitly set siblings. The behavior is slightly different from the
original implementation, I'm not sure if it would bother anyone that is
already used to the original behavior, let me know what you think. With
this change set, the keyboard navigation in the browser works again, with
the caveat that you have to use TAB and SHIFT-TAB instead of left-right (or
we should change the handler of left-right in HierarchicalListMorph to use
some other keys).

While testing this I found a little bug: for some reason, SHIFT-TAB is sent
twice unless SHIFT is unpressed before unpressing TAB. I have to
investigate this further, but I think it is a bug in the event dispatching
mechanism, not a bug in my code.

Also, I got rid of the feature to scroll two lists together. I think this
would be better implemented with some sort of PluggableMultiColumnListMorph
or something like that. The only tools that used this functionality are the
Change Sorter and the Package List. They used it to show a "dirty flag"
(i.e., whether a change set or package has unsaved changes). Instead of
showing this dirty flag in a list, I show it with an asterisk at the
begining of the change set or package name. I like it because IMO it looks
better than the original implementation, wastes less real estate, it is a
well known UI pattern, and the code is simpler.

Let me know what you think, whether I should continue in this direction and
test this code better in order to integrate it, or if you think this change
is a bad idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220617/91fbe0db/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5303-SiblingsRework-LucianoEstebanNotarfrancesco-2022Jun17-06h01m-len.002.cs.st
Type: application/octet-stream
Size: 20084 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220617/91fbe0db/attachment-0001.obj>