EyeTreeInspector not ready for prime-time
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form... As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost ----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean, The previous tools had quirks as well, lets try to fix the issues one by one, can't be that big a problem with your UI/Morph/Spec skills ;-) I find the Eye tools pretty cool, they do improve certain aspects (like sharing between inspector/explorer, making it easy to add custom extensions), there is just some polish needed. Sven On 13 Mar 2014, at 12:51, Sean P. DeNigris <sean@clipperadams.com> wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
It would be great if we could reach an effective goal: having a super cool inspector and avoiding reinventing all this. GTInspector is truly effective and usable. Maybe we should change the name of the moose image into Pharo-Dev or something. Alexandre On Mar 13, 2014, at 8:51 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
These are different things: - Eye tools are a reimplementation of the classic tools - GTInspector and friends try to break new ground, reinvent ideas and concepts For me this is not an either-or discussion, both have their place and are important. And it is perfectly possible to use a Moose image as a starting point, that is absolutely fine, but again, it is not either-or but and-and. On 13 Mar 2014, at 13:42, Alexandre Bergel <alexandre.bergel@me.com> wrote:
It would be great if we could reach an effective goal: having a super cool inspector and avoiding reinventing all this.
GTInspector is truly effective and usable. Maybe we should change the name of the moose image into Pharo-Dev or something.
Alexandre
On Mar 13, 2014, at 8:51 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
These are different things:
- Eye tools are a reimplementation of the classic tools - GTInspector and friends try to break new ground, reinvent ideas and concepts
I do not know whether they are that different. Nautilus is a reimplementation of the OB and the old standard browser. Is Nautilus different or complementary to OB?
For me this is not an either-or discussion, both have their place and are important.
Indeed. I agree on this. Alexandre
And it is perfectly possible to use a Moose image as a starting point, that is absolutely fine, but again, it is not either-or but and-and.
On 13 Mar 2014, at 13:42, Alexandre Bergel <alexandre.bergel@me.com> wrote:
It would be great if we could reach an effective goal: having a super cool inspector and avoiding reinventing all this.
GTInspector is truly effective and usable. Maybe we should change the name of the moose image into Pharo-Dev or something.
Alexandre
On Mar 13, 2014, at 8:51 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I agree with that. I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc. A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot. Phil On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I went back to compare the explorer in 2.0, the only visible (not behaviour) difference that I see is the class field, it would probably be better to lose that: But I hate the 'all inst vars' field, who uses that and for what ?? On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
yeah, and saw what happens when you use the keyboard? try this: 1. selecting in a workspace 2. cmd+shift+i 3. when it opens, press 3 ro 4 times the right arrow you navigate the class instead of the instace not great I miss the old explorer On Mar 13, 2014, at 4:30 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I went back to compare the explorer in 2.0, the only visible (not behaviour) difference that I see is the class field, it would probably be better to lose that:
<Screen Shot 2014-03-13 at 20.28.45.png>
<Screen Shot 2014-03-13 at 20.29.10.png>
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I see that you haven't clicked on a 17K long string that opens a 17K items long tree of characters with nice icons and makes your image bloat to 200+MB in size.
--> 223 162 288 bytes for XXXX.image Look: (in 2.0 the explorer just shows a piece of text) [image: Inline image 1]
.
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com
wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
But you have GB's of RAM, right ;-) See EyeInspector>>#limit1 and limit2 that control how much to show in collections, maybe 100000 it too high ;-) But in general, I think maybe we could use a dedicated EyeStringInspector. I agree that viewing a bigger string in the explorer/tree view is a bit silly, but it is correct though. Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. For strings characters could then no longer be shown. On 13 Mar 2014, at 20:49, phil@highoctane.be wrote:
I see that you haven't clicked on a 17K long string that opens a 17K items long tree of characters with nice icons and makes your image bloat to 200+MB in size.
--> 223 162 288 bytes for XXXX.image
Look: (in 2.0 the explorer just shows a piece of text)
<13-03-14 20-47-35.png>
.
<Screen Shot 2014-03-13 at 20.28.45.png>
<Screen Shot 2014-03-13 at 20.29.10.png>
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Good ideas. Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file - open that in the EyeTreeExplorer.) Now, on the GB thing, sure but the EyeTreeExplorer suddenly feels sluggish, not matter how much RAM there is. Phil On Thu, Mar 13, 2014 at 10:46 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
But you have GB's of RAM, right ;-)
See EyeInspector>>#limit1 and limit2 that control how much to show in collections, maybe 100000 it too high ;-)
But in general, I think maybe we could use a dedicated EyeStringInspector.
I agree that viewing a bigger string in the explorer/tree view is a bit silly, but it is correct though.
Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. For strings characters could then no longer be shown.
On 13 Mar 2014, at 20:49, phil@highoctane.be wrote:
I see that you haven't clicked on a 17K long string that opens a 17K items long tree of characters with nice icons and makes your image bloat to 200+MB in size.
--> 223 162 288 bytes for XXXX.image
Look: (in 2.0 the explorer just shows a piece of text)
<13-03-14 20-47-35.png>
.
<Screen Shot 2014-03-13 at 20.28.45.png>
<Screen Shot 2014-03-13 at 20.29.10.png>
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris < sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mar 13, 2014, at 6:53 PM, phil@highoctane.be wrote:
Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file
that actually happened to me a couple of times, yeah sebastian o/
Looks like there is some shared fun with ZnClient and https then :-) ... on my way to ZnNinja (slowly). Sven, HTTPComponents is really Ubercool! Phil On Thu, Mar 13, 2014 at 11:00 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
On Mar 13, 2014, at 6:53 PM, phil@highoctane.be wrote:
Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file
that actually happened to me a couple of times, yeah
sebastian <https://about.me/sebastianconcept>
o/
Hello, EyeInspector>>#limit1 and limit2 are here to limit the size of collection shown. In the old inspector the limits were 100 and 10, which means you could see the first 100 and the last 10 elements. We put more in the EyeInspector because even for 100000 elements it was not lagging. But we didn't think about the size in memory, so I guess we should put back 100 and 10. 2014-03-13 23:22 GMT+01:00 phil@highoctane.be <phil@highoctane.be>:
Looks like there is some shared fun with ZnClient and https then :-)
... on my way to ZnNinja (slowly).
Sven, HTTPComponents is really Ubercool!
Phil
On Thu, Mar 13, 2014 at 11:00 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
On Mar 13, 2014, at 6:53 PM, phil@highoctane.be wrote:
Not silly if what you do is creating a gateway that gets stuff back from a REST api and you need to figure out some parts of what you get back (and one things is a huge Base64-encoded file
that actually happened to me a couple of times, yeah
sebastian <https://about.me/sebastianconcept>
o/
On 13 Mar 2014, at 22:46, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Maybe #childrenFor[Object]: can be used to shortcut the depth of the tree. For strings characters could then no longer be shown.
Well, this does the trick, but it is getting uglier: EyeTreeInspector>>#childrenForObject: anObject anObject isString ifTrue: [ ^ #() ]. ^ anObject inspector elements reject: [ :element | (element isKindOf: SelfEyeElement) or: [ (element isKindOf: AllInstVarsEyeElement) or: [ element isKindOf: ClassEyeElement ] ] ] This gives you clean strings in the explorer/tree.
I would like to have a basic mode without class and all instvars because they get in my way. Stef
I went back to compare the explorer in 2.0, the only visible (not behaviour) difference that I see is the class field, it would probably be better to lose that:
<Screen Shot 2014-03-13 at 20.28.45.png>
<Screen Shot 2014-03-13 at 20.29.10.png>
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Where is the old motto, 'Just doit' ? With this simple change the class field is gone from the explorer: EyeTreeInspector>>#childrenForObject: anObject self flag: 'Minor Ugliness to filter out the self and instavr node'. ^ anObject inspector elements reject: [ :element | (element isKindOf: SelfEyeElement) or: [ (element isKindOf: AllInstVarsEyeElement) or: [ element isKindOf: ClassEyeElement ] ] ] But I would change that to use something like #shouldShowInTree on AbstractEyeElement (unless we do the next one too, then I think we only have to filter the self element). In the following method, you could tune the regular inspector fields, I commented out the class and allInstVars: EyeInspector>>#generateElements "generate the collection of elements to show in the inspector for the object inspected" |elements| elements := OrderedCollection new. self addSelf: elements. "self addClass: elements." "self addAllInstVars: elements." self addSpecialFields: elements. self addInstancesVariable: elements. self addVariableFields: elements. ^elements Pretty readable code if you ask me. Should I make a slice ? On 13 Mar 2014, at 20:51, Pharo4Stef <pharo4Stef@free.fr> wrote:
I would like to have a basic mode without class and all instvars because they get in my way.
Stef
I went back to compare the explorer in 2.0, the only visible (not behaviour) difference that I see is the class field, it would probably be better to lose that:
<Screen Shot 2014-03-13 at 20.28.45.png>
<Screen Shot 2014-03-13 at 20.29.10.png>
But I hate the 'all inst vars' field, who uses that and for what ??
On 13 Mar 2014, at 20:16, phil@highoctane.be wrote:
I agree with that.
I was inspecting a ZnResponse yesterday and it was very hard to see the contents etc.
A general pain. I was clicking on the "inspect" option to see what the real content was. I was cursing a lot.
Phil
On Thu, Mar 13, 2014 at 12:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Should I make a slice ?
I have grouped all my suggested solutions and then some more in https://pharo.fogbugz.com/f/cases/13076/Optimize-the-information-displayed-b... Sven
On 14 Mar 2014, at 10:13, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Should I make a slice ?
I have grouped all my suggested solutions and then some more in
https://pharo.fogbugz.com/f/cases/13076/Optimize-the-information-displayed-b... Guys, please review the slice. Sven
thanks sven.
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Should I make a slice ?
I have grouped all my suggested solutions and then some more in
https://pharo.fogbugz.com/f/cases/13076/Optimize-the-information-displayed-b...
Sven
Sean P. DeNigris wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer.
Can you try https://pharo.fogbugz.com/f/cases/13086/ cheers -ben
- It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
----- Cheers, Sean -- View this message in context: http://forum.world.st/EyeTreeInspector-not-ready-for-prime-time-tp4748966.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 13 Mar 2014, at 12:51, Sean P. DeNigris <sean@clipperadams.com> wrote:
I'm glad we're re-inventing the tools! And, I'm struggling with this tool in its current form...
As others have mentioned, the "class" pseudo-variable is confusing, but here are some that I find worse: - The receiver does not change with the selection. For me, this was a key feature of the explorer. - It does not properly update e.g. if you are inspecting a class containing a dictionary and add an item to the dictionary, collapsing and expanding the dictionary node does not show the added item. It seems you must open an entirely new inspector. - If you toggle from EyeTreeInspector to EyeInspector, your code in the bottom pane is lost
With the following two cases integrated https://pharo.fogbugz.com/f/cases/13076/Optimize-the-information-displayed-b... https://pharo.fogbugz.com/f/cases/13086/EyeTreeInspector-text-pane-doItRecei... we're up to the next two open cases https://pharo.fogbugz.com/f/cases/13090/EyeTreeInspector-should-open-with-on... https://pharo.fogbugz.com/f/cases/13091/EyeInspector-switching-should-preser... which would leave the updating issue, which has to be described. Any help appreciated ! Sven
participants (8)
-
Alexandre Bergel -
Ben Coman -
Clément Bera -
Pharo4Stef -
phil＠highoctane.be -
Sean P. DeNigris -
Sebastian Sastre -
Sven Van Caekenberghe