Browser menu interface to refactorings

> On 02-11-2017, at 10:38 AM, Bernhard Pieber <[hidden email]> wrote:
>
> Hi Eliot, Hi Marcel,
>
> IMO refactoring support is one of those features that belong to trunk. I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?

I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.

Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.

So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you don't pay the exorcist do you get repossessed?

2017-11-02 18:48 GMT+01:00 tim Rowledge <[hidden email]>:

> On 02-11-2017, at 10:38 AM, Bernhard Pieber <[hidden email]> wrote:
>
> Hi Eliot, Hi Marcel,
>
> IMO refactoring support is one of those features that belong to trunk. I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?

I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.

Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.

So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you don't pay the exorcist do you get repossessed?

IOW, what we need is a tool for understanding those legacy messy untidy codes which is a preamble to applying any refactoring...

Something like a brain, but better than the poor one we have.

Precisely because we started to complexify that code once we lost the overall picture of the problem/solution...

And we stopped modifying once it was humanely impossible to add a feature without breaking two others.

Such code is a sort of local optimum...

Hi Eliot,

as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:

Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.

Next step would be to build a preview tool that supports add/remove steps of a refactoring. For example, a "rename message" might tackle too much methods. That is, there is no scoping at the moment.

Best,

Marcel

[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak

[2] http://www.squeaksource.com/rb/

Am 01.11.2017 07:34:04 schrieb Tobias Pape <[hidden email]>:

Hi Eliot,


> On 01.11.2017, at 00:34, Eliot Miranda wrote:
>
> Hi All,
>
> I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
>

Have you seen the Refactoring tools? We have done exactly that two years ago

http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html

http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-mt.3.mcz


http://wiki.squeak.org/squeak/831

Best regards
-Tobias


> _,,,^..^,,,_
> best, Eliot
>

On Wed, Nov 1, 2017 at 3:15 AM, Marcel Taeumel <[hidden email]> wrote:

Next step would be to build a preview tool that supports add/remove steps of a refactoring. For example, a "rename message" might tackle too much methods. That is, there is no scoping at the moment.

OK.  We likely definitely want to scope by package(s), right?

 

Using Eliots screenshot as an example to hang some points on - 

That’s a way too long menu. I has hierarchical submenus *and* a ‘more…’ submenu. The refactoring stuff is probably less frequently used than many items below, which is usually a bad idea. The usage of the ellipsis for items like ‘senders of…’ at least indicates there is a further list to come but it confuses with ‘more…’ indicating a submenu.

At the very least I’d want to break this up into a better tree of menus, though it seems to me that some of those options really would be better off not in a menu at all but removed to some other UI element. We have the button list in the Browser that subsumes the sender/implementors stuff and there’s probably more that could be done there. I can’t see why ‘class refs’ is in a method menu at all! Nor indeed the three browse options which are all class list related.

Another interesting UI idea from the past might be useful to consider for the ‘senders of…

‘ type entries; RISC OS menus can include attached dialogues of various types. (In fact even entire application windows can be used but that’s going a bit far in my opinion) Now clearly we could simply add a submenu with the list of selectors used in the method for this particular case and it would be an improvement. Using dialogues (like the ListChoosers we currently open) directly from the menu offers the filtering and multiple input field or multiple lists and hierarchies and buttons capabilities. One might have a dialogue that lists all the selectors used, provides the filtering (yes, I know menus can do basic filtering) and several buttons to choose global or local searching for the implementing methods, limit to this package, check the history database for implementors no longer in the system, whatever. A crucial point would be to make sure the dialogues open and display *fast* even on slower machines.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HCFI: Halt and Catch Fire Immediate