So far it was the models being responsible for such things as list
ordering. As I said, maybe the GUI model (for browsing the
repositories, here MCWorkingCopyBrowser) should be separate from the
domain object (that holds the order necessary for features like browse
revisions, I don't know which one it is, but I don't think that the
working copy browser should be used there).

If we enable the views (morphs, widgets) to do the sorting, it will be
cool to have sorting everywhere immediately. But then there might be
another thing you have to care about when you design your user
interface ("I must have this order, so I will always return it like
this... but nah it means I will have to tell the morph to disable the
sorting"). And we will have two ways to achieve the same thing (sorted
lists/trees). Is that the right way? If you think so, please proceed.


Am Di., 28. Juli 2020 um 18:24 Uhr schrieb tim Rowledge <tim at rowledge.org>:
>
>
>
> > On 2020-07-28, at 12:01 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> >
> > Hi Eliot, hi Chris,
> >
> > what about adding the preference #sortMonticelloRepositoriesAlphabetically like we have #sortMessageCategoriesAlphabetically ?
>
> How about adding sorting to the list *view* morphs instead? Being able to have sorting for name/date/size/colour/whatever in generic list morphs would be pretty helpful.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: HEM: Hide Evidence of Malfunction
>
>
>