Browser menu interface to refactorings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
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,

yes, discoverability and good defaults are key. We should re-design the menus. Yet, it is a challenging endeavour. I read things about adaptive menus, tried them out in former MS Office versions ... such "cleverness" stands in the user's way if not done right. :-/ Maybe even does more harm than good.

The menus we have in Squeak do not work for daily usage - I suppose. You can browse them, discover new features, maybe recall a long forgotten one if you got stuck. Nevertheless, most of them got keyboard shortcuts and you should learn them. ...relying on those menus in the long term is tedious. :-(

Other environments have multiple kinds of menus: classic tool bars, pop-up menus, ribbon bars, floating versions of all these... labels in combination with icons, you can make more features available without annoying the user too much. Again, if all menu entries get an icon, the effect of icons is gone again. ...unless being REALLY GOOD icons ... which they usually aren't. :)

So, I hear you. I understand the issue with the status quo. I really would like to improve it someday.

Speaking of good defaults and means of configuration:


Best,
Marcel

Am 02.11.2017 21:12:16 schrieb tim Rowledge <[hidden email]>:


> On 02-11-2017, at 1:07 PM, Marcel Taeumel 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





Reply | Threaded
Open this post in threaded view
|

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

Bob Arning-2
In reply to this post by Chris Muller-3

that's not too hard



On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".



Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Eliot Miranda-2
In reply to this post by Jakob Reschke
Hi Jacob,

On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]> wrote:
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.

I think offering two scopes is adequate:
a) the entire system
b) classes and extension methods whose package name matches either a prefix or a pattern

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

Remember that one can always generate more narrowly scoped refactoring by
1. performing the refactoring on some larger scope (e.g. the entire system)
2. quitting the system
3. using the changes crash recovery tool to select the desired refactorings
or by using method versions to revert any unwanted

So having a simple generally useful scope such as package or package prefix would work for me.

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


Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
In reply to this post by Bob Arning-2
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/

Best,
Marcel


Am 02.11.2017 23:00:03 schrieb Bob Arning <[hidden email]>:

that's not too hard



On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".



Reply | Threaded
Open this post in threaded view
|

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

Bob Arning-2

well, that's not too hard, either ;-)


On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/

Best,
Marcel


Am 02.11.2017 23:00:03 schrieb Bob Arning [hidden email]:

that's not too hard



On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".




    




menuHiding.03Nov0548.cs (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
Well, it is not too hard to come up with something, right. ;) Especially coding it is much easier than designing it (wrt. configuration and extensibility). You suggestion is, in my opinion, not better than keyboard-filtering of (hierarchical/grouped) menus. Hmm... user-friendly configuration would be more like expressing what you do frequently instead of filling a blacklist with things to not use.

It might be constructive to look for a good implementation of adaptive menus, whose design we could employ in Squeak. MS Office got rid of their approach, which I think is good. :)

Best,
Marcel

Am 03.11.2017 10:50:16 schrieb Bob Arning <[hidden email]>:

well, that's not too hard, either ;-)


On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/

Best,
Marcel


Am 02.11.2017 23:00:03 schrieb Bob Arning [hidden email]:

that's not too hard



On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".




    



Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
These papers might be interesting reads in this regard: 

"A comparison of static, adaptive, and adaptable menus", 2004, Findlater et al.
"Adaptable versus adaptive menus on the desktop: Performance and user satisfaction", 2007, Park et al.
"Ephemeral adaptation: The use of gradual onset to improve menu selection performance", 2009, Findlater et al.

Google (Scholar) can find PDFs of these.

Best,
Marcel

Am 03.11.2017 10:58:08 schrieb Marcel Taeumel <[hidden email]>:

Well, it is not too hard to come up with something, right. ;) Especially coding it is much easier than designing it (wrt. configuration and extensibility). You suggestion is, in my opinion, not better than keyboard-filtering of (hierarchical/grouped) menus. Hmm... user-friendly configuration would be more like expressing what you do frequently instead of filling a blacklist with things to not use.

It might be constructive to look for a good implementation of adaptive menus, whose design we could employ in Squeak. MS Office got rid of their approach, which I think is good. :)

Best,
Marcel

Am 03.11.2017 10:50:16 schrieb Bob Arning <[hidden email]>:

well, that's not too hard, either ;-)


On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/

Best,
Marcel


