feedback about the "new inspector"
Locked
feedback about the "new inspector"
 
|
Hi guys
we tried to use and force you to use the new inspector and it does not fly that well. I'm sure that frederick is open to suggestion so please send your remarks. Here were mine :) Stef Hello Stef, here what is really strange and annoying is that we cannot see the collection elements in the right pane Now it is fixed. on the left Elements is confusing. because this is not clear the relationship with array, firstInd.... It shows only elements of any kind of collection (it is simply a collect: [:o | o] on the collection). on the right this is also frustrating that we cannot modify, touch the elements. Ok... but you can expand the Elements, select the element you want to change, put the new value in the description pane and accept it. I'm not sure that we want to see the class (in an expandable manner). For the methods may be you want to stop and show the methods but expandabel may be by defualt you should not show the class and methods as expandable and have a menu entry doing that (expand) I'm not sure to understand what you want. For me the NewInspector it is a like an infinite inspector: if you want to go into an object, you can. So if you want to inspect a class or the methods, you should have the possibility to do it. Fréd _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
Stef,
I had an open mind about it at first, but after having to retreat to an older image for a while and then seeing it again, (I respect you guys too much to soften this) I want no part of it (though I will look at improvements you want us to try). The choice of a simple inspector and the explorer is hard to beat - I can easily toggle between them with a right click. Anything that tries to do a shotgun wedding of the two ideas is a loser IMHO. I do some expensive computation, and I use a fair amount of lazy initialization, network proxies, etc. to soften the blow. There are times when the explorer is an expensive way to go. The new inspector will likely suffer the same problem, and I find it a serious step backward from explorer. The new inspector reminds me of something I wrote for browsing Dolphin code, IIRC at a package level. It was helpful, but not all that much, so I would use it only when I _really_ got lost. The mission was different, but I suspect the fate of the new inspector would be the same - I might use at times if it were offered by say control-shift-i vs. control-i for the regular inspector, but I prefer the existing tools. Just my 2 asCents. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Wednesday, October 21, 2009 8:55 AM To: Pharo Development Subject: [Pharo-project] feedback about the "new inspector" Hi guys we tried to use and force you to use the new inspector and it does not fly that well. I'm sure that frederick is open to suggestion so please send your remarks. Here were mine :) Stef Hello Stef, here what is really strange and annoying is that we cannot see the collection elements in the right pane Now it is fixed. on the left Elements is confusing. because this is not clear the relationship with array, firstInd.... It shows only elements of any kind of collection (it is simply a collect: [:o | o] on the collection). on the right this is also frustrating that we cannot modify, touch the elements. Ok... but you can expand the Elements, select the element you want to change, put the new value in the description pane and accept it. I'm not sure that we want to see the class (in an expandable manner). For the methods may be you want to stop and show the methods but expandabel may be by defualt you should not show the class and methods as expandable and have a menu entry doing that (expand) I'm not sure to understand what you want. For me the NewInspector it is a like an infinite inspector: if you want to go into an object, you can. So if you want to inspect a class or the methods, you should have the possibility to do it. Fréd _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
In reply to this post by Stéphane Ducasse
I haven't used this new inspector much, but so far I'm not thrilled
either. As a concrete example, do "Undeclared inspect". In the old dictionary inspector I get all the keys in the left pane and the selected key's value in the right pane. It is simple but it provides the info I need. In the new inspector there is too much stuff that I don't care about, like class and methods. Why would I want to look at the class Dictionary or at the bytecodes of a method of this class? Sometimes I do, but in this case I know how to get there in other ways. Btw, what I don't understand is why the keys of the dictionary are all displayed in square brackets. It somehow suggests that these are blocks, but they are plain symbols. Also I miss menu items. For instance, in the old dictionary inspector there is a menu item "reference" that you get by right clicking on a key. In the example of inspecting the undeclared dictionary, this item is key to find where the undeclared bindings come from. Also I miss the menu item "Chase pointers". Hence, as an improvement I suggest to remove all Class and Methods entries in the trees and check the lost menu items. Cheers, Adrian On Oct 21, 2009, at 15:54 , Stéphane Ducasse wrote: > Hi guys > > we tried to use and force you to use the new inspector and it does not > fly that well. > I'm sure that frederick is open to suggestion so please send your > remarks. Here were mine :) > > Stef > > > Hello Stef, > > > > here what is really strange and annoying is that we cannot see the > collection elements in the right pane > > Now it is fixed. > > on the left Elements is confusing. because this is not clear the > relationship with array, firstInd.... > It shows only elements of any kind of collection (it is simply a > collect: [:o | o] on the collection). > > on the right this is also frustrating that we cannot modify, touch the > elements. > > Ok... but you can expand the Elements, select the element you want to > change, put the new value in the description pane and accept it. > > I'm not sure that we want to see the class (in an expandable manner). > For the methods may be you want to stop and show the methods but > expandabel > may be by defualt you should not show the class and methods as > expandable and have a menu entry doing that (expand) > > I'm not sure to understand what you want. For me the NewInspector it > is a like an infinite inspector: if you want to go into an object, you > can. So if you want to inspect a class or the methods, you should have > the possibility to do it. > > Fréd > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Also, for an instance class defined as a variableSubclass, the contents of
the 'slots' are not displayed in the inspector. This is decidedly unhelpful. Define class as: Object variableSubclass: #MyClass instanceVariableNames: '' classVariableBanes: '' poolDictionaries: '' category: 'MyCat' Create an instance and execute it as follows (MyClass new: 5) inspect and you will not see the 5 slots. Regards, Reg > I haven't used this new inspector much, but so far I'm not thrilled > either. > > As a concrete example, do "Undeclared inspect". In the old dictionary > inspector I get all the keys in the left pane and the selected key's > value in the right pane. It is simple but it provides the info I need. > In the new inspector there is too much stuff that I don't care about, > like class and methods. Why would I want to look at the class > Dictionary or at the bytecodes of a method of this class? Sometimes I > do, but in this case I know how to get there in other ways. Btw, what > I don't understand is why the keys of the dictionary are all displayed > in square brackets. It somehow suggests that these are blocks, but > they are plain symbols. > > Also I miss menu items. For instance, in the old dictionary inspector > there is a menu item "reference" that you get by right clicking on a > key. In the example of inspecting the undeclared dictionary, this item > is key to find where the undeclared bindings come from. Also I miss > the menu item "Chase pointers". > > Hence, as an improvement I suggest to remove all Class and Methods > entries in the trees and check the lost menu items. > > Cheers, > Adrian > > > > On Oct 21, 2009, at 15:54 , Stéphane Ducasse wrote: > >> Hi guys >> >> we tried to use and force you to use the new inspector and it does not >> fly that well. >> I'm sure that frederick is open to suggestion so please send your >> remarks. Here were mine :) >> >> Stef >> >> >> Hello Stef, >> >> >> >> here what is really strange and annoying is that we cannot see the >> collection elements in the right pane >> >> Now it is fixed. >> >> on the left Elements is confusing. because this is not clear the >> relationship with array, firstInd.... >> It shows only elements of any kind of collection (it is simply a >> collect: [:o | o] on the collection). >> >> on the right this is also frustrating that we cannot modify, touch the >> elements. >> >> Ok... but you can expand the Elements, select the element you want to >> change, put the new value in the description pane and accept it. >> >> I'm not sure that we want to see the class (in an expandable manner). >> For the methods may be you want to stop and show the methods but >> expandabel >> may be by defualt you should not show the class and methods as >> expandable and have a menu entry doing that (expand) >> >> I'm not sure to understand what you want. For me the NewInspector it >> is a like an infinite inspector: if you want to go into an object, you >> can. So if you want to inspect a class or the methods, you should have >> the possibility to do it. >> >> Fréd >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
In reply to this post by Stéphane Ducasse
I agree that we need to refine the ideas in the inspector. Is Frederic
on this list? I also understood from Niko on monday that he is working on an alternative inspector that very much ressembles the one from Visualworks (which I very much like). The expandable tree 'infinite inspector' is a good idea for exploring an object's state but it should probably not be applied to everything that one can navigate to from within the object (i.e. not for methods). Getting to the methods from within the inspector is cool but if they expand in the same tree as the state, you quickly end up with a tree that does not show you anything anymore. After a couple of expansions, I often get a tree mixing state and behavior on different levels, with long method lists that require me to scroll through the tree and close levels again to see what I want. In the end, I have no easy way of navigating the object structure anymore because opening/ closing the tree levels to see what I want in a single window becomes not manageable. Here is what I would like to see happening (and I'm willing to help to get there too!): - Double clicking on an item in the tree on the left should open a new inspector window on that item (I really do not like adding it as a root in the same window: I find it confusing having two roots). This will already allow me to open up another view on the same structure or keep a window open on certain structure so I can return to it afterwards. - Do not make the methods expandable in the tree but rather open a list of methods in the right-hand pane that can be selected (and 'send' to the object if it's a unary message). Right now, selecting methods will give the list of selectors, which is not so useful. - Use visual icons instead of 'Class' and 'Methods' (duno if this is possible in the treemorph?) - Do not 'inspect/explore' the class as a normal object but make it jump to a browser instead On 21 Oct 2009, at 15:54, Stéphane Ducasse wrote: > Hi guys > > we tried to use and force you to use the new inspector and it does not > fly that well. > I'm sure that frederick is open to suggestion so please send your > remarks. Here were mine :) > > Stef > > > Hello Stef, > > > > here what is really strange and annoying is that we cannot see the > collection elements in the right pane > > Now it is fixed. > > on the left Elements is confusing. because this is not clear the > relationship with array, firstInd.... > It shows only elements of any kind of collection (it is simply a > collect: [:o | o] on the collection). > > on the right this is also frustrating that we cannot modify, touch the > elements. > > Ok... but you can expand the Elements, select the element you want to > change, put the new value in the description pane and accept it. > > I'm not sure that we want to see the class (in an expandable manner). > For the methods may be you want to stop and show the methods but > expandabel > may be by defualt you should not show the class and methods as > expandable and have a menu entry doing that (expand) > > I'm not sure to understand what you want. For me the NewInspector it > is a like an infinite inspector: if you want to go into an object, you > can. So if you want to inspect a class or the methods, you should have > the possibility to do it. > > Fréd > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
Hi Johan,
On 21.10.2009, at 18:39, Johan Brichau wrote: > I also understood from Niko on monday that he is working on an > alternative inspector that very much ressembles the one from > Visualworks. Yes, with Toon Verwaest, it should get ready on the weekend. :) Niko _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
In reply to this post by Johan Brichau
I think that frederick is on the list.
Fred? On Oct 21, 2009, at 6:39 PM, Johan Brichau wrote: > I agree that we need to refine the ideas in the inspector. Is Frederic > on this list? > > I also understood from Niko on monday that he is working on an > alternative inspector that very much ressembles the one from > Visualworks (which I very much like). > > The expandable tree 'infinite inspector' is a good idea for exploring > an object's state but it should probably not be applied to everything > that one can navigate to from within the object (i.e. not for > methods). Getting to the methods from within the inspector is cool but > if they expand in the same tree as the state, you quickly end up with > a tree that does not show you anything anymore. After a couple of > expansions, I often get a tree mixing state and behavior on different > levels, with long method lists that require me to scroll through the > tree and close levels again to see what I want. In the end, I have no > easy way of navigating the object structure anymore because opening/ > closing the tree levels to see what I want in a single window becomes > not manageable. > > Here is what I would like to see happening (and I'm willing to help to > get there too!): > > - Double clicking on an item in the tree on the left should open a new > inspector window on that item (I really do not like adding it as a > root in the same window: I find it confusing having two roots). This > will already allow me to open up another view on the same structure or > keep a window open on certain structure so I can return to it > afterwards. > > - Do not make the methods expandable in the tree but rather open a > list of methods in the right-hand pane that can be selected (and > 'send' to the object if it's a unary message). Right now, selecting > methods will give the list of selectors, which is not so useful. > > - Use visual icons instead of 'Class' and 'Methods' (duno if this is > possible in the treemorph?) > > - Do not 'inspect/explore' the class as a normal object but make it > jump to a browser instead > > > > On 21 Oct 2009, at 15:54, Stéphane Ducasse wrote: > >> Hi guys >> >> we tried to use and force you to use the new inspector and it does >> not >> fly that well. >> I'm sure that frederick is open to suggestion so please send your >> remarks. Here were mine :) >> >> Stef >> >> >> Hello Stef, >> >> >> >> here what is really strange and annoying is that we cannot see the >> collection elements in the right pane >> >> Now it is fixed. >> >> on the left Elements is confusing. because this is not clear the >> relationship with array, firstInd.... >> It shows only elements of any kind of collection (it is simply a >> collect: [:o | o] on the collection). >> >> on the right this is also frustrating that we cannot modify, touch >> the >> elements. >> >> Ok... but you can expand the Elements, select the element you want to >> change, put the new value in the description pane and accept it. >> >> I'm not sure that we want to see the class (in an expandable manner). >> For the methods may be you want to stop and show the methods but >> expandabel >> may be by defualt you should not show the class and methods as >> expandable and have a menu entry doing that (expand) >> >> I'm not sure to understand what you want. For me the NewInspector it >> is a like an infinite inspector: if you want to go into an object, >> you >> can. So if you want to inspect a class or the methods, you should >> have >> the possibility to do it. >> >> Fréd >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
In reply to this post by Johan Brichau
2009/10/21 Johan Brichau <[hidden email]>:
> - Do not 'inspect/explore' the class as a normal object but make it > jump to a browser instead I don't agree with it. Class is a normal object and must be inspected as all other objects, I think. But, it would be great to have menu item or shortcut to open the class being inspected in a browser. I'm not very experienced squeak/pharo user but as for me, I've used the object explorer most of the time instead of inspector. So I like the new inspector. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
On 22 Oct 2009, at 11:03, George Herolyants wrote: > 2009/10/21 Johan Brichau <[hidden email]>: >> - Do not 'inspect/explore' the class as a normal object but make it >> jump to a browser instead > > I don't agree with it. Class is a normal object and must be inspected > as all other objects, I think. But, it would be great to have menu > item or shortcut to open the class being inspected in a browser. Of course, inspecting classes as normal objects should still be possible using the inspector. In essence, 'Object inspect' should still open the normal inspector. My comment relates to having the 'Class' link in the tree. I have never wanted to inspect the class of an object at that level when inspecting 'regular objects'. Instead, I want to know the Object's class and use the convenient class browsers to find which methods the object understands. cheers ---------------------------- Johan Brichau [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
2009/10/22 Johan Brichau <[hidden email]>:
> My comment relates to having the 'Class' link in the tree. I have > never wanted to inspect the class of an object at that level when > inspecting 'regular objects'. Instead, I want to know the Object's > class and use the convenient class browsers to find which methods the > object understands. Oh, sorry for misunderstanding :) Of course I'm fully agreed with you. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
In reply to this post by Johan Brichau
Yes or you click on the class and say expand and this means that you
inpect it then. Stef On Oct 22, 2009, at 11:41 AM, Johan Brichau wrote: > > On 22 Oct 2009, at 11:03, George Herolyants wrote: > >> 2009/10/21 Johan Brichau <[hidden email]>: >>> - Do not 'inspect/explore' the class as a normal object but make it >>> jump to a browser instead >> >> I don't agree with it. Class is a normal object and must be inspected >> as all other objects, I think. But, it would be great to have menu >> item or shortcut to open the class being inspected in a browser. > > Of course, inspecting classes as normal objects should still be > possible using the inspector. > In essence, 'Object inspect' should still open the normal inspector. > > My comment relates to having the 'Class' link in the tree. I have > never wanted to inspect the class of an object at that level when > inspecting 'regular objects'. Instead, I want to know the Object's > class and use the convenient class browsers to find which methods the > object understands. > > cheers > > ---------------------------- > Johan Brichau > [hidden email] > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: feedback about the "new inspector"
|
|
Hello,
Thank you for the feedback on NewInspector. This tool was firstly designed to be easily configurable for adapting the childs/label/description/callback to the needs of each developer. I think the default configuration seems to be too far from your wishes. The cool thing is that the configuration can be changed easily for each class :) So you must find the perfect default configuration for each class.
I'll go to OOPSLA tomorrow. I will try to reflect on all your comments during the conference. Fréd ----
Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Thu, Oct 22, 2009 at 1:56 PM, Stéphane Ducasse <[hidden email]> wrote: Yes or you click on the class and say expand and this means that you _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |