On 13 Mar 2014, at 12:51, Sean P. DeNigris s...@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
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
On 13 Mar 2014, at 23:22, p...@highoctane.be wrote:
Looks like there is some shared fun with ZnClient and https then :-)
... on my way to ZnNinja (slowly).
Sven, HTTPComponents is really Ubercool!
Phil
Thanks.
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe s...@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-by-EyeInspector-and-EyeTreeInspector
Sven
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 10 elements it was not lagging. But we
On 14 Mar 2014, at 10:13, Sven Van Caekenberghe s...@stfx.eu wrote:
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe s...@stfx.eu wrote:
Should I make a slice ?
I have grouped all my suggested solutions and then some more in
thanks sven.
On 13 Mar 2014, at 22:35, Sven Van Caekenberghe s...@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-by-EyeInspector-and-EyeTreeInspector
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
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.
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
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
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
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
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
But you have GB's of RAM, right ;-)
See EyeInspector#limit1 and limit2 that control how much to show in
collections, maybe 10 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
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
On 13 Mar 2014, at 22:46, Sven Van Caekenberghe s...@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:
On Mar 13, 2014, at 6:53 PM, p...@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,
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: [
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
sebast...@flowingconcept.com wrote:
On Mar 13, 2014, at 6:53 PM, p...@highoctane.be wrote:
20 matches
Mail list logo
