Browser menu interface to refactorings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Browser menu interface to refactorings

Eliot Miranda-2
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.

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


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Chris Muller-3
I used it in my 3.9 images, which I still have around.  Are you
looking for just menu structure or actual menu-creation code?  We've
made so many changes, code might not port more easily than re-writing.

On Tue, Oct 31, 2017 at 6:34 PM, Eliot Miranda <[hidden email]> 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.
>
> _,,,^..^,,,_
> best, Eliot
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Tobias Pape
In reply to this post by Eliot Miranda-2
Hi Eliot,


> On 01.11.2017, at 00:34, Eliot Miranda <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

marcel.taeumel
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

[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
>




Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

marcel.taeumel
...there is also a Metacello script in "http://www.squeaksource.com/MetacelloRepository" behind "ConfigurationOfRefactoringTools".

Best,
Marcel


Am 01.11.2017 11:15:29 schrieb Marcel Taeumel <[hidden email]>:

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

[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
>




Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

David T. Lewis
In reply to this post by marcel.taeumel
If the refactoring tools are known to work in current Squeak, and if there
is active support for the package, then we should have an entry for this on
SqueakMap.

Looking at the SqueakMap Package Loader in my trunk image, I see entries
for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also
an entry for Refactoring Engine for Squeak 3.9. These were maintained by
Marcus Denker, who is no longer active in Squeak development.

Could someone please volunteer to make an entry for the current tools that
are being maintained for Squeak today?

Thanks!

Dave


On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:

> 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
> >
>
>



>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Tobias Pape

> On 01.11.2017, at 12:26, David T. Lewis <[hidden email]> wrote:
>
> If the refactoring tools are known to work in current Squeak, and if there
> is active support for the package, then we should have an entry for this on
> SqueakMap.
>
> Looking at the SqueakMap Package Loader in my trunk image, I see entries
> for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also
> an entry for Refactoring Engine for Squeak 3.9. These were maintained by
> Marcus Denker, who is no longer active in Squeak development.
>
> Could someone please volunteer to make an entry for the current tools that
> are being maintained for Squeak today?

We (at hpi) currently only maintain the Metacello Config...

>
> Thanks!
>
> Dave
>
>
> On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:
>> 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
>>>
>>
>>
>
>
>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Hannes Hirzel
A squeakmap entry may contain just an installation script such as the ones at

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

It is a matter of contacting Marcus Denker and ask him for the rights
to add a new version entry to the existing 'Refactoring Engine' entry
on SqueakMap.

On 11/1/17, Tobias Pape <[hidden email]> wrote:

>
>> On 01.11.2017, at 12:26, David T. Lewis <[hidden email]> wrote:
>>
>> If the refactoring tools are known to work in current Squeak, and if there
>> is active support for the package, then we should have an entry for this
>> on
>> SqueakMap.
>>
>> Looking at the SqueakMap Package Loader in my trunk image, I see entries
>> for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also
>> an entry for Refactoring Engine for Squeak 3.9. These were maintained by
>> Marcus Denker, who is no longer active in Squeak development.
>>
>> Could someone please volunteer to make an entry for the current tools that
>> are being maintained for Squeak today?
>
> We (at hpi) currently only maintain the Metacello Config...
>
>>
>> Thanks!
>>
>> Dave
>>
>>
>> On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:
>>> 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
>>>>
>>>
>>>
>>
>>
>>
>>>
>>
>>
>
>
>

bpi
Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

bpi
In reply to this post by marcel.taeumel
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?

Bernhard

> Am 01.11.2017 um 11:15 schrieb Marcel Taeumel <[hidden email]>:
>
> 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:
>
> <image.png>
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

timrowledge

> 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?






Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Nicolas Cellier


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...



Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Nicolas Cellier


2017-11-02 18:56 GMT+01:00 Nicolas Cellier <[hidden email]>:


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...

I wanted to finish with a return to main subject:
I still think that refactoring tools are helpful well before we reach such critical state.


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Herbert König
In reply to this post by Nicolas Cellier

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...

:-)) I thoroughly dislike those just trying to make a genetic optimizer less prone to be stuck in them.
But then the real world mainly consists of those.
SCNR,
Herbert


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Eliot Miranda-2
In reply to this post by marcel.taeumel
Hi Tobias & Marcel,

On Wed, Nov 1, 2017 at 3:15 AM, Marcel Taeumel <[hidden email]> wrote:
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.

That's great news.  I'll use your code.  I think the tools should be in the base image but perhaps we can put the browser integration in the base and have it not show menus until the refactoring code is loaded.
 

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?
 

Best,
Marcel


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
>








--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Chris Muller-3
In reply to this post by marcel.taeumel
Oh my goodness this is awesome!

On Wed, Nov 1, 2017 at 5:15 AM, Marcel Taeumel <[hidden email]> wrote:
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


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
>








Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Jakob Reschke-2
In reply to this post by Eliot Miranda-2
Am 02.11.2017 7:11 nachm. schrieb "Eliot Miranda" <[hidden email]>:

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?
 

Unless you wanted to say "packages, not classes or categories" I do not think so. Mostly because projects/software is often divided into -Core and -Tests packages. Or think of -Examples, -Plugins, -Extensions... So I fear explicit input of the scope (a set of packages) will be required.

Using package dependencies (like in ENVY) would be nice, but they are unmaintained in Monticello (often only supplied with Metacello).

Oh, and my Environments bell is ringing again... ;-)


Reply | Threaded
Open this post in threaded view
|

A point about menu complistification (was Re: Browser menu interface to refactorings)

timrowledge
In reply to this post by Eliot Miranda-2
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




Reply | Threaded
Open this post in threaded view
|

Re: A point about menu complistification (was Re: Browser menu interface to refactorings)

Chris Muller-3
I could easily do without 6 items on that menu, but I need the rest.  It's possible others might like those features, though.

It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".

On Thu, Nov 2, 2017 at 2:34 PM, tim Rowledge <[hidden email]> wrote:
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








Reply | Threaded
Open this post in threaded view
|

Re: A point about menu complistification (was Re: Browser menu interface to refactorings)

marcel.taeumel
Hi Tim.

Just type a word. It will filter the menu and help you focus. ...maybe we should expand this search to submenus? :) Just thinking about our current state of tree-node filtering in the object explorer...

Best,
Marcel

Am 02.11.2017 20:49:48 schrieb Chris Muller <[hidden email]>:

I could easily do without 6 items on that menu, but I need the rest.  It's possible others might like those features, though.

It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".

On Thu, Nov 2, 2017 at 2:34 PM, tim Rowledge <[hidden email]> wrote:
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








Reply | Threaded
Open this post in threaded view
|

Re: A point about menu complistification (was Re: Browser menu interface to refactorings)

timrowledge

> On 02-11-2017, at 1:07 PM, Marcel Taeumel <[hidden email]> wrote:
> Just type a word. It will filter the menu and help you focus

Yeah, but no, that doesn’t solve the over-complication problem. It helps *if* you already know what you want. It’s no use for discovery, nor much for muscle memory usage. I’m not saying it shouldn’t be available or indeed improved, but it is only a very small aspect of the whole issue.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
My computer NEVER cras



12