Am 02.11.2017 23:00:03 schrieb Bob Arning [hidden email]:

that's not too hard



On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".




    



Reply | Threaded
Open this post in threaded view
|

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

Kjell Godo

On Fri, Nov 3, 2017 at 03:04 Marcel Taeumel <[hidden email]> wrote:
These papers might be interesting reads in this regard: 

"A comparison of static, adaptive, and adaptable menus", 2004, Findlater et al.
"Adaptable versus adaptive menus on the desktop: Performance and user satisfaction", 2007, Park et al.
"Ephemeral adaptation: The use of gradual onset to improve menu selection performance", 2009, Findlater et al.

Google (Scholar) can find PDFs of these.

i saw this adaptive menu on a Japanese device once a long time ago
     where the most recently used menu item rises to the top
     and i liked it and i still like it
so i made one in Smalltalk and i still use it
the short cut keys are 
     <WindowsPopUpMenuKey> , <M> , <FirstLetterOfTheComand>
the menu is divided up into sections
     and the most recently used section rises to the top
     such that from then on just the three key presses 
     will execute the menu item
the menu is just a list Chooser Dialog      <—-[ Dolphin ]
there is a menu command that opens a text View on all
     the menu commands which can be searched
          there are a lot of them
many menu commands have documentation 
     which pops up first which unconscious hitting
     <Spacebar> bypasses
          it shows that something is happening
     one could turn this prefix doc off but i never want to
     ( the Pharo Message dialogs are too dark i think i want white )
there are many old dead menu commands in the list
     left over from long ago which i just leave deprecated 
     but have not removed since no one else will see them
     ( spies excepted i guess )
it’s easy to add new commands which act on the 
     text selection in the TextView which gives a command line
     effect

if one was to implement these menu commands as
     KEGArrows<—-[ see Haskell arrows ]
     then the user might be able to compose them into
     scripts or programs like named MSOffice macros i guess
     with some ..Arrows able to look at their surroundings
     to keep it correct if they get refactored
     ..Arrows try to minimize the need for program variables
          so code looks more like a list of ..Arrows
i would like to publish this ..Arrows Package soon
     but how do i do it do i have to be a member of
     something to get it more widely viewed and if so what is it?
     ( i have seen where members were encouraged to ignore
          non members of something but i can’t remember what
       i noticed some kind of member list for Pharo Squeak
          which i would like to join if possible      but how )
i am trying to move to mostly ..Arrows based programming
          not quite sure what the best ways are
     because it looks is convenient for TDDev etc and it makes it
     easier to handle more complexity i think and have more
     tests much more integration tests which might even
     act like Iffel runtime correctness checks when turned on
     the test instrumentation in the target Method is brief just a
          few Charaters
..Arrows could also be a functional way to handle state via
     the state monad idea of pure and impure functions
     which helps the Compiler     could help it they say



Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Hannes Hirzel
In reply to this post by Eliot Miranda-2
Hello

Following up on this thread.

Where do I get the latest version of the RefactoringTools updated for
the most recent trunk version?

There are some SqueakMap entries but they are outdated.

This

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

seems to give recent information as well.

--Hannes

On 11/3/17, Eliot Miranda <[hidden email]> wrote:

> Hi Jacob,
>
> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]>
> wrote:
>
>> 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.
>>
>
> I think offering two scopes is adequate:
> a) the entire system
> b) classes and extension methods whose package name matches either a prefix
> or a pattern
>
>
>
>> 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... ;-)
>>
>
> Remember that one can always generate more narrowly scoped refactoring by
> 1. performing the refactoring on some larger scope (e.g. the entire system)
> 2. quitting the system
> 3. using the changes crash recovery tool to select the desired refactorings
> or by using method versions to revert any unwanted
>
> So having a simple generally useful scope such as package or package prefix
> would work for me.
>
> _,,,^..^,,,_
> best, Eliot
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Tobias Pape
Hi

> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>
> Hello
>
> Following up on this thread.
>
> Where do I get the latest version of the RefactoringTools updated for
> the most recent trunk version?
>
> There are some SqueakMap entries but they are outdated.
>
> This
>
>     http://wiki.squeak.org/squeak/831
>
> seems to give recent information as well.

This is the most recent info.

I short, if you have Metacello,

        Metacello new
                configuration: 'RefactoringTools';
                load.


