Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano Peck and Guido Chari we have been trying to address issue 11605<https://pharo.fogbugz.com/default.asp?pre=preMultiSearch&pg=pgList&pgBack=pg...>, i.e. using NewList in Nautilus. I am still trying to finish with this task, and I have a few questions, may be somebody here can enlighten me. We have encountered some problems with multiple selections. First, the list has 4 ValueModels for its selected elements: selectedIndex, selectedIndexes, selectedItem, selectedItems. I would like to understand more clearly how should we use them. In particular I find difficult to bring the plural versions and the singular versions together. If I select more than one element in the list, it seems that the value in the selectedItem/selectedIndex points to the last one I clicked. But then the model in Nautilus is receiving two updates, one from selectedItem/Index and the other from selectedItems/indexes, should we just ignore the singular one or what? Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this? Finally, another question not related to multiple selections. The old list (it was a PluggableIconListMorph) has a "searchedElement" attribute. Looking at the categories list in Nautilus, the usage is so: if you have not selected any category (i.e. you are seeing the method of all categories in a class) and you click on a method in the method list, the searched element of the category list points to the category of the selected method. This is different from selecting the category, because selecting the category would filter the method list. It also highlights the category in a different color. So, my question is, should we keep this behaviour while migrating Nautilus to new lists o not? If the answer is yes, I would ask how to do it, because the NewList does not seem to have this feature. Should I add the searchedElement to the NewList or is there another way to achieve the same behavior?
Ben? :D On Mon, Sep 16, 2013 at 4:18 PM, Nicolas Passerini <npasserini@gmail.com>wrote:
Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano Peck and Guido Chari we have been trying to address issue 11605<https://pharo.fogbugz.com/default.asp?pre=preMultiSearch&pg=pgList&pgBack=pg...>, i.e. using NewList in Nautilus. I am still trying to finish with this task, and I have a few questions, may be somebody here can enlighten me.
We have encountered some problems with multiple selections. First, the list has 4 ValueModels for its selected elements: selectedIndex, selectedIndexes, selectedItem, selectedItems. I would like to understand more clearly how should we use them. In particular I find difficult to bring the plural versions and the singular versions together. If I select more than one element in the list, it seems that the value in the selectedItem/selectedIndex points to the last one I clicked. But then the model in Nautilus is receiving two updates, one from selectedItem/Index and the other from selectedItems/indexes, should we just ignore the singular one or what?
Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this?
Finally, another question not related to multiple selections. The old list (it was a PluggableIconListMorph) has a "searchedElement" attribute. Looking at the categories list in Nautilus, the usage is so: if you have not selected any category (i.e. you are seeing the method of all categories in a class) and you click on a method in the method list, the searched element of the category list points to the category of the selected method. This is different from selecting the category, because selecting the category would filter the method list. It also highlights the category in a different color.
So, my question is, should we keep this behaviour while migrating Nautilus to new lists o not? If the answer is yes, I would ask how to do it, because the NewList does not seem to have this feature. Should I add the searchedElement to the NewList or is there another way to achieve the same behavior?
On 2013-09-16, at 11:18, Nicolas Passerini <npasserini@gmail.com> wrote:
Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this?
yes, that is actually the part gisela and nahuel hacked on during the sprint. Seems like this combination of key modifiers + mouse click is not properly reported to the image :/.
On Sep 16, 2013, at 4:18 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano Peck and Guido Chari we have been trying to address issue 11605, i.e. using NewList in Nautilus. I am still trying to finish with this task, and I have a few questions, may be somebody here can enlighten me.
We have encountered some problems with multiple selections. First, the list has 4 ValueModels for its selected elements: selectedIndex, selectedIndexes, selectedItem, selectedItems. I would like to understand more clearly how should we use them. In particular I find difficult to bring the plural versions and the singular versions together. If I select more than one element in the list, it seems that the value in the selectedItem/selectedIndex points to the last one I clicked. But then the model in Nautilus is receiving two updates, one from selectedItem/Index and the other from selectedItems/indexes, should we just ignore the singular one or what?
If your UI is based on multi selection (and Nautilus definitely is) you should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:, but only the plural version.
Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this?
VM ?
Finally, another question not related to multiple selections. The old list (it was a PluggableIconListMorph) has a "searchedElement" attribute. Looking at the categories list in Nautilus, the usage is so: if you have not selected any category (i.e. you are seeing the method of all categories in a class) and you click on a method in the method list, the searched element of the category list points to the category of the selected method. This is different from selecting the category, because selecting the category would filter the method list. It also highlights the category in a different color.
So, my question is, should we keep this behaviour while migrating Nautilus to new lists o not?
Yes we should :)
If the answer is yes, I would ask how to do it, because the NewList does not seem to have this feature. Should I add the searchedElement to the NewList or is there another way to achieve the same behaviour?
As far as I remember, this feature exists in NewList, but I do not think it's publicly exposed. But I would like to finish by saying we (the community) should better put effort on the Spec based Nautilus new version that the NewList in Nautilus. The event mechanism between PluggableListMorph and NewList is so different, it will be really painful for you guys :) MCHttpRepository location: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/Nautilus/main' user: '' password: '' Ben
If your UI is based on multi selection (and Nautilus definitely is) you should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:, but only the plural version.
Ok, I get that. Still, when you create a NewList you have to provide a setIndexSelector, for example in the CategoryWidget I am doing: categoriesList := NewList on: self getItemsSelector: #getCategories setIndexSelector: #selectedCategoryIndex: getDisplaySelector: #categoryWrapper:. So, every time you click on the categories list (both selecting multiple categories or not) the CategoryWidget receives the #selectedCategoryIndex: message. The current selectedCategoryIndex: message reads like this: selectedCategoryIndex: anInteger | anObject | anObject := self getCategories at: anInteger ifAbsent: [ nil ]. self model selectedCategory: anObject. self changed: #selectedCategoryIndex. self model categorySelectionChanged. self model changed: #currentHistoryIndex. Also the NewList is in the list of dependents of the CategoryWidget, so it also gets the #update: message Is this right?
If you want to react to some selection, you should better use whenSelectedItemChanged: I guess Ben On Sep 17, 2013, at 4:00 AM, Nicolas Passerini <npasserini@gmail.com> wrote:
If your UI is based on multi selection (and Nautilus definitely is) you should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:, but only the plural version.
Ok, I get that. Still, when you create a NewList you have to provide a setIndexSelector, for example in the CategoryWidget I am doing:
categoriesList := NewList on: self getItemsSelector: #getCategories setIndexSelector: #selectedCategoryIndex: getDisplaySelector: #categoryWrapper:.
So, every time you click on the categories list (both selecting multiple categories or not) the CategoryWidget receives the #selectedCategoryIndex: message. The current selectedCategoryIndex: message reads like this:
selectedCategoryIndex: anInteger
| anObject | anObject := self getCategories at: anInteger ifAbsent: [ nil ]. self model selectedCategory: anObject.
self changed: #selectedCategoryIndex. self model categorySelectionChanged. self model changed: #currentHistoryIndex.
Also the NewList is in the list of dependents of the CategoryWidget, so it also gets the #update: message Is this right?
A note about click and control/alt. Now for unix system the command in mac is equivalent to the alt key. Particularry alt + click are catched by the os (to do some fancy windows moves). So what works in mac as command + click is mapped in unix as alt + click. 2013/9/17 Benjamin <benjamin.vanryseghem.pharo@gmail.com>
If you want to react to some selection, you should better use whenSelectedItemChanged: I guess
Ben
On Sep 17, 2013, at 4:00 AM, Nicolas Passerini <npasserini@gmail.com> wrote:
If your UI is based on multi selection (and Nautilus definitely is) you
should not register to whenSelectedIndexChanged:/whenSelectedItemChanged:, but only the plural version.
Ok, I get that. Still, when you create a NewList you have to provide a setIndexSelector, for example in the CategoryWidget I am doing:
categoriesList := NewList on: self getItemsSelector: #getCategories setIndexSelector: #selectedCategoryIndex: getDisplaySelector: #categoryWrapper:.
So, every time you click on the categories list (both selecting multiple categories or not) the CategoryWidget receives the #selectedCategoryIndex: message. The current selectedCategoryIndex: message reads like this:
selectedCategoryIndex: anInteger
| anObject | anObject := self getCategories at: anInteger ifAbsent: [ nil ]. self model selectedCategory: anObject. self changed: #selectedCategoryIndex. self model categorySelectionChanged. self model changed: #currentHistoryIndex.
Also the NewList is in the list of dependents of the CategoryWidget, so it also gets the #update: message Is this right?
Thanks nicolas! I love to read this mail :) Stef On Sep 16, 2013, at 4:18 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
Last Saturday in the Pharo Sprint in Buenos Aires, together with Mariano Peck and Guido Chari we have been trying to address issue 11605, i.e. using NewList in Nautilus. I am still trying to finish with this task, and I have a few questions, may be somebody here can enlighten me.
We have encountered some problems with multiple selections. First, the list has 4 ValueModels for its selected elements: selectedIndex, selectedIndexes, selectedItem, selectedItems. I would like to understand more clearly how should we use them. In particular I find difficult to bring the plural versions and the singular versions together. If I select more than one element in the list, it seems that the value in the selectedItem/selectedIndex points to the last one I clicked. But then the model in Nautilus is receiving two updates, one from selectedItem/Index and the other from selectedItems/indexes, should we just ignore the singular one or what?
Second, in my linux the list doesn't seem to receive ctrl+click events. Any clue about this?
Finally, another question not related to multiple selections. The old list (it was a PluggableIconListMorph) has a "searchedElement" attribute. Looking at the categories list in Nautilus, the usage is so: if you have not selected any category (i.e. you are seeing the method of all categories in a class) and you click on a method in the method list, the searched element of the category list points to the category of the selected method. This is different from selecting the category, because selecting the category would filter the method list. It also highlights the category in a different color.
So, my question is, should we keep this behaviour while migrating Nautilus to new lists o not? If the answer is yes, I would ask how to do it, because the NewList does not seem to have this feature. Should I add the searchedElement to the NewList or is there another way to achieve the same behavior?
participants (6)
-
Benjamin -
Camillo Bruni -
Gisela Decuzzi -
Guillermo Polito -
Nicolas Passerini -
Stéphane Ducasse