[ANN] RBCustomBrowserUI

Dear Travis et al,
    I've replicated RBCustomBrowserUI (and RBCustomBrowserUITests) to the Cincom OR.  This supports the '4-pane view of a subset of pundles' UI that I showed at ESUG.  Select one or more pundles in a 'Whole System' view to get the option of viewing them, e.g. select the Tool-IDE bundle to see:
      
It requires a custom refactoring version of the RB. (Use:
     Tools-Refactoring Browser ... CS11 RC3
or a version descended from it or merged from it;  do not load it with other versions.  Likewise, the tests expect bundle:
    RefactoringBrowserTests ... CS11 RC3
to be loaded.)

This is only an internal release of the custom refactoring project at the moment.  It tries to be unintrusive to main RB code, leading to a couple of round-about coding constructions in places where RB-in-VW7 optimisations (I assume) break the genericity of the framework.

I've made it visible so people can see whether they want it or not, and so Travis can be aware of it just in case the genericity issues have any connection with any RB-development lines he is considering.  If it is wanted, we can think about cleaning up its code and related RB code to make it better-integrated with the main RB and to address performance when viewing large parcels of large pundles.  If not, it works OK as what it is and can be left for now..

See package, blessing and class comments for details.

          Yours faithfully
             Niall Ross

On Fri, 12 Oct 2007 16:41:11 +0100
Niall Ross <[hidden email]> wrote:

>
> I've made it visible so people can see whether they want it or not, and

I want it!

Now let's see if it works here :-)

Thanks,
s.

Dear Stefan,

On Fri, 12 Oct 2007 16:41:11 +0100
Niall Ross [hidden email] wrote:

  

I've made it visible so people can see whether they want it or not, and 
    

I want it!

Now let's see if it works here :-)

Thanks,
s.
  

> The tests expect bundle:
>    RefactoringBrowserTests ... CS11 RC3
> to be loaded.

A few remarks in case they help:

 - Loading this bundle will prompt to load the dynamic refactoring (i.e. of method name) code.  If you don't want that for any reason (or you do, but want to test the new tool independently of it) then load the first three packages in the bundle, leaving the last.  (Unlike the pundle-focussing tool, the dynamic refactoring stuff is fully released.  It is not in the main Tools-Refactoring Browser bundle because it must have method wrappers loaded and, while many of the RB tests require wrappers, the rest of the RB itself does not.  We therefore keep dynamic renaming separate so users have the choice of having method wrappers in their development image or not.)

 - RBTestMethods (the first package in the RefactoringBrowserTests' bundle) has no real tests but two fake tests used to test the RBSUnitExtensions.  Select the other packages and run their tests, not the whole bundle or you will see one spurious failure and one spurious error caused by the undesired inclusion of these in the run.

 - All tests pass (allow several minutes :-/)) when an appropriate Tools-refactoring Browser version is loaded, provided you start with Help loaded and RBSUnitExtensions loaded.  (The RBStoreExtensions is also tested but that test is protected to give a trivial pass if the tool is not loaded.)  Be connected to (any) Store database;  a connection will be demanded if not already present.

 - If you then load RBCustomBrowserUI and RBCustomBrowserUITests, its tests (almost all inherited) should run green too, also taking a few minutes :-/) and of course the others will still run green.

 - (N.B #testPackagesAndParcels creates and then unloads RBPackageTestThatNobodyShouldDefine, RBOtherPackageTestThatNobodyShouldDefine and, in the superclass SomeNewParcelThatDoesntExist and AnotherNewParcelThatDoesntExist.  If any hiccough, e.g. absence of Help loaded or of a store db connection, causes this test to fail in either subclass or superclass, ensure these packages and parcels are all unloaded before rerunning.)

If all these tests run green but nevertheless you then have any problems with the tool, please let me know.  I'll be most pleased if you find it useful.

          Yours faithfully
             Niall Ross

Dear Stefan,
    I've just published a minor fix:  please use the latest version.

On Fri, 12 Oct 2007 16:41:11 +0100
Niall Ross [hidden email] wrote:

  

I've made it visible so people can see whether they want it or not, and 
    

I want it!

Now let's see if it works here :-)

Thanks,
s.
  

> The tests expect bundle:
>    RefactoringBrowserTests ... CS11 RC3
> to be loaded.

A few remarks in case they help:

 - Loading this bundle will prompt to load the dynamic refactoring (i.e. of method name) code.  If you don't want that for any reason (or you do, but want to test the new tool independently of it) then load the first three packages in the bundle, leaving the last.  (Unlike the pundle-focussing tool, the dynamic refactoring stuff is fully released.  It is not in the main Tools-Refactoring Browser bundle because it must have method wrappers loaded and, while many of the RB tests require wrappers, the rest of the RB itself does not.  We therefore keep dynamic renaming separate so users have the choice of having method wrappers in their development image or not.)

 - RBTestMethods (the first package in the RefactoringBrowserTests' bundle) has no real tests but two fake tests used to test the RBSUnitExtensions.  Select the other packages and run their tests, not the whole bundle or you will see one spurious failure and one spurious error caused by the undesired inclusion of these in the run.

 - All tests pass (allow several minutes :-/)) when an appropriate Tools-refactoring Browser version is loaded, provided you start with Help loaded and RBSUnitExtensions loaded.  (The RBStoreExtensions is also tested but that test is protected to give a trivial pass if the tool is not loaded.)  Be connected to (any) Store database;  a connection will be demanded if not already present.

 - If you then load RBCustomBrowserUI and RBCustomBrowserUITests, its tests (almost all inherited) should run green too, also taking a few minutes :-/) and of course the others will still run green.

 - (N.B #testPackagesAndParcels creates and then unloads RBPackageTestThatNobodyShouldDefine, RBOtherPackageTestThatNobodyShouldDefine and, in the superclass SomeNewParcelThatDoesntExist and AnotherNewParcelThatDoesntExist.  If any hiccough, e.g. absence of Help loaded or of a store db connection, causes this test to fail in either subclass or superclass, ensure these packages and parcels are all unloaded before rerunning.)

If all these tests run green but nevertheless you then have any problems with the tool, please let me know.  I'll be most pleased if you find it useful.

Lastly (I trust this is obvious but if it is not please tell me - it would affect tool usability), when you switch to viewing just a specific bundle or set of pundles, be aware your whole environment in that browser is _just_ that, so:

 - finding implementors, methods with strings, etc., via the menu items in that browser is now searching only in that environment, not the whole image, eaxctly as it would be in a 3-pane browser.  Switching back reverts to whole-image searching.

 - Menu refactorings of course apply to the whole image, as they do in any RB view.

 - Tearing Off the rewrite tool gives whole-image behaviour (i.e. no environment is selected initially, whereas in the 3-pane browser, the browsed pundles would be the initial scope of the

          Yours faithfully
             Niall Ross