That's about it.
Marcel and Me will keep the Config up to date.
We have not made any SqueakMap entries.

Best regards
        -Tobias



>
> --Hannes
>
> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>> Hi Jacob,
>>
>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]>
>> wrote:
>>
>>> 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.
>>>
>>
>> I think offering two scopes is adequate:
>> a) the entire system
>> b) classes and extension methods whose package name matches either a prefix
>> or a pattern
>>
>>
>>
>>> 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... ;-)
>>>
>>
>> Remember that one can always generate more narrowly scoped refactoring by
>> 1. performing the refactoring on some larger scope (e.g. the entire system)
>> 2. quitting the system
>> 3. using the changes crash recovery tool to select the desired refactorings
>> or by using method versions to revert any unwanted
>>
>> So having a simple generally useful scope such as package or package prefix
>> would work for me.
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Chris Muller-3
... and... how to get Metacello please?


On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:

> Hi
>
>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>
>> Hello
>>
>> Following up on this thread.
>>
>> Where do I get the latest version of the RefactoringTools updated for
>> the most recent trunk version?
>>
>> There are some SqueakMap entries but they are outdated.
>>
>> This
>>
>>     http://wiki.squeak.org/squeak/831
>>
>> seems to give recent information as well.
>
> This is the most recent info.
>
> I short, if you have Metacello,
>
>         Metacello new
>                 configuration: 'RefactoringTools';
>                 load.
>
>
> That's about it.
> Marcel and Me will keep the Config up to date.
> We have not made any SqueakMap entries.
>
> Best regards
>         -Tobias
>
>
>
>>
>> --Hannes
>>
>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>> Hi Jacob,
>>>
>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> I think offering two scopes is adequate:
>>> a) the entire system
>>> b) classes and extension methods whose package name matches either a prefix
>>> or a pattern
>>>
>>>
>>>
>>>> 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... ;-)
>>>>
>>>
>>> Remember that one can always generate more narrowly scoped refactoring by
>>> 1. performing the refactoring on some larger scope (e.g. the entire system)
>>> 2. quitting the system
>>> 3. using the changes crash recovery tool to select the desired refactorings
>>> or by using method versions to revert any unwanted
>>>
>>> So having a simple generally useful scope such as package or package prefix
>>> would work for me.
>>>
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Hannes Hirzel
The wiki page cited above

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

  has a link to

Metacello http://wiki.squeak.org/squeak/6157

which has a paragraph. called 'Installation'.


On 5/10/18, Chris Muller <[hidden email]> wrote:

> ... and... how to get Metacello please?
>
>
> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>> Hi
>>
>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>
>>> Hello
>>>
>>> Following up on this thread.
>>>
>>> Where do I get the latest version of the RefactoringTools updated for
>>> the most recent trunk version?
>>>
>>> There are some SqueakMap entries but they are outdated.
>>>
>>> This
>>>
>>>     http://wiki.squeak.org/squeak/831
>>>
>>> seems to give recent information as well.
>>
>> This is the most recent info.
>>
>> I short, if you have Metacello,
>>
>>         Metacello new
>>                 configuration: 'RefactoringTools';
>>                 load.
>>
>>
>> That's about it.
>> Marcel and Me will keep the Config up to date.
>> We have not made any SqueakMap entries.
>>
>> Best regards
>>         -Tobias
>>
>>
>>
>>>
>>> --Hannes
>>>
>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>> Hi Jacob,
>>>>
>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I think offering two scopes is adequate:
>>>> a) the entire system
>>>> b) classes and extension methods whose package name matches either a
>>>> prefix
>>>> or a pattern
>>>>
>>>>
>>>>
>>>>> 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... ;-)
>>>>>
>>>>
>>>> Remember that one can always generate more narrowly scoped refactoring
>>>> by
>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>> system)
>>>> 2. quitting the system
>>>> 3. using the changes crash recovery tool to select the desired
>>>> refactorings
>>>> or by using method versions to revert any unwanted
>>>>
>>>> So having a simple generally useful scope such as package or package
>>>> prefix
>>>> would work for me.
>>>>
>>>> _,,,^..^,,,_
>>>> best, Eliot
>>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Tobias Pape
In reply to this post by Chris Muller-3

> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>
> ... and... how to get Metacello please?
>

Installer ensureRecentMetacello

