Hi,
1) this is caused by this line in "listIntConfiguration" dragTransformationBlock: [ :item | item asInteger ]; you are dragging a symbol c, but "#c asInteger = nil" 2) dragging the number converts it into a StringMorph which obviously isn't in the original collection. This is quite [expletive], because each list behaves differently: * ListModel the passenger is the object converted to a Morph, * IconListModel (a subclass of ListModel) has as a passenger IconListItem that holds reference to the original object * FastTableModel (a subclass of ListModel) will just break down on drag * MultiColumnListModel (a subclass of ListModel) won't even launch * NewListModel breaks down on drag * TreeModel has a different API, but also breaks down on drag Fun, ain't it? 3) probably similar to (2), didn't have the energy to investigate… NOW: In general, the drag and drop behavior, the API, and the overall behavior is broken to a various degree and inconsistent between ListModel, it's children and related classes (TreeModel, NewListModel). Last week I was working on a File Dialog replacement https://github.com/peteruhnak/file-dialog and the brokenness and inconsistencies were really frustrating. I don't see a point in trying to write a book about this particular section because it's really bad right now. Of course not having a dedicated maintainer of Spec makes life a lot harder, as people that work with/on Spec generally invest into Spec at their own time discretion (me included), so while bugs can generally be fixed, there's really no systematic effort in cleanup and API harmonization. With Stef we started to clean up and rethink it a bit when I was in Lille because there's a lot of things we don't like or should fix, but that's a long-term plan. We need a more immediate solution for the current mess. -_- TL;DR: 1. imho no point in documenting this stuff _right now_ 2. it's seriously broken 3. we need to clean it up and harmonize first Peter On Thu, Jun 9, 2016 at 3:52 PM, Marion Noirbent <[hidden email]> wrote: Hello |
Hi peter
do not check NewList we will remove it for sure! I imagine I know And you see I did not know how to find a path. This is still on my todo to start renaming Model ->Presenter. But I'm working on a project proposal that I should finish :)
|
In reply to this post by Peter Uhnak
ok, thanks
Le 09/06/2016 20:29, Peter Uhnák a écrit : > Hi, > > 1) this is caused by this line in "listIntConfiguration" > > dragTransformationBlock: [ :item | item asInteger ]; > > you are dragging a symbol c, but "#c asInteger = nil" > > 2) > > dragging the number converts it into a StringMorph which obviously isn't in > the original collection. > > This is quite [expletive], because each list behaves differently: > > * ListModel the passenger is the object converted to a Morph, > * IconListModel (a subclass of ListModel) has as a passenger IconListItem > that holds reference to the original object > * FastTableModel (a subclass of ListModel) will just break down on drag > * MultiColumnListModel (a subclass of ListModel) won't even launch > * NewListModel breaks down on drag > * TreeModel has a different API, but also breaks down on drag > > Fun, ain't it? > > 3) > > probably similar to (2), didn't have the energy to investigate… > > > *NOW:* > > In general, the drag and drop behavior, the API, and the overall behavior > is broken to a various degree and inconsistent between ListModel, it's > children and related classes (TreeModel, NewListModel). > Last week I was working on a File Dialog replacement > https://github.com/peteruhnak/file-dialog and the brokenness and > inconsistencies were really frustrating. > > I don't see a point in trying to write a book about this particular section > because it's really bad right now. > > Of course not having a dedicated maintainer of Spec makes life a lot > harder, as people that work with/on Spec generally invest into Spec at > their own time discretion (me included), so while bugs can generally be > fixed, there's really no systematic effort in cleanup and API harmonization. > > With Stef we started to clean up and rethink it a bit when I was in Lille > because there's a lot of things we don't like or should fix, but that's a > long-term plan. We need a more immediate solution for the current mess. -_- > > *TL;DR:* > 1. imho no point in documenting this stuff _right now_ > 2. it's seriously broken > 3. we need to clean it up and harmonize first > > Peter > > On Thu, Jun 9, 2016 at 3:52 PM, Marion Noirbent < > [hidden email]> wrote: > >> Hello >> I would try to integrate the exemple Drag n Drop from >> http://spec.st/docs/drag_n_drop/ at the tutorial Building UI with Spec, >> so I have create a class in Pharo to try them and modify the code. >> >> I have found some of problems, I'm not sure if it come from strange >> configuration (i think about dragTransformationBlock: ), but it appear >> on the both version (my class and the original code). >> >> Marion, >> >> 1) >> Reproduce: >> Deplace the 'c' in the list of int, try to replace the 'c' in the list >> of char >> Error "nil not found in Orderred Collection" >> - Proceed don't remove the c from the list and make arrives a nil, like >> in the result deplaceReplaceC.png >> - Abandon seems work well, but the next refreshing of the list (by >> another move) make the nil appear too >> >> >> 2) >> Reproduce: >> Deplace the 3 in the list of char, try to replace the 3 in the list of >> int (at its place) >> Error " '3' not found in Orderred Collection" >> - Proceed duplicate the 3 gives the result DuplicateNumber.png >> - Abandon affect all number after the place, they "become" the previous >> number (BadNumber.png). Try to move the 4 make an error because it don't >> found 3, try to move the 5 make move the 4. >> >> >> 3) >> Reproduce: >> Deplace all items the list of int in the other >> Try to move the 'a' in the empty list of int >> Error "SubscriptOutOfBounds: 0" >> - Proceed remove the a from the list, but don't make it appear >> - Abandon seems work well >> > |
Free forum by Nabble | Edit this page |