[vlc-devel] [PATCH 1/2] core: added sort by date (prepare for playlist fix)

[Marcel Schnirring]

I proposed this solution because it would not make the user interface more
complicated and can further use most of the existing code base (only call
to "qsort()" within "playlist_ItemArraySort()" also in "sort.c") must be
replaced by a stable sorting algorithm. C++ STL provides
"std::stable_sort()" and "std::inplace_merge()" in "<algorithm>" with only
small performance penalties compared to "std::sort()" which should be
similar to C "qsort()". The performance on today's machines should be more
than sufficient for normal playlist sizes even with a stable sorting
algorithm.

But I see your point, that only few people will think about it and use it
accordingly. Further, single click sorts (one column) will be worse since
chaining (e.g. artist, date, album, number) will not be performed
automatically any more.


*Mit freundlichen Grüßen / Kind regards,*
Marcel Schnirring

*Heilbronner Strasse 36*
*76131 Karlsruhe*
*Deutschland / Germany*
*Email: ms at marcel-schnirring.de <ms at marcel-schnirring.de>*
*Mobile: (+49) 178 198 37 61*

On Thu, Dec 8, 2016 at 5:41 PM, Wilawar <chrcnt7 at swift-mail.com> wrote:

> This is a reworked version of my previous message.
>
>
> > When I was writing this code, I was wondering if a rework of the
> underlying
> > sorting algorithm would make sense.
> >
> > Using a stable sorting algorithm would allow the user to choose how he
> want
> > to sort equal entries in one property. This way, all the extra handling
> of
> > equal elements can be removed.
> >
> > For example when you would like to sort based on Artist, Date, Album,
> > Title, you would click the column headers in reverse order (Title, Album,
> > Date, Artist).
>
> Well, if you think users wouldn’t ask why the heck they would have to
> click column headers in reverse to the
> relevance they have to them, just to make them appear in the way they
> would like them to be, and if
> you further disregarded the problem that new items couldn’t be put into
> place automatically if the implementation
> didn’t track all sort commands that don’t cancel each other (which might
> be almost all previous sort operations),
> then sure, your proposal would make for a nice insider trick (but not much
> more). ;)
> By the way, I already noticed that this proposal would require clicking in
> reverse to the order of thinking before
> I read about it in your message, so to me this seems like a very obvious
> problem.
>
> In general, it’s certainly desirable to have items sorted by multiple
> rules acting in priority order; yet it’s seldomly seen in other programs,
> so it would be guaranteed to give a good impression to everyone who notices.
> However, I know I won’t work on this in the forseeable future, so you
> might have to implement this yourself or
> convince someone else to do it. I would also like to call to your
> attention that – while applying multiple stable
> sorting algorithms in reverse order is (mathematically seen) a very
> elegant solution – in programming,
> performance matters and other approaches might be more suitable, such as
> remembering the ranges which only
> have items that have got an equal rank during the last sorting operation.
>
>
> Now, these were just my two cents while reading at least a few messages
> from the stale backlog. ;)
>
> --
> http://www.fastmail.com - Access your email from home and the web
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161208/d9e2d997/attachment.html>