>
> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>> Hi
>>
>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>
>>> Hello
>>>
>>> Following up on this thread.
>>>
>>> Where do I get the latest version of the RefactoringTools updated for
>>> the most recent trunk version?
>>>
>>> There are some SqueakMap entries but they are outdated.
>>>
>>> This
>>>
>>>    http://wiki.squeak.org/squeak/831
>>>
>>> seems to give recent information as well.
>>
>> This is the most recent info.
>>
>> I short, if you have Metacello,
>>
>>        Metacello new
>>                configuration: 'RefactoringTools';
>>                load.
>>
>>
>> That's about it.
>> Marcel and Me will keep the Config up to date.
>> We have not made any SqueakMap entries.
>>
>> Best regards
>>        -Tobias
>>
>>
>>
>>>
>>> --Hannes
>>>
>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>> Hi Jacob,
>>>>
>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I think offering two scopes is adequate:
>>>> a) the entire system
>>>> b) classes and extension methods whose package name matches either a prefix
>>>> or a pattern
>>>>
>>>>
>>>>
>>>>> 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... ;-)
>>>>>
>>>>
>>>> Remember that one can always generate more narrowly scoped refactoring by
>>>> 1. performing the refactoring on some larger scope (e.g. the entire system)
>>>> 2. quitting the system
>>>> 3. using the changes crash recovery tool to select the desired refactorings
>>>> or by using method versions to revert any unwanted
>>>>
>>>> So having a simple generally useful scope such as package or package prefix
>>>> would work for me.
>>>>
>>>> _,,,^..^,,,_
>>>> best, Eliot
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Hannes Hirzel
Proposal

Take the result of this discussion

    Installer ensureRecentMetacello.
    Metacello new
                configuration: 'RefactoringTools';
                load.


and put it into the Squeak help file subject 'Extending the system'
thus replacing the Omnibrowser script.

--Hannes



On 5/11/18, Tobias Pape <[hidden email]> wrote:

>
>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>
>> ... and... how to get Metacello please?
>>
>
> Installer ensureRecentMetacello
>
>>
>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>> Hi
>>>
>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>
>>>> Hello
>>>>
>>>> Following up on this thread.
>>>>
>>>> Where do I get the latest version of the RefactoringTools updated for
>>>> the most recent trunk version?
>>>>
>>>> There are some SqueakMap entries but they are outdated.
>>>>
>>>> This
>>>>
>>>>    http://wiki.squeak.org/squeak/831
>>>>
>>>> seems to give recent information as well.
>>>
>>> This is the most recent info.
>>>
>>> I short, if you have Metacello,
>>>
>>>        Metacello new
>>>                configuration: 'RefactoringTools';
>>>                load.
>>>
>>>
>>> That's about it.
>>> Marcel and Me will keep the Config up to date.
>>> We have not made any SqueakMap entries.
>>>
>>> Best regards
>>>        -Tobias
>>>
>>>
>>>
>>>>
>>>> --Hannes
>>>>
>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>> Hi Jacob,
>>>>>
>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> I think offering two scopes is adequate:
>>>>> a) the entire system
>>>>> b) classes and extension methods whose package name matches either a
>>>>> prefix
>>>>> or a pattern
>>>>>
>>>>>
>>>>>
>>>>>> 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... ;-)
>>>>>>
>>>>>
>>>>> Remember that one can always generate more narrowly scoped refactoring
>>>>> by
>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>> system)
>>>>> 2. quitting the system
>>>>> 3. using the changes crash recovery tool to select the desired
>>>>> refactorings
>>>>> or by using method versions to revert any unwanted
>>>>>
>>>>> So having a simple generally useful scope such as package or package
>>>>> prefix
>>>>> would work for me.
>>>>>
>>>>> _,,,^..^,,,_
>>>>> best, Eliot
>>>>>
>>>>
>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Levente Uzonyi
+1, but the configuration has to be updated first to load the correct
versions.

Levente

On Mon, 2 Jul 2018, H. Hirzel wrote:

