Feature Request for Changes Chooser: Group classes per system category?

[LinqLover]

A common practice (as can be seen in the Trunk) is to store n system categories in a single package, which can lead to a less clear list of changes in the changes chooser/save version dialog. It might be helpful to insert another grouping so that class changes are not only grouped by packages but also by system categories within these packages.

[j4yk]

I made the classes sorted by the categories (according to the order of categories in the incoming version). I am reluctant to introduce another layer of tree nodes for the categories because then you have yet another thing to expand to drill down to the methods.

[LinqLover]

Thank you!

I made the classes sorted by the categories (according to the order of categories in the incoming version). I am reluctant to introduce another layer of tree nodes for the categories because then you have yet another thing to expand to drill down to the methods.

Hmm ... I see that point, but one could also argue that the current selection is pretty subtle and does not document the categories explicitly. I actually forgot about my categories a few times today and always was searching for a class at the wrong place in a list - a non-strictly alphabetic order could be considered non-intuitive. If we had horizontal separators, this might be different, though. :-) What do you think?

[j4yk]

I think that it is getting too complicated. The alphabetical list was good enough for me, and as you experienced yourself it was the more intuitive solution. ;-)

If you require more organization in the tool, maybe you are making too large commits or you need an entirely different tool. For example a package diff tool that is organized like the system browser with the four panes at the top and the display of the selected method (diff) at the bottom.

Horizontal separators would either be awkward (--- items, selectable, shudder) or would require a custom tree widget with specialized drawing. I do not think that it is worth the effort.

[LinqLover]

I do not think that it is worth the effort.

+1.
Alright, I'll let it up to you whether to revert b718256 or not. :-)

---

Nitpicking:

If you require more organization in the tool, maybe you are making too large commits or you need an entirely different tool.

Rather too large working copies, yes. :-) The Git Browser is already better at grouping than Monticello (but in Monticello, type-to-filter is easier - but that's another construction site).

--- items, selectable, shudder

👀😉

Yes, there are construction sites in the ToolBuilder, I guess. 😅

[LinqLover]

Maybe all the groupings should be customizable dynamically altogether. Right now I am merging a larger list of extension methods that have been moved into another package. In this case, flattening the view and viewing all classes with their methods regardless of their packages or system categories would be helpful too. :-)

[j4yk]

I have reverted to the old ordering behavior to simplify things.

The other -- items you were referring to are workarounds, too, to address the lack of discoverability in standard Smalltalk tools as built in Smalltalk 80 and Squeak... but at least for those mentioned items I made a programming effort that you cannot select them again after you have already had a "real" item selected. ;-) And they appear only at the top of course, not in the middle of the list or even multiple times in the list, so I imagine them to be less clunky than separator items in the middle.

If the presentation must even be customizable after all, it should really be viewed through a separate tool ;-) Note that there is #252 which is kind of related. Squot is complex enough as it is, it would be better if it could outsource the more specialized work. :-)