On Mon, Sep 6, 2010 at 1:59 AM, Hannes Hirzel hannes.hirzel@gmail.comwrote:
On 9/6/10, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
while all these cool new browsers are great I get on well with thestandard browser and my multi-window hack around it.
Interesting, What do you mean by multi-window hack, Eliot?
In trunk go to preferences browsing and enable Multi-window browsers, then open a Browser. Use e.g. find class to ... find a class. Then use find class to ... find another class; voila the window label says 2. SecondClass. If you mouse in that label with the left/red button you'll find its a drop-down menu which selects between different browsers that now share the same screen real-estate. I depend on this; its a cheap tabbed browser implementation and at least for me I like its light-weight - IMO tabs steal too much screen real estate. The scheme marks changed browsers as red entries in the multi-window menu and won't discard edits in any of the other browsers on close without confirmation, etc.
--Hannes
But the multi-window
hack shows up one major weakness with the default Browser, and that is
it's
use of list indices (systemCategoryListIndex classListIndex messageCategoryListIndex messageListIndex). These should just be systemCategoryName, className, messageProtocol (categories are in System-Organization; classes have protocols) messageSelector. If this happened the indices the browser has into the system would never become obsolete as does happen for example when one adds a class to a category, invalidating any classListIndex values into the same category, or systemCategoryListIndexes as happens often when the SystemOrganization changes on loading a package. So if anyone is looking for a small useful project, someone who probably has RB chops, how about reimplementing
Browser
so that it is essentially unchanged except for the indexes being ripped
out,
buried and stomped on?
If someone did this I'd get round to using menu pragmas throughout and integrating the RB into the base Browser.
cheers Eliot