> Proposal
>
> Take the result of this discussion
>
>    Installer ensureRecentMetacello.
>    Metacello new
>                configuration: 'RefactoringTools';
>                load.
>
>
> and put it into the Squeak help file subject 'Extending the system'
> thus replacing the Omnibrowser script.
>
> --Hannes
>
>
>
> On 5/11/18, Tobias Pape <[hidden email]> wrote:
>>
>>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>>
>>> ... and... how to get Metacello please?
>>>
>>
>> Installer ensureRecentMetacello
>>
>>>
>>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>>> Hi
>>>>
>>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> Following up on this thread.
>>>>>
>>>>> Where do I get the latest version of the RefactoringTools updated for
>>>>> the most recent trunk version?
>>>>>
>>>>> There are some SqueakMap entries but they are outdated.
>>>>>
>>>>> This
>>>>>
>>>>>    http://wiki.squeak.org/squeak/831
>>>>>
>>>>> seems to give recent information as well.
>>>>
>>>> This is the most recent info.
>>>>
>>>> I short, if you have Metacello,
>>>>
>>>>        Metacello new
>>>>                configuration: 'RefactoringTools';
>>>>                load.
>>>>
>>>>
>>>> That's about it.
>>>> Marcel and Me will keep the Config up to date.
>>>> We have not made any SqueakMap entries.
>>>>
>>>> Best regards
>>>>        -Tobias
>>>>
>>>>
>>>>
>>>>>
>>>>> --Hannes
>>>>>
>>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>>> Hi Jacob,
>>>>>>
>>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>>> <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> I think offering two scopes is adequate:
>>>>>> a) the entire system
>>>>>> b) classes and extension methods whose package name matches either a
>>>>>> prefix
>>>>>> or a pattern
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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... ;-)
>>>>>>>
>>>>>>
>>>>>> Remember that one can always generate more narrowly scoped refactoring
>>>>>> by
>>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>>> system)
>>>>>> 2. quitting the system
>>>>>> 3. using the changes crash recovery tool to select the desired
>>>>>> refactorings
>>>>>> or by using method versions to revert any unwanted
>>>>>>
>>>>>> So having a simple generally useful scope such as package or package
>>>>>> prefix
>>>>>> would work for me.
>>>>>>
>>>>>> _,,,^..^,,,_
>>>>>> best, Eliot
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Edgar De Cleene
Alternative Browser is a good thing.
Do not matter OmnniBrowser is not developed any more.
If people could have the last version working , maybe some find inspiration
and continue.
Another old Broser's

StarBrower
Tamaris


Edgar
@morplenauta



On 02/07/2018, 10:26, "Levente Uzonyi" <[hidden email]> wrote:

>> Proposal
>
> Take the result of this discussion
>
>    Installer
>> ensureRecentMetacello.
>    Metacello new
>                configuration:
>> 'RefactoringTools';
>                load.
>
>
> and put it into the Squeak
>> help file subject 'Extending the system'
> thus replacing the Omnibrowser
>> script.
>
> --Hannes



Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Tobias Pape
In reply to this post by Levente Uzonyi

> On 02.07.2018, at 15:26, Levente Uzonyi <[hidden email]> wrote:
>
> +1, but the configuration has to be updated first to load the correct versions.

ok.. can you elaborate?


>
> Levente
>
> On Mon, 2 Jul 2018, H. Hirzel wrote:
>
>> Proposal
>>
>> Take the result of this discussion
>>
>>  Installer ensureRecentMetacello.
>>  Metacello new
>>              configuration: 'RefactoringTools';
>>              load.
>>
>>
>> and put it into the Squeak help file subject 'Extending the system'
>> thus replacing the Omnibrowser script.
>>
>> --Hannes
>>
>>
>>
>> On 5/11/18, Tobias Pape <[hidden email]> wrote:
>>>
>>>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>>>
>>>> ... and... how to get Metacello please?
>>>>
>>>
>>> Installer ensureRecentMetacello
>>>
>>>>
>>>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>>>> Hi
>>>>>
>>>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> Following up on this thread.
>>>>>>
>>>>>> Where do I get the latest version of the RefactoringTools updated for
>>>>>> the most recent trunk version?
>>>>>>
>>>>>> There are some SqueakMap entries but they are outdated.
>>>>>>
>>>>>> This
>>>>>>
>>>>>>  http://wiki.squeak.org/squeak/831
>>>>>>
>>>>>> seems to give recent information as well.
>>>>>
>>>>> This is the most recent info.
>>>>>
>>>>> I short, if you have Metacello,
>>>>>
>>>>>      Metacello new
>>>>>              configuration: 'RefactoringTools';
>>>>>              load.
>>>>>
>>>>>
>>>>> That's about it.
>>>>> Marcel and Me will keep the Config up to date.
>>>>> We have not made any SqueakMap entries.
>>>>>
>>>>> Best regards
>>>>>      -Tobias
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> --Hannes
>>>>>>
>>>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>>>> Hi Jacob,
>>>>>>>
>>>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>>>> <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> I think offering two scopes is adequate:
>>>>>>> a) the entire system
>>>>>>> b) classes and extension methods whose package name matches either a
>>>>>>> prefix
>>>>>>> or a pattern
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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... ;-)
>>>>>>>>
>>>>>>>
>>>>>>> Remember that one can always generate more narrowly scoped refactoring
>>>>>>> by
>>>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>>>> system)
>>>>>>> 2. quitting the system
>>>>>>> 3. using the changes crash recovery tool to select the desired
>>>>>>> refactorings
>>>>>>> or by using method versions to revert any unwanted
>>>>>>>
>>>>>>> So having a simple generally useful scope such as package or package
>>>>>>> prefix
>>>>>>> would work for me.
>>>>>>>
>>>>>>> _,,,^..^,,,_
>>>>>>> best, Eliot
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Levente Uzonyi
On Tue, 3 Jul 2018, Tobias Pape wrote:

