<div dir="ltr">Hi,<div>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.</div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>