The CheckableListListener is only informed about the fact that the order of the list has been changed but not how. It would be therefore nice to have additional information such as the from- and the to-Index,especially in relation with feature 79.
Although this would require a few small changes, multiple components might be affected by this changes, so they should be applied at another branch.
Replaced the method with itemMoved(int, int) ([4c881a]).
Related
Commit: [4c881a]
(1) How does itemMoved(int,int) behave if the list is repopulated or completeley re-ordered (e.g. by a sort in the model)? Was this case covered by onOrderChanged?
(2) Why do we need the order Information to be shipped with the change event? The receiver of such an event ususally has direct access to the list itself. Thus, it can just read the current state from the list directly. Does this have performance implications?
PS: In case you create a new feature/bug-branch that is side-arm of another feature/bug (i.e., FR 79 in this case) it might be less troublesome to branch it form the other feature branch in order to avoid merge conflicts. Furthermore, it better reflects the workflow/mergeflow.
(1) The listener is only triggered after a drag and drop event occured. Furthermore the only use of this method is in the PropertyConfgurationPanel so far for which [d29ff6] was applied, since this method should just not be called by every change of the list-order.
(2) At feature 79 the table should be updated everytime the ColumnFilter changes. Currently this has to be done by completely rebuilding the column order. This overhead could be avoided by more precise information about the drag event.
Ok, but i also need the changes from the master-branch. Merging the master into feature-79 and rebasing feature-106 on feature-79 seems to be the best way for me so. Since feature-106 is already pushed, it must be forced after reabasing. Hope this will not cause any trouble.
Related
Commit: [d29ff6]
Detected a small issue and fixed it. Also added two TODOs at importData() ([f2e269]). Can you please review them too?
The method is named itemDragged() now and the javadoc offers a more detailed explanation of the methods purpose ([30ee78]).
Related
Commit: [30ee78]
Commit: [f2e269]
Da Sourceforge mal wieder down ist ...
Im Anhang findest du eine überarbeitete Version des CheckableListTransferHandlers. Du hattest recht mit deinen Todos. Darüber hinaus gab es aber noch ne ganz Menge an weitere Problemen (z.B. konnte man zwischen verschiedenen checkableLists drag&drop machen) und race conditions erzeugen. Da war es schneller das eben selbst zu umzuschreiben, als das über Mail zu kommunizieren.
Ich werde das gleich auch noch mal versuchen zu pushen. Sag bitte kurz Bescheid, wenn du die angehängte Version verwenden solltest (da SF noch down ist, wenn du wieder daran arbeitest). Dann pushe ich diese nicht damit es zu keinen Merge-Konflikten kommt (d.h. du kannst die Änderungen in diesem Fall einfach commiten).
Viele Grüße
Till
On Mittwoch, 27. September 2017 11:12:51 CEST Philipp Mewes wrote:
--
Dipl.-Inf. Till Schäfer
TU Dortmund University
Chair 11 - Algorithm Engineering
Otto-Hahn-Str. 14 / Room 237
44227 Dortmund, Germany
e-mail: till.schaefer@cs.tu-dortmund.de
phone: +49(231)755-7706
fax: +49(231)755-7740
web: http://ls11-www.cs.uni-dortmund.de/staff/schaefer
pgp: https://keyserver2.pgp.com/vkd/SubmitSearch.event?&&SearchCriteria=0xD84DED79
Fixed a small bug with the listener ([0de327]).
Related
Commit: [0de327]
This feature is implemented and merged into feature #79.