>
>> On 02.07.2018, at 15:26, Levente Uzonyi <[hidden email]> wrote:
>>
>> +1, but the configuration has to be updated first to load the correct versions.
>
> ok.. can you elaborate?

If you evaluate the proposed snippet in a Trunk image, you'll find that
the loaded Refactoring Engine code sends deprecated methods and there is
no support for the new class formats introduced by Spur.

Levente

>
>
>>
>> Levente
>>
>> On Mon, 2 Jul 2018, H. Hirzel wrote:
>>
>>> Proposal
>>>
>>> Take the result of this discussion
>>>
>>>  Installer ensureRecentMetacello.
>>>  Metacello new
>>>              configuration: 'RefactoringTools';
>>>              load.
>>>
>>>
>>> and put it into the Squeak help file subject 'Extending the system'
>>> thus replacing the Omnibrowser script.
>>>
>>> --Hannes
>>>
>>>
>>>
>>> On 5/11/18, Tobias Pape <[hidden email]> wrote:
>>>>
>>>>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>>>>
>>>>> ... and... how to get Metacello please?
>>>>>
>>>>
>>>> Installer ensureRecentMetacello
>>>>
>>>>>
>>>>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>>>>> Hi
>>>>>>
>>>>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> Following up on this thread.
>>>>>>>
>>>>>>> Where do I get the latest version of the RefactoringTools updated for
>>>>>>> the most recent trunk version?
>>>>>>>
>>>>>>> There are some SqueakMap entries but they are outdated.
>>>>>>>
>>>>>>> This
>>>>>>>
>>>>>>>  http://wiki.squeak.org/squeak/831
>>>>>>>
>>>>>>> seems to give recent information as well.
>>>>>>
>>>>>> This is the most recent info.
>>>>>>
>>>>>> I short, if you have Metacello,
>>>>>>
>>>>>>      Metacello new
>>>>>>              configuration: 'RefactoringTools';
>>>>>>              load.
>>>>>>
>>>>>>
>>>>>> That's about it.
>>>>>> Marcel and Me will keep the Config up to date.
>>>>>> We have not made any SqueakMap entries.
>>>>>>
>>>>>> Best regards
>>>>>>      -Tobias
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> --Hannes
>>>>>>>
>>>>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>>>>> Hi Jacob,
>>>>>>>>
>>>>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>>>>> <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think offering two scopes is adequate:
>>>>>>>> a) the entire system
>>>>>>>> b) classes and extension methods whose package name matches either a
>>>>>>>> prefix
>>>>>>>> or a pattern
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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... ;-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Remember that one can always generate more narrowly scoped refactoring
>>>>>>>> by
>>>>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>>>>> system)
>>>>>>>> 2. quitting the system
>>>>>>>> 3. using the changes crash recovery tool to select the desired
>>>>>>>> refactorings
>>>>>>>> or by using method versions to revert any unwanted
>>>>>>>>
>>>>>>>> So having a simple generally useful scope such as package or package
>>>>>>>> prefix
>>>>>>>> would work for me.
>>>>>>>>
>>>>>>>> _,,,^..^,,,_
>>>>>>>> best, Eliot
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Hannes Hirzel
Has this been fixed in the meantime so that the Omnibrowser load
script may be replaced with the Refactoring Engine load script in the
workspace which opens after choosing 'Help' / 'Extending the system'?

