Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour
New issue 1099 by usman.bh...@gmail.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
Tree/list presentation should display non-visible items when one of these items is selected. To reproduce, execute the following script. Normally, the of items should be expanded and 14 should be shown in the list on the left because it is the current selection item. However, the list does not change and 14 is not shown.
browser := GLMTabulator new. browser column: #one; column: #two. browser transmit to: #one; andShow: [:a | a list showOnly: 10; display: [:number | (1 to: number)] ]. browser transmit to: #two; from: #one; andShow: [:a | a roassal2 initializeView: [ RTMondrianViewBuilder new ]; painting: [:view :number | view interaction when: TRMouseDoubleClick do: [:ann | ((browser paneNamed: #one) port:#selection) value: ann element model ]. view shape label. view nodes: (1 to: number + 5). view edgesFrom: [:each | each // 2 ]. view treeLayout ]]. browser openOn: 100. ((browser paneNamed: #one) port: #selection) value: 14.
Comment #1 on issue 1099 by tu...@tudorgirba.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
Thanks. I think with the current list implementation we cannot handle this use case. Imagine you would have a 100k items in your list and you would select the last item. It would mean that we have to show the whole list, but this is precisely the point of the paging. The same mechanism is actually used also when you write a selection query for a group, so having 100k items is not an unusual case.
I agree that it is not intuitive, but handling it will require a new implementation of the list. For example, we can imagine having some sort of ... in the middle of the list and show only the selected items (in your case it would be (1,2,3,4,5,6,7,8,9,10 ... 14) . We will likely get to it but not in the near future, unfortunately.
Or do you have another idea?
Comment #2 on issue 1099 by usman.bh...@gmail.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
As per my understanding, PaginatedMorphTreeMorph can have two modes of expansion: incremental mode or scroll to the page of selected element(s). Incremental mode expands the list up to the selected item. Paged mode shows a fixed number of elements on each page and jump to a specific page item selected. To see it working, execute script below:
| treeMorph aWindow aModel | aModel := PaginatedMorphTreeModel new rootItems: (1 to: 100) asArray. aWindow := aModel theme newWindowIn: World for: aModel title: 'test'. treeMorph := aModel defaultTreeMorph. treeMorph pageSize: 30. treeMorph buildContents. aWindow addMorph: treeMorph fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1) offsets: (0 @ 0 corner: 0 @ 0)). aWindow open. aModel expandItemPath: {50}.
Glamour chooses the incremental mode and effectively this mode is not adapted for 100K items. In my opinion, we should use paged mode and it should not require drastic changes to the current tree model in Glamour.
As for the bug, the solution will be that the model needs to do expandItemPath: when a selection is made and update list. And I should provide a fix once we find an agreement on the selection display mode.
Comment #3 on issue 1099 by usman.bh...@gmail.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
So, here is a proposal for paged list in Glamour. The changes are not drastic. You can try it with this script. MorphNodeTreeMorph was changed to adapt the position of children. It is not a bug itself because original MorhTreeMorph does not allow to create children but since subclasses do, it has to provide this service, IMO.
browser := GLMTabulator new. browser column: #one; column: #two. browser transmit to: #one; andShow: [:a | a tree children: [:one :two :level | level <2 ifTrue: [{level}]]; showOnly: 10; display: [:number | (2 to: number)] ]. browser transmit to: #two; from: #one; andShow: [:a | a roassal2 initializeView: [ RTMondrianViewBuilder new ]; painting: [:view :number | view interaction when: TRMouseDoubleClick do: [:ann | ((browser paneNamed: #one) port:#selection) value: ann element model ]. view shape label. view nodes: (1 to: number + 5). view edgesFrom: [:each | each // 2 ]. view treeLayout ]]. browser openOn: 100. ((browser paneNamed: #one) port: #selection) value: 15
Let me know what do you think.
Attachments: Glamour-Morphic-Renderer-usmanbhatti.300.mcz 62.0 KB Glamour-Morphic-Widgets-usmanbhatti.152.mcz 55.1 KB Morphic-Base-usmanbhatti.296.mcz 654 KB
Comment #4 on issue 1099 by tu...@tudorgirba.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
The problem with this is that it introduces paging and I specifically do not want that :(
Comment #5 on issue 1099 by usman.bh...@gmail.com: update visible list items on selection https://code.google.com/p/moose-technology/issues/detail?id=1099
In my opinion, paging is more adapted for long lists.
-> you don't have to scroll to the 50kth element at the end to see your selection. -> page size can be modified by the user. -> I ve seen ppl thinking that a list is incomplete but they only know that they are looking at a partial view when they reach at the bottom when scroll arrows appear...
-
moose-technology＠googlecode.com