Howto create speciel RB with thee panes?

>
> Hello all,
>
> I had a similar problem to Georg's; I wanted to port some old code
> that subclassed the pre-RB Browser class, and eventually gave up.
>
> Every time I've tried to customize the RB Browser (even like adding a
> menu item to the class list view), I've been confounded by its
> complexity and sparse documentation. Has anyone "ported" the old-
> style browser (or anything like it)?
>
> Do most users like the package/hierarchy selection in the RB browser?
> I generally use the FullBrowser just because I like the old system
> categories (even for my own new code).
>
> stp
>
> --
>      Stephen Travis Pope -- Santa Barbara, California, USA
>      http://create.ucsb.edu/~stp  http://HeavenEverywhere.com  http://
> FASTLabInc.com
>
>
> Begin forwarded message:
>
>> Resent-From: [hidden email]
>> From: "Georg Heeg" <[hidden email]>
>> Date: March 15, 2006 8:26:03 AM PST
>> To: <[hidden email]>
>> Resent-Cc: recipient list not shown: ;
>> Cc: "'engies'" <[hidden email]>
>> Subject: Howto create  speciel RB with thee panes?
>>
>> From the past there are several tools which still use the old
>> browser technology (example GHUndeclaredBrowser).
>>
>>
>> They all follow the same pattern: There are two lists above and a
>> text editor below. The first (left) list is a list of something and
>> the second list is a list of methods “related to” the selection(s)
>> in the first list.
>>
>>
>> What I found are prototypes of windows with just the second list
>> and the editor (CodeTool).
>>
>>
>> Does anybody know of or have a configurable window with these three
>> list or an instruction to create them based upon RB technology?
>>
>>
>> Georg
>>
>

> To add a menu item, just stick something like the following in the  
> method that implements the menu. Any message implemented in  
> MenuAutomaticGenerator will do.
>
>         <menuItem: 'Frobnicate'
>                 icon: nil
>                 nameKey: #frobnicate
>                 enablement: #isClassSelected
>                 indication: nil
>                 menu: #(#classMenu)
>                 position: 999.999>
>

> At 07:08 PM 3/15/2006, Stephen Travis Pope wrote:
>
>> Hello all,
>>
>> I had a similar problem to Georg's; I wanted to port some old code that  
>> subclassed the pre-RB Browser class, and eventually gave up.
>>
>> Every time I've tried to customize the RB Browser (even like adding a  
>> menu item to the class list view), I've been confounded by its  
>> complexity and sparse documentation. Has anyone "ported" the old-style  
>> browser (or anything like it)?
>
> Well, it's certainly not a model of simplicity, but I've not seen many  
> browsers that were.  To add a menu item, just stick something like the  
> following in the method that implements the menu. Any message  
> implemented in MenuAutomaticGenerator will do.
>
>         <menuItem: 'Frobnicate'
>                 icon: nil
>                 nameKey: #frobnicate
>                 enablement: #isClassSelected
>                 indication: nil
>                 menu: #(#classMenu)
>                 position: 999.999>
>
> You would hardly have to port the old-style browser. It's still in the  
> system, because it's still used in a few places, e.g. for Store database  
> browsing. We're working on getting it out, but it's not gone quite yet.
>
> I'm not sure how to do what Georg is asking, but you can certainly  
> reconfigure which of the various panes and tools there are and what  
> order they come in. Looking at how the browser opens in various  
> different modes (e.g. browsing packages vs. browsing a single package)  
> would probably be informative.
>
>> Do most users like the package/hierarchy selection in the RB browser?
>> I generally use the FullBrowser just because I like the old system  
>> categories (even for my own new code).
>
> I like it a lot. If you really want categories, I think you could just  
> uncomment something somewhere and get it back in the RB.
>
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it  
> run." - Niall Ross

> In general I am pleased with RB, it actually is built with pluggable
> extension points. As far as menus there is an RBActionCommandEditor
> which allows one to build , install and even save different sets of
> actions. RBCommand holds to a list of actions in a class var which are
> accessible via #actionNamed:
>
> This in combination with pragma based menu specification allow for the
> programmatic building of menus in RB. Check out:
> BrowserApplicationModel>>>#buildMenuFrom: aMenu , also:
> #createActionMenuItemFrom:
>
> so I will argue that RB was build with pluggability in mind even at the
> menu level and not just in the more understood RB tab pluggins. So I'm a
> fan but yes zero docs.