--Hannes

On 7/4/18, Levente Uzonyi <[hidden email]> wrote:

> On Tue, 3 Jul 2018, Tobias Pape wrote:
>
>>
>>> On 02.07.2018, at 15:26, Levente Uzonyi <[hidden email]> wrote:
>>>
>>> +1, but the configuration has to be updated first to load the correct
>>> versions.
>>
>> ok.. can you elaborate?
>
> If you evaluate the proposed snippet in a Trunk image, you'll find that
> the loaded Refactoring Engine code sends deprecated methods and there is
> no support for the new class formats introduced by Spur.
>
> Levente
>
>>
>>
>>>
>>> Levente
>>>
>>> On Mon, 2 Jul 2018, H. Hirzel wrote:
>>>
>>>> Proposal
>>>>
>>>> Take the result of this discussion
>>>>
>>>>  Installer ensureRecentMetacello.
>>>>  Metacello new
>>>>              configuration: 'RefactoringTools';
>>>>              load.
>>>>
>>>>
>>>> and put it into the Squeak help file subject 'Extending the system'
>>>> thus replacing the Omnibrowser script.
>>>>
>>>> --Hannes
>>>>
>>>>
>>>>
>>>> On 5/11/18, Tobias Pape <[hidden email]> wrote:
>>>>>
>>>>>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>>>>>
>>>>>> ... and... how to get Metacello please?
>>>>>>
>>>>>
>>>>> Installer ensureRecentMetacello
>>>>>
>>>>>>
>>>>>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> Following up on this thread.
>>>>>>>>
>>>>>>>> Where do I get the latest version of the RefactoringTools updated
>>>>>>>> for
>>>>>>>> the most recent trunk version?
>>>>>>>>
>>>>>>>> There are some SqueakMap entries but they are outdated.
>>>>>>>>
>>>>>>>> This
>>>>>>>>
>>>>>>>>  http://wiki.squeak.org/squeak/831
>>>>>>>>
>>>>>>>> seems to give recent information as well.
>>>>>>>
>>>>>>> This is the most recent info.
>>>>>>>
>>>>>>> I short, if you have Metacello,
>>>>>>>
>>>>>>>      Metacello new
>>>>>>>              configuration: 'RefactoringTools';
>>>>>>>              load.
>>>>>>>
>>>>>>>
>>>>>>> That's about it.
>>>>>>> Marcel and Me will keep the Config up to date.
>>>>>>> We have not made any SqueakMap entries.
>>>>>>>
>>>>>>> Best regards
>>>>>>>      -Tobias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> --Hannes
>>>>>>>>
>>>>>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>>>>>> Hi Jacob,
>>>>>>>>>
>>>>>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>>>>>> <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think offering two scopes is adequate:
>>>>>>>>> a) the entire system
>>>>>>>>> b) classes and extension methods whose package name matches either
>>>>>>>>> a
>>>>>>>>> prefix
>>>>>>>>> or a pattern
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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... ;-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Remember that one can always generate more narrowly scoped
>>>>>>>>> refactoring
>>>>>>>>> by
>>>>>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>>>>>> system)
>>>>>>>>> 2. quitting the system
>>>>>>>>> 3. using the changes crash recovery tool to select the desired
>>>>>>>>> refactorings
>>>>>>>>> or by using method versions to revert any unwanted
>>>>>>>>>
>>>>>>>>> So having a simple generally useful scope such as package or
>>>>>>>>> package
>>>>>>>>> prefix
>>>>>>>>> would work for me.
>>>>>>>>>
>>>>>>>>> _,,,^..^,,,_
>>>>>>>>> best, Eliot
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Browser menu interface to refactorings

Levente Uzonyi
On Thu, 6 Sep 2018, H. Hirzel wrote:

> Has this been fixed in the meantime so that the Omnibrowser load

As far as I know, there has been no new Metacello configuration published,
so no.

> script may be replaced with the Refactoring Engine load script in the
> workspace which opens after choosing 'Help' / 'Extending the system'?

It should be replaced anyway, since OB will probably not load into the
Trunk.

Levente

