> 6. Threading code in rcube_imap class should be separated from
> non-threading code a little bit more. E.g. _list_headers() is a mess.
+1
>
> Please, consider my proposal from points 2, 3 and 6. Without this
> understandig of this part of patch (rcube_imap.php) is really hard.
>
Yep, it is always a headache for me too. Everything else is clean.
But I do not understand underlying logic deep enough to deal with all
that caching-not-caching-sorting-not-sorting... So it would be
definitely better if you agree with Chris on how it should be and do it
yourselves.
About the previous discussion:
From my point of view 'default' ('unsorted') mode from a threading
patch is almost the same as a 'index_sort' option, so it would probably
be sufficient to just silently enable that option for threaded view just
to prevent in-code resorting of what is already sorted by a server.
I just missed that while merging patch last time.
And about overall usability of both features:
More I think more I sure that there should be a per-folder sorting
option for both threading and index_sort. Later should be enabled
unconditionally when former is enabled. Either index_sort should be
added as a column where threading is added or they both should be moved
into a messagelist. It could be done as a narrow dropdown box before the
'subject' heading (at the horizontal level of expando boxes in a
threaded view) with three options, 'enable threading', 'enable
index_sort' and 'disable both'. Later should be a default. This solution
is a preferred one for me if it is easy enough to implement this. It
would add greater usability because it is often desirable to switch to
another mode without visiting a settings pane... As I wrote before, new
messages could appear on a third page of a threaded view (as it happened
with me today on a RC Dev list ;) ) and it would be very convenient to
switch to a plain mode in a just one click.
Vladislav
_______________________________________________
List info: http://lists.roundcube.net/dev/
