Quote:
Originally Posted by kiwidude
@Charles - I don't suppose there is a convenient way to identify what the current sort column is? I discovered that sorting every time you move to the next duplicate group is quite slow. So what would be better I think (since the topmost sort column is that of "marked") is to check whether that is still the current top sort column, and only apply my sorts again of title then marked if it is not. The user can't sort on "marked" since it is not visible, so this should work as an optimisation.
I know from my ViewManager plugin that I can get down and dirty and roll around in get_state() with sort history etc, but I thought I would ask you first before I did that again to see if you had a better suggestion  |
No, there isn't. I could add a method to search for the column displaying the sort indicator, but I am not sure that is what you want. And in any event, it won't work for 'marked' because it isn't a column that can be made visible.
There be some dragons in using sort history or the proposed method. What that tells you is that the last time the view was sorted, it used columns X. It does not tell you that the view is currently in that order. For example, added books will go on top, which is probably not where they should be. I am not sure you should assume that the last sort is still good.
What I will look at is whether we can sort the filtered set (after search) instead of the entire cache. First blush look in the GUI says it will work there, because sorts are reapplied after a search. I don't know how the content server would treat this. Perhaps an option to db.sort would be best, so that the code that is prepared for this behavior can ask for it.