Updating internal Store tools

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

Updating internal Store tools

Randy Coulman
We have a number of internal tools that facilitate our work with Store, and I've been working on bringing them forward in 7.7.1.  Many of them continue to work as before, but I'm starting to convert them over to use the new Glorp-based Store code and the newer tools.

I'm having trouble figuring out which tools are staying, and which are going.  The package I'm working on right now should add a menu option to any browser that displays a list of package/bundle versions.  In 7.6, it adds a menu option to both VersionBrowser and PackageBrowserHelper.  It looks like VersionBrowser is still in use in 7.7.1, but is it going to live beyond that?

It looks to me like PackageListPane is a new class I need to work with.  Are there more classes used in the display of package/bundle versions anywhere? 

Is it possible to add menu extensions to PackageListPane using #pragmas, or do I have to override the menu resource method?

Finally, this package also drives the old MergeTool programmatically.  The idea is that it, if all of the merges can be resolved automatically, it applies them; otherwise, it opens the MergeTool UI and gives up.  I'm trying to convert this code over to the new Glorp-based merge tool, but I'm not clear on how best to do that.  Is it possible to just use ResolutionManager without using the MergeTool at all, or is there too much domain code in the tool itself for that to work?  I can try to provide more detail on what I'm trying to do if this question is unclear.

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Samuel S. Shuster-2
Randy:

Wow, that's a lot of good questions.

> We have a number of internal tools that facilitate our work with Store, and I've been working on bringing them forward in 7.7.1.  Many of them continue to work as before, but I'm starting to convert them over to use the new Glorp-based Store code and the newer tools.
>
> I'm having trouble figuring out which tools are staying, and which are going.  The package I'm working on right now should add a menu option to any browser that displays a list of package/bundle versions.  In 7.6, it adds a menu option to both VersionBrowser and PackageBrowserHelper.  It looks like VersionBrowser is still in use in 7.7.1, but is it going to live beyond that?

The existing VersionBrowser, and all of the Helpers are about to be obsolete in 7.8.

> It looks to me like PackageListPane is a new class I need to work with.  Are there more classes used in the display of package/bundle versions anywhere?  

There is a "new" tiny framework in 7.7.1, which has been extended a bit more in 7.8. This is the DefinitionsForListTool.

As you (may) have seen, this is a basic tool, which owns a text pane (and status pane) at the bottom, and has a "XXXListPane" at the top (all subclassed from DefinitionsForListPane). The plugin panes are MethodListPane, ClassListPane, BundleTreePane and so on. Clicking on something on the top pane causes a simple update chain to update the text and status at the bottom.

In 7.8, we get rid of the version browser, and it's ilk, by introducing PublishedPundleVersionsTool, which is a DefinitionsForListTool subclass, which hosts a special subclass of PackageListPane; PundleVersionPane, and then hosts the search module of package and bundles on the left.

> Is it possible to add menu extensions to PackageListPane using #pragmas, or do I have to override the menu resource method?

Yes it supports pragmas in extension methods. However, due to an interesting way we make one menu work in two places, adding a pragma to the PackageListPane will only show up in the local popup menu for the top pane, and not also in the Action menu of the hosting window.

> Finally, this package also drives the old MergeTool programmatically.  The idea is that it, if all of the merges can be resolved automatically, it applies them; otherwise, it opens the MergeTool UI and gives up.  I'm trying to convert this code over to the new Glorp-based merge tool, but I'm not clear on how best to do that.  Is it possible to just use ResolutionManager without using the MergeTool at all, or is there too much domain code in the tool itself for that to work?  I can try to provide more detail on what I'm trying to do if this question is unclear.

First off, the old Merge Tool, and all of its supporting mechanisms, will/have been moved to an independently loadable parcel: OldStoreTools, which in 7.8, is placed in the obsolete directory. So you can continue to use the old MergeTool if you wish, but it will no longer be supported.

We have done our best (but maybe not as good as we could) in making the ResolutionManager more the center of attention in the new MergeTool.

Most of the work is in ResolutionManager doMerge. It builds all of the proposal objects. From there, the MergeTool, for UI purposes, builds ResolutionPackageItems when you click on an selected resolution in the tree.

The thing that is in the UI, is the apply machinery, to sort a collection of resolutions in proper order, and then call apply on each.

