Broken menu in explorer

Hello,

In the Squeak6.0alpha-17967-32bit image, open an explorer and attempt to
use the "browse class" item. You'll get a DNU from PluggableTreeMorph on
#browseCass.

It works in an inspector, though.

Stef

I have Squeak6.0alpha-17945-32bit.image and don't see this.
I update now for see some new introduce the bug


On 10/05/2018, 05:49, "Stéphane Rollandin" <[hidden email]> wrote:

> Hello,

In the Squeak6.0alpha-17967-32bit image, open an explorer and attempt
> to
use the "browse class" item. You'll get a DNU from PluggableTreeMorph on
>
#browseCass.

It works in an inspector, though.

Stef

> I have Squeak6.0alpha-17945-32bit.image and don't see this.
> I update now for see some new introduce the bug
>
>
> On 10/05/2018, 05:49, "Stéphane Rollandin" <[hidden email]> wrote:
>
>> Hello,

In the Squeak6.0alpha-17967-32bit image, open an explorer and attempt
>> to
use the "browse class" item. You'll get a DNU from PluggableTreeMorph on
>>
#browseCass.

It works in an inspector, though.

Stef


No, right now update to 17970 and do not show this


Edgar
@morplenauta

>> I have Squeak6.0alpha-17945-32bit.image and don't see this.
>> I update now for see some new introduce the bug
...
>
> No, right now update to 17970 and do not show this

I just reproduced it again.

I downloaded the Squeak6.0alpha-17967-32bit-201712221331-Windows archive
from http://files.squeak.org/6.0alpha/ and used the VM in that archive
to open Squeak6.0alpha-17967-32bit.image

Then I alt-clicked on the welcome window and get its halo, clicked on
the grey handle, did "explore morph", then from the explorer that opens
I right-clicked on the first line and did "browse class". Got the DNU.

Stef

> What is the intended difference between 'browse full' and 'browse class'
> in this menu ?

I dont know. As far as I am concerned, "browse full" works well enough;
it just happened that I noticed that "browse class" is broken.

Stef

That's been broken for a few years. It used to open a browser on a single class (with no method selected).

What is the intended difference between 'browse full' and 'browse class' in this menu ?

Browse class in other places seem to mean browse the selected class and method.

But I don't see how we could infer the method in this context

Best,

Karl

On Thu, May 10, 2018 at 2:01 PM, Stéphane Rollandin <[hidden email]> wrote:

I have Squeak6.0alpha-17945-32bit.image and don't see this.
I update now for see some new introduce the bug

...

No, right now update to 17970 and do not show this

I just reproduced it again.

I downloaded the Squeak6.0alpha-17967-32bit-201712221331-Windows archive from http://files.squeak.org/6.0alpha/ and used the VM in that archive to open Squeak6.0alpha-17967-32bit.image

Then I alt-clicked on the welcome window and get its halo, clicked on the grey handle, did "explore morph", then from the explorer that opens I right-clicked on the first line and did "browse class". Got the DNU.

Stef

> That's been broken for a few years. It used to open a browser on a
> single class (with no method selected).

Ah, ok. The problem is that I am used to my own tweaked image, so I
guess I fixed it there... indeed it works once muO is loaded.

Sorry for the noise (but we could maybe nuke that item it it is useless)

Stef

If you look in the code for ObjectExplorer (which is not a terribly pleasant experience) you can find implementations for #browseFull, #classHierarchy & #browseFullProtocol but not #browseClass

Just within the three methods actually there we have three totally different ways of opening a new browser; via ToolSet, via systemNavigation and by direct testing of Smalltalk isMorphic. Sigh. Nice thing to clean up for a simple job.

The practical problem is that ToolSet appears to have no access to make a single-class browser (which we do have, Browser newOnClass: works perfectly well) and in any case ToolSet goes via yet another damn AppRegistry (SystemBrowser). So we'd have to add methods to ObjectExplorer, ToolSet, SystemBrowser and probably another dozen currently hidden places. But in principle, implement ObjectExplorer>browseClass and ToolSet>browseSomethingOrOtherButNotClassBecauseThatIsAlreadyMisusedForBrowseFull and SystemBrowser>somethingOrOther

Or delete it from the ObejctExplorer menu.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Overdue for deincarnation.

> On 10-05-2018, at 12:19 PM, karl ramberg <[hidden email]> wrote:
>
> I think we can remove 'browse class' from both Inspector and ObjectExplorer if they just do the same thing as 'browse full'

Done for ObjectExplorer at least.

>
> And we should probably stick with one way of activating features like this.
> I got really confused when I looked at the different approaches.

Yah. The current mess is simply embarrassing.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- IQ = dx / (1 + dx), where x = age.

> On 10-05-2018, at 2:55 PM, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 10-05-2018, at 12:19 PM, karl ramberg <[hidden email]> wrote:
>>
>> I think we can remove 'browse class' from both Inspector and ObjectExplorer if they just do the same thing as 'browse full'
>
> Done for ObjectExplorer at least.

Hmph. The Inspector situation is just silly. The menu includes both
                ('browse full (b)' browseMethodFull)
and
                ('browse class' browseClass)
#browseClass does what one might expect. #browseMethodFull accidentally does the same thing because no Inspector class actually implements #selectedMessageName as anything other than ^nil and so StringHolder>>#browseMethodFull only ever opens a full browser. The right thing here is to just remove that entry from the menu.

But wait, it gets more insane! #browseClass actually delegates (in StringHolder) back to #browseMethodFull!

I think what has happened her over time is that somewhere #browseClass and 'browse full' have got confused in people's minds because of poor choices in naming things. ToolSet (etc) > browseClass actually open a full multi-pane class browser, not a single class browser. Add in the somewhat strange hierarchy around StringHolder and #browseMethodFull which is intended to open a full class browser with the class and method pre-set and we have a recipe for trouble.

An Inspector clearly isn't going to be opening the latter and making sensible use of #browseMethodFull. (Actually one might just possibly make sense of it within a CompiledMethodInspector? But we don't) So, what I'm going to do here is
remove the 'browse class' menu entry
make the 'browse full' menu entry refer to #browseClass since we widely use 'browse full' that way
similar for the key:from: method
make Inspector>browseClass actually directly do a #browseClass
I'm fairly sure that would strictly mean #selectedMessageName could be removed from Inspector


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Manual Writer's Creed:  Garbage in, gospel out.