The Trunk: Monticello-cmm.726.mcz
Locked
 
|
Chris Muller uploaded a new version of Monticello to project The Trunk:
http://source.squeak.org/trunk/Monticello-cmm.726.mcz ==================== Summary ==================== Name: Monticello-cmm.726 Author: cmm Time: 30 June 2020, 5:21:11.609668 pm UUID: 1a529d96-0be7-45a8-a65e-b9dcae087b85 Ancestors: Monticello-mt.725 Revert incorrect implementation of sorting repositories, because it broke "demote to bottom" which broke "browse revisions" and "browse origin". =============== Diff against Monticello-mt.725 =============== Item was changed: ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic ui') ----- repositories + ^ self repositoryGroup repositories! - | repositories | - repositories := self repositoryGroup repositories. - ^{repositories first}, (repositories allButFirst sort: [:r1 :r2| r1 description < r2 description])! |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
Hi Eliot, The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases. Would list-filtering help you find the repository you seek amongst your list of 40 repositories? - Chris On Tue, Jun 30, 2020 at 5:21 PM <[hidden email]> wrote: Chris Muller uploaded a new version of Monticello to project The Trunk: |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
On Tue, 30 Jun 2020, Chris Muller wrote:
> Hi Eliot, > The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases. Would list-filtering help you find the repository you seek amongst your list of 40 repositories? What model is it part of? And if it is, how come the GUI doesn't let you change that order? Levente > > - Chris > > On Tue, Jun 30, 2020 at 5:21 PM <[hidden email]> wrote: > Chris Muller uploaded a new version of Monticello to project The Trunk: > http://source.squeak.org/trunk/Monticello-cmm.726.mcz > > ==================== Summary ==================== > > Name: Monticello-cmm.726 > Author: cmm > Time: 30 June 2020, 5:21:11.609668 pm > UUID: 1a529d96-0be7-45a8-a65e-b9dcae087b85 > Ancestors: Monticello-mt.725 > > Revert incorrect implementation of sorting repositories, because it broke "demote to bottom" which broke "browse revisions" and "browse origin". > > =============== Diff against Monticello-mt.725 =============== > > Item was changed: > ----- Method: MCWorkingCopyBrowser>>repositories (in category 'morphic ui') ----- > repositories > + ^ self repositoryGroup repositories! > - | repositories | > - repositories := self repositoryGroup repositories. > - ^{repositories first}, (repositories allButFirst sort: [:r1 :r2| r1 description < r2 description])! > > > > |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <[hidden email]> wrote: On Tue, 30 Jun 2020, Chris Muller wrote: Monticello's. MCWorkingCopyBrowser's. And if it is, how come the GUI doesn't let you change that order? It's "demote to bottom" on the menu. But it seemed to have gotten broke due to the #repositories list always being sorted. My hope is that Eliot's use-case is for only when there are no WorkingCopy's selected, thus showing _all_ repositories -- because we can sort that output. But sorting as far as when an individual WorkingCopy is selected, it breaks one or two use cases. - Chris |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
On Tue, 30 Jun 2020, Chris Muller wrote:
> On Tue, Jun 30, 2020 at 7:59 PM Levente Uzonyi <[hidden email]> wrote: > On Tue, 30 Jun 2020, Chris Muller wrote: > > > Hi Eliot, > > The order of repositories is part of the model, sorting them conceptually breaks a couple of MC's use-cases. Would list-filtering help you find the repository you seek amongst your list of 40 repositories? > > What model is it part of? > > > Monticello's. MCWorkingCopyBrowser's. > > And if it is, how come the GUI doesn't let you change that order? > > > It's "demote to bottom" on the menu. But it seemed to have gotten broke due to the #repositories list always being sorted. should be the following options if that's the goal: alphabetize, move down, move up, move to front, move to end (this is the one called demote now which is not a good name IMO). Levente > > My hope is that Eliot's use-case is for only when there are no WorkingCopy's selected, thus showing _all_ repositories -- because we can sort that output. But sorting as far as when an individual WorkingCopy is selected, it > breaks one or two use cases. > > - Chris > > |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
Should we separate sorting the view from sorting the model, or the UI model object from the actual domain object/data? Eliot wants to view the list sorted and Chris insists not to break a deliberate order of repositories in the model because other functionality depends on it. Disconnect them. The bytes on my disk do not move when I sort a list of files by name. Levente Uzonyi <[hidden email]> schrieb am Mi., 1. Juli 2020, 13:40: On Tue, 30 Jun 2020, Chris Muller wrote: |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
In reply to this post by Levente Uzonyi
That nomenclature is tied to the use-case, which is about a prioritization of repositories (primary, mirror, local, etc.). I originally wanted to make it "promote" (instead of demote) but I thought it might be confusing with the package-cache always being first. The api nomenclature you suggest would shift the focus to the implementation innards being a "collection", without really being as revealing about why a user would want to "move up" a Repository in the list. It's really not a big deal to me if you want to change it, but I do think having this functionality is useful. It sounds like an alphabetize option would be useful for VMMaker.. - Chris On Wed, Jul 1, 2020 at 6:40 AM Levente Uzonyi <[hidden email]> wrote: On Tue, 30 Jun 2020, Chris Muller wrote: |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
In reply to this post by Chris Muller-3
Hi Chris, On Tue, Jun 30, 2020 at 4:28 PM Chris Muller <[hidden email]> wrote:
Perhaps, but having a rational sort order makes the most sense. I've just got annoyed, and calmed down, as I had to add trunk to one of my packages and couldn't find it easily in the list. I have to admit I found your reverting of my sorting passive aggressive. This is a real issue for me. I would have liked to see us fix the issues that introducing sorting added. I don't see how anyone can deal with a complex configuration with the apparently arbitrary and unsorted list we have now. So I'm reraising this as a real issue. Can you explain your commit comment for Monticello-cmm.726, "Revert incorrect implementation of sorting repositories, because it broke "demote to bottom" which broke "browse revisions" and "browse origin"."? How and why does it break these things? ow and why do they rely on the unsorted order?
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
In reply to this post by Chris Muller-4
On Tue, Jun 30, 2020 at 8:55 PM Chris Muller <[hidden email]> wrote:
It's the "show all repositories" use case I care about. I certainly *don't* (and didn't) intend to change the sort order of an individual package's repositories. I understand how I f**ked up now. I apologize. Maybe I can do better next time?
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
Hi Eliot, I care that something in the IDE isn't working optimally for you. I do certainly prefer when we engage in a deliberative work style, so when I went to use those legacy IDE functions and found this change to be the reason I couldn't, I took care not to fix it more aggressively than it was committed, and remain sensitive to your use-case to help get it in properly. So that's good to know you were referring to the "all" list, that should make it just a presentation issue then.. - Chris On Mon, Jul 27, 2020 at 2:31 PM Eliot Miranda <[hidden email]> wrote:
|
Re: The Trunk: Monticello-cmm.726.mcz
|
Hi Eliot, hi Chris, what about adding the preference #sortMonticelloRepositoriesAlphabetically like we have #sortMessageCategoriesAlphabetically ? Best, Marcel
|
Re: The Trunk: Monticello-cmm.726.mcz
|
|
> On 2020-07-28, at 12:01 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HEM: Hide Evidence of Malfunction |
Re: The Trunk: Monticello-cmm.726.mcz
|
|
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 <[hidden email]>: > > > > > On 2020-07-28, at 12:01 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: HEM: Hide Evidence of Malfunction > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |