[Cuis-dev] PluggableListMorph siblings navigation and scrolling

[Juan Vuletich]

Pushed to GitHub.

Thanks,

On 6/17/2022 4:37 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> Cool, I think it’s best to use only left/right and shift-left/right 
> and remove tab.
>
> On Fri, 17 Jun 2022 at 9:54 PM Juan Vuletich <JuanVuletich at zoho.com 
> <mailto:JuanVuletich at zoho.com>> wrote:
>
>     Hi Luciano,
>
>     I really like this. The attach includes two further tweaks. One is
>     to enable shift-arrows to change focus. I find this nicer
>     especially for HierarchicalList. I also made lists to auto select
>     the first item if none selected.
>
>     Folks, if you all agree, we'd integrate these.
>
>     Thanks,
>
>
>     On 6/17/2022 9:07 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>>     Here's an updated version. I added back the feature to scroll
>>     siblings, because it turns out the Package List tool still needs
>>     it. But this time I used a property instead of an instance
>>     variable, and I set it up by calling >>#scrollSiblings: with a
>>     collection of siblings to scroll  with the receiver instead of
>>     relying on the original leftSibling and rightSibling instance
>>     variables. The biggest changes in this change set are:
>>     - rework of sibling navigation using a more general approach
>>     instead of leftSibling and rightSibling (navigate all morphs that
>>     handle keyboard focus in the same system window using left/right
>>     arrows and TAB/SHIFT-TAB, works for PluggableListMorph and
>>     HierarchicalListMorph and be be easily extended to other morphs);
>>     - change in Change Sorter and Package List to show the dirty flag
>>     as an asterisk in the change set or package name instead of using
>>     an extra list.
>>
>>     Let me know what you think. Thanks,
>>     Luciano
>>
>>     On Fri, Jun 17, 2022 at 8:07 AM Luciano Notarfrancesco
>>     <luchiano at gmail.com <mailto:luchiano at gmail.com>> wrote:
>>
>>         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.
>>
>
>
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     https://independent.academia.edu/JuanVuletich
>     https://www.researchgate.net/profile/Juan-Vuletich
>     https://patents.justia.com/inventor/juan-manuel-vuletich
>     https://twitter.com/JuanVuletich
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220620/2ad15b97/attachment.htm>