On 2010-05-11, at 11:45 AM, Casey Ransberger wrote:

> One interesting way forward, I think, would be to look into what it would take to make the refactoring engine (separate from the OB framework) integrate with the standard system browser in Squeak (in some way such that it would be unloadable.) Other than the neat icons in the list panes, what do you really get with OB? Better menu options for refactoring, and these (AFAIK) just expose functionality that's implemented in the refactoring engine anyway. I don't know of any applications other than the OB system browser that actually take advantage of OB as a browser-creation framework.
> 
> I'd vote against including a browser-creation framework in which only a single browser is implemented in the standard Squeak distribution. It adds a lot of complexity without giving a lot back in return. On the other hand, the refactoring engine might be interesting, so I don't have an opinion either way on that.

Why all the hate for OmniBrowser? Above, you seem to be saying, "I want a browser with the features that OmniBrowser has, but without the flexibility and modularity." You're even suggesting that someone should do a lot of work (and yes, it *is* a lot of work) to reimplement the functionality that OB already provides. 

By the way, there are quite a few other projects that use the OB framework. Off the top of my head:

- Seaside use it for configuration
- The Gemstone interface to Monticello is based on OB (runs great in Squeak!).
- The Gemstone Test-Runner is based on OB (runs great in Squeak!).
- Hernán Durand's Dependency Browser is based on OB
- My FileBrowser package
- OB-Tools, a debugger and inspector based on OB.

Now, OB isn't perfect. It has issues and bugs just like any significant piece of software. But why not fix them, or at least complain so that others can fix them?

Colin