Bottom line, we will be removing from the base image, in 7.8, OldBrowsers and all Store tools that rely on them (which are many, although many haven't been used in years).

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Randy Coulman
Thanks, Sames.  More below...

On Thu, Oct 14, 2010 at 11:00 AM, Samuel S. Shuster <[hidden email]> wrote:
> Is it possible to add menu extensions to PackageListPane using #pragmas, or do I have to override the menu resource method?


Yes it supports pragmas in extension methods. However, due to an interesting way we make one menu work in two places, adding a pragma to the PackageListPane will only show up in the local popup menu for the top pane, and not also in the Action menu of the hosting window.


I'm not seeing my pragma show up in either place in 7.7.1.  The implementation of PackageListPane>>listMenu says (self class mainMenu atNameKey: #Action) submenu, and #mainMenu is a menu resource method.  I don't see where it looks for any additional menu items via pragmas.  Am I missing something, or doing something wrong there?
 
First off, the old Merge Tool, and all of its supporting mechanisms, will/have been moved to an independently loadable parcel: OldStoreTools, which in 7.8, is placed in the obsolete directory. So you can continue to use the old MergeTool if you wish, but it will no longer be supported.

We have done our best (but maybe not as good as we could) in making the ResolutionManager more the center of attention in the new MergeTool.

Most of the work is in ResolutionManager doMerge. It builds all of the proposal objects. From there, the MergeTool, for UI purposes, builds ResolutionPackageItems when you click on an selected resolution in the tree.

The thing that is in the UI, is the apply machinery, to sort a collection of resolutions in proper order, and then call apply on each.


I'll play with the ResolutionManager a bit and I'll come back with more detailed questions if I have them.
 
Bottom line, we will be removing from the base image, in 7.8, OldBrowsers and all Store tools that rely on them (which are many, although many haven't been used in years).


This is why I'm trying to move my tools forward, but I haven't had time to look at 7.8 yet, so sometimes I don't know which are which.

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Samuel S. Shuster-2

On Oct 14, 2010, at 2:20 PM, Randy Coulman wrote:

> I'm not seeing my pragma show up in either place in 7.7.1.  The implementation of PackageListPane>>listMenu says (self class mainMenu atNameKey: #Action) submenu, and #mainMenu is a menu resource method.  I don't see where it looks for any additional menu items via pragmas.  Am I missing something, or doing something wrong there?

In package list pane, change listMenu to:

listMenu

        | menu |
        menu := (self class mainMenu atNameKey: #Action) submenu.
        menu augmentFrom: self class
                to: DefinitionsForListPane
                menuName: #listMenu
                for: self.
        ^menu

This is something I forgot to have in 7.7.1

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Randy Coulman

On Thu, Oct 14, 2010 at 12:48 PM, Samuel S. Shuster <[hidden email]> wrote:

In package list pane, change listMenu to:

listMenu

       | menu |
       menu := (self class mainMenu atNameKey: #Action) submenu.
       menu augmentFrom: self class
               to: DefinitionsForListPane
               menuName: #listMenu
               for: self.
       ^menu

This is something I forgot to have in 7.7.1


Yup, that works for the context pop-up menu.  Is there a way to make it work for the Action menu, or is that just not going to happen in 7.7.1?  It's not a big deal for me either way; just curious.

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Samuel S. Shuster-2
Randy:

> Yup, that works for the context pop-up menu.  Is there a way to make it work for the Action menu, or is that just not going to happen in 7.7.1?  It's not a big deal for me either way; just curious.


In 7.8, you'll be able to do it for DefinitionForListTool also.

Because of the strange way I did things, you would need to add a pragma on both the ...Tool and the ...Pane. Maybe I'll figure out a way to fix that so the ...Pane propagates to the ...Tool, but for now, no promises.

Oh, and I've made it so you can do it on all Pane or Tool subclasses in 7.8

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Updating internal Store tools

Randy Coulman
In reply to this post by Samuel S. Shuster-2

On Thu, Oct 14, 2010 at 11:00 AM, Samuel S. Shuster <[hidden email]> wrote:

We have done our best (but maybe not as good as we could) in making the ResolutionManager more the center of attention in the new MergeTool.

Most of the work is in ResolutionManager doMerge. It builds all of the proposal objects. From there, the MergeTool, for UI purposes, builds ResolutionPackageItems when you click on an selected resolution in the tree.

The thing that is in the UI, is the apply machinery, to sort a collection of resolutions in proper order, and then call apply on each.


I finally had a chance to get back the work I was doing here.  I now have something that works, but it requires a fairly ugly combination of MergeTool and ResolutionManager calls to get the job done.  The version of our tool that used the old MergeTool was able to use the tool without actually opening the UI.  That is not possible with the new tool.  I tried to do as much as possible with just the ResolutionManager, but it seems to be missing at least three key pieces that are provided by the MergeTool:  #collectPackageVersionsFrom: , #verifyAgainstImage: (which actually adds the image pundle to the collection of pundles to merge), and (as you mentioned), the apply machinery.

I basically had to duplicate much of the code in #mergePundleVersions: and #applyResolved: to remove the UI-specific bits.

If it's possible, it would be nice if there could be a better UI/model separation here.  I'd like to be able to do everything necessary with the ResolutionManager and ignore the MergeTool entirely here.

Thanks,
Randy
--
Randy Coulman
[hidden email]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc