rqt_console bad sorting/numbering of messages of same time

[tkruse]

Using rqt_console in groovy; I see the following messages in this order

594 Node: /move_base_node Time: 1376315276.855 Severity: Debug Waypoint Follower created velocities x = 0.242897, th=-0.098650
564 Node: /move_base_node Time: 1376315276.854 Severity: Debug Waypoint Follower got new plan
565 Node: /move_base_node Time: 1376315276.854 Severity: Debug  Waypoint Follower waypoint: (3.373784, -2.061401, -0.058796)

As you can see, the numbering is neither strictly ascending nor descending (594, 564, 565).
Sorting by time in ascending order looks mostly okay, because it sorts both by time and by number in ascending order. Sorting by time in descending order then still sorts by number in ascending order for same times, which is horrible.

[ablasdel]

Can I get more info on what the issue is here? screen shots might help.

[tkruse]

The issue is message sorting. You can change the sotring between ascending
and descending in time. All messages have a time AND a number (leftmost
column), and switching the sort order should revert ethe list.

E.g. 1, 2, 3,4
should be
4, 3, 2, 1

However, what we currently get is
1, 2, 3, 4
and
3, 4, 2, 1

if 3 and 4 have the same time. I can make a screenshot tomorrow if you do
not see the problem.

On Mon, Aug 12, 2013 at 6:28 PM, Aaron Blasdel notifications@github.heygears.comwrote:

Can I get more info on what the issue is here? screen shots might help.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/124#issuecomment-22505902
.

[ablasdel]

Is it because the two nodes have the same time value? When sorting by the time the two numbers could end up either direction unless we take into account that number as a secondary sort criterion.

[tkruse]

Yes, I suggest you take into account that number as secondary sort
criterion, when the log entries have the same time value

On Mon, Aug 12, 2013 at 7:10 PM, Aaron Blasdel notifications@github.heygears.comwrote:

Is it because the two nodes have the same time value? When sorting by the
time the two numbers could end up either direction unless we take into
account that number as a secondary sort criterion.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/124#issuecomment-22508936
.

[ablasdel]

To do this we would need implement a custom "lessThan" function here: https://github.com/ros-visualization/rqt_common_plugins/blob/hydro-devel/rqt_console/src/rqt_console/message_proxy_model.py#L39

This would need extensive testing before merging to ensure we don't slow down the sorting/filtering too much and that we ensure all types of data still work. For these reasons I won't put this on the Hydro release milestone

Note: For anyone interested examples of how to implement QSortFilterProxy.lessThan in python can be found here: http://srinikom.github.io/pyside-docs/PySide/QtGui/QSortFilterProxyModel.html

[ablasdel]

Looked back at this and asked myself what those numbers actually gained us. They were intended as an improvement but since they are not strictly unique identifiers once we start removing things they are anything but useful. I have put in a pull request that removes the number bar entirely and solves this issue in the process.

[dirk-thomas]

Please see pull request #134 which uses the model row index as a tie breaker for ordering equal values.

[tkruse]

I don't see how changes in #134 change anythin to the ordering, maybe you meant a different pull request.

[ablasdel]

If you check #158 you can see that #139 is the pull that solved the issue.

commit hash viewable here:
bea76bd

[dirk-thomas]

Finally addressed in #186.