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
|
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". |
In reply to this post by Jakob Reschke
Hi Jacob,
On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke <[hidden email]> wrote:
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
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 |
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
|
well, that's not too hard, either ;-) On 11/3/17 4:41 AM, Marcel Taeumel
wrote:
menuHiding.03Nov0548.cs (3K) Download Attachment |
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
|
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
|
On Fri, Nov 3, 2017 at 03:04 Marcel Taeumel <[hidden email]> wrote:
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 |
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 > |
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 >> > |
... 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 >>> >> > > |
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 >>>> >>> >> >> > > |
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 >>>> >>> >> >> > |
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 >>>>> >>>> >>> >>> >> > > > |
+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 >>>>>> >>>>> >>>> >>>> >>> >> >> >> |
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 |
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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> > |
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 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >> |
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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>> > > |
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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> |
Free forum by Nabble | Edit this page |