> Charles A. Monteiro wrote:
>> In general I am pleased with RB, it actually is built with pluggable  
>> extension points. As far as menus there is an RBActionCommandEditor  
>> which allows one to build , install and even save different sets of  
>> actions. RBCommand holds to a list of actions in a class var which are  
>> accessible via #actionNamed:
>>  This in combination with pragma based menu specification allow for the  
>> programmatic building of menus in RB. Check out:  
>> BrowserApplicationModel>>>#buildMenuFrom: aMenu , also:  
>> #createActionMenuItemFrom:
>>  so I will argue that RB was build with pluggability in mind even at  
>> the menu level and not just in the more understood RB tab pluggins. So  
>> I'm a fan but yes zero docs.
>
> I disagree, I was impressed with the RB when I started working with it  
> (and as a tool it functions very well for me), however I dislike the  
> implementation. The object model of the RB is mostly fine however the  
> method implementations are horrible since they are rife with case  
> statements. This makes it very hard to add extra cases since we have to  
> resort to either forking the code or maintaining package overrides which  
> is *hell* for methods that are packageoverridden by multiple parties.
>
>
> Another issue is that the RB is written to be cross-platform so the  
> integration with VW is not 'deep' enough.
> - We begot RBParseNodes that are a straight copy of VW's ParseNodes.
> - We have RB checking all kinds of parameters where we would be better  
> off without those checks because VW would give us superior 'correct it'  
> oprions if the RB would allow the erroneous parameters to reach the VW  
> code.
> - We have declarations of menus and actions sitting in a comment instead  
> of having these decls in pragmas or code that can be introspected upon
>
>
> I have written in the past that RB-on-VW in its current form is ossified  
> and will remain so for a long while, ironically holding back tools  
> advances in my favorite IDE :-(
>
> I think we need a VW-specific rewrite of the RB, using as much of it's  
> structure as possible but getting rid of unVW-isms, library duplications  
> and those pesky case statements. We also need to clean up it's UI  
> repainting algorithms since  the bugger is *slooow* in some situations  
> due to excessive whole-window repaints.
>
>

> Charles A. Monteiro wrote:
>> I guess I don't understand what you mean by saying you "disagree" :)
>>
>> what I said is that it was built to with extension points as oppossed to
>> what we had before i.e. with the old browsers which was basically just
>> Smalltalk. The funny thing is that just the fact that they were written  
>> in
>> Smalltalk made them more user extendable than most other IDEs.
>
> Right, what I meant is that the RB has only *a couple* of extension  
> points
> that are practical to use, despite the object model suggesting that it is
> highly pluggable. I often found I need to use packageoverrides when  
> trying to
> plug extensions into other places than the common ones (typically new
> CodeTools or menu actions).
>
>>
>> have you checked Heeg's goodie to make this better? I have not yet.
>
> No, not yet...
>
>> I am also curious about this statement you made:
>> > - We have declarations of menus and actions sitting in a comment  
>> instead
>> > of having these decls in pragmas or code that can be introspected upon
>>
>> can you provide me with an example in code which illustrates this.
>
> I looked it up, turns out I was confused with other frameworks (like  
> SmaCC and
> the HotDraw tool statemachine editor). Thanks for putting me straight :-/
>
>
>> From
>> what I see, the RB framework uses traditional menu resources, pragmas,  
>> and
>> I believe I saw some programmatic manual menu building,
>
> For the latter see RBActionEditor and RBCommand class>>actionArray
>
>
> R
> -

> Reinout and Charles, and all others,
>
> No wonder that no one has tried out our RB speedup patch yet. It has not
> been made available yet outside of AR 48877. As there has been several
> messages in this list about this patch, I have decided to make it  
> available
> now. It has not yet been reviewed or even approved.
>
>> From the description: "Each RB adds some of its components as  
>> dependents of
> ChangeSet. So I modified two update: methods to do nothing when a global
> information resource tells them to suppress all refreshes. I added  
> control
> of this resource to modifySystem:. Upon re-allowing updates all RBs are
> refreshed by sending updateNavigator."
>
> As the patch is a very small file (3k) I just attach it to this message.
>
> Georg
>
> -----Ursprüngliche Nachricht-----
> Von: Reinout Heeck [mailto:[hidden email]]
> Gesendet: Samstag, 18. März 2006 09:00
> An: [hidden email]
> Betreff: Re: Reusing the Refactoring Browser
>
> Charles A. Monteiro wrote:
> [...]
>
>>
>> have you checked Heeg's goodie to make this better? I have not yet.
>
> No, not yet...
>
> [...]
>