>
> --Hannes
>
> On 7/4/18, Levente Uzonyi <[hidden email]> wrote:
>> On Tue, 3 Jul 2018, Tobias Pape wrote:
>>
>>>
>>>> On 02.07.2018, at 15:26, Levente Uzonyi <[hidden email]> wrote:
>>>>
>>>> +1, but the configuration has to be updated first to load the correct
>>>> versions.
>>>
>>> ok.. can you elaborate?
>>
>> If you evaluate the proposed snippet in a Trunk image, you'll find that
>> the loaded Refactoring Engine code sends deprecated methods and there is
>> no support for the new class formats introduced by Spur.
>>
>> Levente
>>
>>>
>>>
>>>>
>>>> Levente
>>>>
>>>> On Mon, 2 Jul 2018, H. Hirzel wrote:
>>>>
>>>>> Proposal
>>>>>
>>>>> Take the result of this discussion
>>>>>
>>>>>  Installer ensureRecentMetacello.
>>>>>  Metacello new
>>>>>              configuration: 'RefactoringTools';
>>>>>              load.
>>>>>
>>>>>
>>>>> and put it into the Squeak help file subject 'Extending the system'
>>>>> thus replacing the Omnibrowser script.
>>>>>
>>>>> --Hannes
>>>>>
>>>>>
>>>>>
>>>>> On 5/11/18, Tobias Pape <[hidden email]> wrote:
>>>>>>
>>>>>>> On 10.05.2018, at 18:41, Chris Muller <[hidden email]> wrote:
>>>>>>>
>>>>>>> ... and... how to get Metacello please?
>>>>>>>
>>>>>>
>>>>>> Installer ensureRecentMetacello
>>>>>>
>>>>>>>
>>>>>>> On Thu, May 10, 2018 at 6:29 AM, Tobias Pape <[hidden email]> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>>> On 10.05.2018, at 09:19, H. Hirzel <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Hello
>>>>>>>>>
>>>>>>>>> Following up on this thread.
>>>>>>>>>
>>>>>>>>> Where do I get the latest version of the RefactoringTools updated
>>>>>>>>> for
>>>>>>>>> the most recent trunk version?
>>>>>>>>>
>>>>>>>>> There are some SqueakMap entries but they are outdated.
>>>>>>>>>
>>>>>>>>> This
>>>>>>>>>
>>>>>>>>>  http://wiki.squeak.org/squeak/831
>>>>>>>>>
>>>>>>>>> seems to give recent information as well.
>>>>>>>>
>>>>>>>> This is the most recent info.
>>>>>>>>
>>>>>>>> I short, if you have Metacello,
>>>>>>>>
>>>>>>>>      Metacello new
>>>>>>>>              configuration: 'RefactoringTools';
>>>>>>>>              load.
>>>>>>>>
>>>>>>>>
>>>>>>>> That's about it.
>>>>>>>> Marcel and Me will keep the Config up to date.
>>>>>>>> We have not made any SqueakMap entries.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>      -Tobias
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> --Hannes
>>>>>>>>>
>>>>>>>>> On 11/3/17, Eliot Miranda <[hidden email]> wrote:
>>>>>>>>>> Hi Jacob,
>>>>>>>>>>
>>>>>>>>>> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke
>>>>>>>>>> <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think offering two scopes is adequate:
>>>>>>>>>> a) the entire system
>>>>>>>>>> b) classes and extension methods whose package name matches either
>>>>>>>>>> a
>>>>>>>>>> prefix
>>>>>>>>>> or a pattern
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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... ;-)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Remember that one can always generate more narrowly scoped
>>>>>>>>>> refactoring
>>>>>>>>>> by
>>>>>>>>>> 1. performing the refactoring on some larger scope (e.g. the entire
>>>>>>>>>> system)
>>>>>>>>>> 2. quitting the system
>>>>>>>>>> 3. using the changes crash recovery tool to select the desired
>>>>>>>>>> refactorings
>>>>>>>>>> or by using method versions to revert any unwanted
>>>>>>>>>>
>>>>>>>>>> So having a simple generally useful scope such as package or
>>>>>>>>>> package
>>>>>>>>>> prefix
>>>>>>>>>> would work for me.
>>>>>>>>>>
>>>>>>>>>> _,,,^..^,,,_
>>>>>>>>>> best, Eliot
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>

12