Smalltalk › Squeak › Squeak - Dev

Browser whitewash

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Eliot Miranda-2

Browser whitewash

Hi All,

while all these cool new browsers are great I get on well with the standard browser and my multi-window hack around it. 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

Hannes Hirzel

Re: Browser whitewash

On 9/6/10, Eliot Miranda <[hidden email]> wrote:
> Hi All,
>
> while all these cool new browsers are great I get on well with the
> standard browser and my multi-window hack around it.

Interesting,
What do you mean by multi-window hack, Eliot?
--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
>

Eliot Miranda-2

Re: Browser whitewash

On Mon, Sep 6, 2010 at 1:59 AM, Hannes Hirzel <[hidden email]> wrote:

On 9/6/10, Eliot Miranda <[hidden email]> wrote:
> Hi All,
>
> while all these cool new browsers are great I get on well with the
> standard 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
>

Hans-Martin Mosner

Re: Browser whitewash

In reply to this post by Eliot Miranda-2

Am 06.09.2010 03:00, schrieb Eliot Miranda:
> 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.

+999

Using integer indices in the browser panes is very 80's... and it has
bitten me more than once.

Cheers,
Hans-Martin

Frank Shearar

Re: Browser whitewash

In reply to this post by Eliot Miranda-2

On 2010/09/06 02:00, Eliot Miranda wrote:

> Hi All,
>
> while all these cool new browsers are great I get on well with the
> standard browser and my multi-window hack around it. 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?

Browser already has methods like #selectedSystemCategoryName. Do these
methods do what you want? (Never mind that internally they use the
dreaded indices.)

Lots of places simply check the systemCategoryListIndex just to see if
something's selected; obviously, it's easy to just replace
"systemCategoryListIndex = 0" with "self selectedSystemCategoryName isNil"

By far the biggest hurdle to easily mucking around (apart from the fun
of breaking essential infrastructure) is the serious lack of tests.

> If someone did this I'd get round to using menu pragmas throughout and
> integrating the RB into the base Browser.

That's a very tasty carrot you're dangling there.

I've started slowly, carefully, weeding out the index stuff: for now,
I've just started on some baby steps (Tools-fbs.300) towards a Grand
Refactoring.

frank

Eliot Miranda-2

Re: Browser whitewash

On Wed, Mar 2, 2011 at 1:45 PM, Frank Shearar <[hidden email]> wrote:

On 2010/09/06 02:00, Eliot Miranda wrote:

Hi All,

while all these cool new browsers are great I get on well with the
standard browser and my multi-window hack around it. 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?

Browser already has methods like #selectedSystemCategoryName. Do these methods do what you want? (Never mind that internally they use the dreaded indices.)

What I want is that internally the browser /not/ use indices, and instead use symbols for the selected category name, the selected class name, the selected method protocol name, and the selected selector. The reason is of course that the indices become stale very quickly when the system is changed, either in other browsers or when packages are loaded/unloaded etc.

Lots of places simply check the systemCategoryListIndex just to see if something's selected; obviously, it's easy to just replace "systemCategoryListIndex = 0" with "self selectedSystemCategoryName isNil"

Right.

By far the biggest hurdle to easily mucking around (apart from the fun of breaking essential infrastructure) is the serious lack of tests.

If someone did this I'd get round to using menu pragmas throughout and
integrating the RB into the base Browser.

That's a very tasty carrot you're dangling there.

I find that carrot delicious too :)

I've started slowly, carefully, weeding out the index stuff: for now, I've just started on some baby steps (Tools-fbs.300) towards a Grand Refactoring.

Cool! That's great to hear.

frank