this is probably like that but you may want to be able to swicth (ie inspect dictionary as default objects.)
On Nov 26, 2009, at 8:11 PM, Peter Hugosson-Miller wrote: > Rather than a mode for inspecting dictionaries, wouldn't it be better > to have a subclass, say DictionaryInspector, which could be selected > as needed by means of an #inspectorClass method. Then, if more > specializations turn up, they could be added in the same way. > > Just a thought that struck me. > > -- > Cheers, > Peter. > > On 26 nov 2009, at 20.01, Stéphane Ducasse <[email protected]> > wrote: > >> Ok I will check. >> may be we can have a mode that does not provide object >> interpretation (for dict we would only see >> tally and array not the dictionary, ...). >> >> Stef >> >> On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote: >> >>> Just yesterday, I asked Frederic to remove the class and method >>> entries that add a lot of the noise and are most often not needed. He >>> committed a new version with these changes. >>> >>> But from Stef's analysis it seems there is a bit more needed to make >>> this inspector fly... And a really good inspector is key! >>> >>> Another item to add to Stef's list: what is the point of the item >>> "Keys"? I can see the keys of the dictionary already by opening >>> "Elements". So this seems superfluous. >>> >>> I wonder why inspecting a dictionary could not be reduced to the >>> information that is actually of interest, namely the keys and their >>> values. So when opening a dictionary, the subtree would directly >>> display the keys in the left pane (no array, tally, Keys, Elements). >>> If a key is selected, its value is printed in the right pane. >>> Expanding a key would dive into its associated value. Actually, I >>> think what I described here is more or less the behavior of the old >>> explore tool. >>> >>> Cheers, >>> Adrian >>> >>> >>> On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> again I did a demo of smalltalk and the newInspecotr got in my way. >>>> I tried to analyze what did not work: >>>> - apparently the refresh does not work. Does change in instance >>>> variables get refreshed in the inspector? >>>> >>>> I try to understand what get in my way in general. >>>> - when an object has few instance variable I think that it is >>>> lost >>>> in the sea of trees. >>>> >>>> - I think that the |> class is not useful at the top level. >>>> May be just having Class: and the class Name is enough no need >>>> for >>>> the |> >>>> May be the Class : ByteString should appear after the Elements: >>>> >>>> - the |> methods to be useful should be sorted by category >>>> >>>> in the screenshot >>>> Why do I see the instance variable of the dictionary (array and >>>> tally) I find that confusing? >>>> Because I get elements and at the same time the instance >>>> variables. >>>> >>>> I do not understand why some lines are bold and other blue >>>> >>>> When we click on connectInfo I see on the right pane >>>> - size : 5 >>>> [#host] : a SocketAddress (size: 24) >>>> [#loginMethod] : #zork >>>> [#password] : nil >>>> [#port] : 110 >>>> [#user] : 'stephane.ducasse' >>>> But I cannot modify anything. >>>> >>>> What is the point to have Elements expanded in the left pane >>>> when I >>>> get the contents by clicking on the instance >>>> variable and getting the contents on the right. >>>> >>>> Then Keys should probably close to Elements. >>>> >>>> I do not see the point to have |> for individual method >>>> I do not understand why we see Elements and ByteCode >>>> I get a DNU when I click on Elements of a method BTW >>>> >>>> >>>> <Screen shot 2009-11-26 at 6.14.31 >>>> PM.png>_______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
