Hi, What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss. Doru On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <bera.clement@gmail.com> wrote:

Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>:

...

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com "Every thing has its own flow"

2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

On 23 Dec 2014, at 19:13, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss.

What took you so long, Doru ? Haha ;-)

Seriously, I think that the 'Raw' tab of GT-Inspector actually covers the key old inspector *and* inspector behaviour quite well. I guess that was/is also the design goal.

No it covers only part of it. See below.

The rest is mostly a reaction to something new and unfamiliar. GT takes some getting used to.

But we need concrete use cases that give people trouble to be able to improve.

My use case is simple, I have variable objects such as Context or BlockClosure, and when I inspect them I cannot see their variable fields with GTInspector. The old basicInspector allows me to see these fields. Example: | t | t := 1. [ t ] inspect GT visualisation: [image: Images intégrées 1] Old visualisation: [image: Images intégrées 2] In the old visualisation I could see the 1 with its value. Same problem with contexts. In the old basicInspector I could see all the stack fields, I can't see them anymore. Example: [image: Images intégrées 3] [image: Images intégrées 4] Therefore I need the old inspector to inspect Context and BlockClosure. I talk about Context and BlockClosure because they are the most annoying in my workflows, but the problem is more generic. GTInspector does not automatically detect the object's layout, on the contrary to the old inspector. Therefore when I do: Object variableSubclass: #MyVariableObject instanceVariableNames: '' classVariableNames: '' category: 'Banana' (MyVariableObject new: 3) inspect => I can't see any of the fields. Same issue with variableByteSubclass and co. And Context and BlockClosure falls into this category of objects (they're variableSubclasses). To me a basicInspector is an inspector that allows you to see the ALL the internal state of an object without hiding or changing the names of fields, and I do not have that (right now) with GTInspector on the contrary to the old inspectors. Note: don't mistake me, I use GTInspector for most of my daily work, I like it and it improved my productivity. There are just a few cases that do not work where I need to switch to the old inspector, mostly the ones I've just described. In addition, a visualization of tempName -> tempValue for inspectors on context is missing but that's a detail.

Doru

...

On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <bera.clement@gmail.com>

wrote:

...

Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>: Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

Hi Clement, Thanks for the detailed feedback. This is useful. Btw, did you try to extend this view yourself? It would actually be more useful to come from you given that you know what you want to see and then we iterate. Here is a starting point: http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect... If not, then could you advise me as to how to get the internal state independent of the layout? Cheers, Doru On Tue, Dec 23, 2014 at 8:09 PM, Clément Bera <bera.clement@gmail.com> wrote:

2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

...

On 23 Dec 2014, at 19:13, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss.

What took you so long, Doru ? Haha ;-)

Seriously, I think that the 'Raw' tab of GT-Inspector actually covers the key old inspector *and* inspector behaviour quite well. I guess that was/is also the design goal.

No it covers only part of it. See below.

...

The rest is mostly a reaction to something new and unfamiliar. GT takes some getting used to.

But we need concrete use cases that give people trouble to be able to improve.

My use case is simple, I have variable objects such as Context or BlockClosure, and when I inspect them I cannot see their variable fields with GTInspector. The old basicInspector allows me to see these fields.

Example:

| t | t := 1. [ t ] inspect

GT visualisation:

[image: Images intégrées 1]

Old visualisation:

[image: Images intégrées 2]

In the old visualisation I could see the 1 with its value.

Same problem with contexts. In the old basicInspector I could see all the stack fields, I can't see them anymore.

Example:

[image: Images intégrées 3]

[image: Images intégrées 4]

Therefore I need the old inspector to inspect Context and BlockClosure. I talk about Context and BlockClosure because they are the most annoying in my workflows, but the problem is more generic. GTInspector does not automatically detect the object's layout, on the contrary to the old inspector. Therefore when I do:

Object variableSubclass: #MyVariableObject instanceVariableNames: '' classVariableNames: '' category: 'Banana'

(MyVariableObject new: 3) inspect

=> I can't see any of the fields.

Same issue with variableByteSubclass and co. And Context and BlockClosure falls into this category of objects (they're variableSubclasses).

To me a basicInspector is an inspector that allows you to see the ALL the internal state of an object without hiding or changing the names of fields, and I do not have that (right now) with GTInspector on the contrary to the old inspectors.

Note: don't mistake me, I use GTInspector for most of my daily work, I like it and it improved my productivity. There are just a few cases that do not work where I need to switch to the old inspector, mostly the ones I've just described.

In addition, a visualization of tempName -> tempValue for inspectors on context is missing but that's a detail.

...

Doru

...

On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <bera.clement@gmail.com>

wrote:

...

Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>: Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Hi Clément, Thanks for the extra pointers. I tried to dig a little and I now added dynamic variables into the Raw view. Take a look at the latest version (GT-Inspector-TudorGirba.277) and let me know if it fits your needs. Cheers, Doru On Wed, Dec 24, 2014 at 12:22 AM, Clément Bera <bera.clement@gmail.com> wrote:

On Dec 23, 2014 9:36 PM, "Tudor Girba" <tudor@tudorgirba.com> wrote:

...

Hi Clement,

Thanks for the detailed feedback. This is useful. Btw, did you try to extend this view yourself?

Well I added other views (mostly roassal views) but not this one.

...

It would actually be more useful to come from you given that you know what you want to see and then we iterate. Here is a starting point:

http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect...

If not, then could you advise me as to how to get the internal state independent of the layout?

I think the issue is that #gtInspectorItemsIn: is in Collection whereas it should be on all objects that answers true to: "object class layout isVariable".

One needs to check this method works on all variable objects (WordArray, ByteArray, CompiledMethod and WeakArray).

But I don't know how to change that in gtInspector.

...

Cheers, Doru

On Tue, Dec 23, 2014 at 8:09 PM, Clément Bera <bera.clement@gmail.com> wrote:

...

2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

...

On 23 Dec 2014, at 19:13, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss.

What took you so long, Doru ? Haha ;-)

Seriously, I think that the 'Raw' tab of GT-Inspector actually covers the key old inspector *and* inspector behaviour quite well. I guess that was/is also the design goal.

No it covers only part of it. See below.

...

The rest is mostly a reaction to something new and unfamiliar. GT takes some getting used to.

But we need concrete use cases that give people trouble to be able to improve.

My use case is simple, I have variable objects such as Context or BlockClosure, and when I inspect them I cannot see their variable fields with GTInspector. The old basicInspector allows me to see these fields.

Example:

| t | t := 1. [ t ] inspect

GT visualisation:

[image: Images intégrées 1]

Old visualisation:

[image: Images intégrées 2]

In the old visualisation I could see the 1 with its value.

Same problem with contexts. In the old basicInspector I could see all the stack fields, I can't see them anymore.

Example:

[image: Images intégrées 3]

[image: Images intégrées 4]

Therefore I need the old inspector to inspect Context and BlockClosure. I talk about Context and BlockClosure because they are the most annoying in my workflows, but the problem is more generic. GTInspector does not automatically detect the object's layout, on the contrary to the old inspector. Therefore when I do:

Object variableSubclass: #MyVariableObject instanceVariableNames: '' classVariableNames: '' category: 'Banana'

(MyVariableObject new: 3) inspect

=> I can't see any of the fields.

Same issue with variableByteSubclass and co. And Context and BlockClosure falls into this category of objects (they're variableSubclasses).

To me a basicInspector is an inspector that allows you to see the ALL the internal state of an object without hiding or changing the names of fields, and I do not have that (right now) with GTInspector on the contrary to the old inspectors.

Note: don't mistake me, I use GTInspector for most of my daily work, I like it and it improved my productivity. There are just a few cases that do not work where I need to switch to the old inspector, mostly the ones I've just described.

In addition, a visualization of tempName -> tempValue for inspectors on context is missing but that's a detail.

...

Doru

...

On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <bera.clement@gmail.com>

wrote:

...

Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>: Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Hi Clément, Thanks for reviewing. I'm glad it fits your needs. Indeed, my implementation is naive and was intended to enable quick review. We will iterate over it. Cheers, Doru On Thu, Jan 1, 2015 at 10:52 AM, Clément Bera <bera.clement@gmail.com> wrote:

Hello Doru,

Yes this works for me.

There are still little details like when you inspect an object with instance variable and variable fields, the variable fields are shown before the instance variables as 01 is before any string in alphabetical order but that's minor.

Thank you very much. I won't have to switch anymore to the old inspector for closures and contexts.

Best,

Clement

2015-01-01 9:57 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

...

Hi Clément,

Thanks for the extra pointers. I tried to dig a little and I now added dynamic variables into the Raw view.

Take a look at the latest version (GT-Inspector-TudorGirba.277) and let me know if it fits your needs.

Cheers, Doru

On Wed, Dec 24, 2014 at 12:22 AM, Clément Bera <bera.clement@gmail.com> wrote:

...

On Dec 23, 2014 9:36 PM, "Tudor Girba" <tudor@tudorgirba.com> wrote:

...

Hi Clement,

Thanks for the detailed feedback. This is useful. Btw, did you try to extend this view yourself?

Well I added other views (mostly roassal views) but not this one.

...

It would actually be more useful to come from you given that you know what you want to see and then we iterate. Here is a starting point:

http://www.humane-assessment.com/blog/extending-variables-shown-in-gtinspect...

If not, then could you advise me as to how to get the internal state independent of the layout?

I think the issue is that #gtInspectorItemsIn: is in Collection whereas it should be on all objects that answers true to: "object class layout isVariable".

One needs to check this method works on all variable objects (WordArray, ByteArray, CompiledMethod and WeakArray).

But I don't know how to change that in gtInspector.

...

Cheers, Doru

On Tue, Dec 23, 2014 at 8:09 PM, Clément Bera <bera.clement@gmail.com> wrote:

...

2014-12-23 19:37 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

...

On 23 Dec 2014, at 19:13, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss.

What took you so long, Doru ? Haha ;-)

Seriously, I think that the 'Raw' tab of GT-Inspector actually covers the key old inspector *and* inspector behaviour quite well. I guess that was/is also the design goal.

No it covers only part of it. See below.

...

The rest is mostly a reaction to something new and unfamiliar. GT takes some getting used to.

But we need concrete use cases that give people trouble to be able to improve.

My use case is simple, I have variable objects such as Context or BlockClosure, and when I inspect them I cannot see their variable fields with GTInspector. The old basicInspector allows me to see these fields.

Example:

| t | t := 1. [ t ] inspect

GT visualisation:

[image: Images intégrées 1]

Old visualisation:

[image: Images intégrées 2]

In the old visualisation I could see the 1 with its value.

Same problem with contexts. In the old basicInspector I could see all the stack fields, I can't see them anymore.

Example:

[image: Images intégrées 3]

[image: Images intégrées 4]

Therefore I need the old inspector to inspect Context and BlockClosure. I talk about Context and BlockClosure because they are the most annoying in my workflows, but the problem is more generic. GTInspector does not automatically detect the object's layout, on the contrary to the old inspector. Therefore when I do:

Object variableSubclass: #MyVariableObject instanceVariableNames: '' classVariableNames: '' category: 'Banana'

(MyVariableObject new: 3) inspect

=> I can't see any of the fields.

Same issue with variableByteSubclass and co. And Context and BlockClosure falls into this category of objects (they're variableSubclasses).

To me a basicInspector is an inspector that allows you to see the ALL the internal state of an object without hiding or changing the names of fields, and I do not have that (right now) with GTInspector on the contrary to the old inspectors.

Note: don't mistake me, I use GTInspector for most of my daily work, I like it and it improved my productivity. There are just a few cases that do not work where I need to switch to the old inspector, mostly the ones I've just described.

In addition, a visualization of tempName -> tempValue for inspectors on context is missing but that's a detail.

...

Doru

...

On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <

bera.clement@gmail.com> wrote:

...

Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>: Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Sven Van Caekenberghe wrote:

...

On 23 Dec 2014, at 19:13, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

What does a basic inspector mean for you? It's not a rhetorical question. I am actually interested in what you miss.

What took you so long, Doru ? Haha ;-)

Seriously, I think that the 'Raw' tab of GT-Inspector actually covers the key old inspector *and* inspector behaviour quite well. I guess that was/is also the design goal.

The rest is mostly a reaction to something new and unfamiliar. GT takes some getting used to.

But we need concrete use cases that give people trouble to be able to improve.

I miss the Tree View - being able to drill down in a _compact_ way. Could that be a tab of its own? I actually think this "might" have great potential - being able to navigate in both a vertical and horizontal direction - allowing you to skip some levels between opening a new pane horizontally. cheers -ben

...

Doru

On Tue, Dec 23, 2014 at 6:06 PM, Clément Bera <bera.clement@gmail.com> wrote: Yes.

World Menu >> Settings >> Glamourous toolkit

then you can uncheck GTInspector and GTPlayground.

I also need to do that very often as GTInspector does not have a basic inspector.

2014-12-23 11:50 GMT+01:00 Norbert Hartl <norbert@hartl.name>: Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

2014-12-23 22:46 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

The Raw view is a tree :)

Doru

It would be good if "self", in the bottom panel, is bound to the current selected item in the tree. And a "compact" tree view does not need to create a new pane to the right. ( I am still unfamilliar with the behavior: select an element and the whole tab scrolls to the left. For example, If you have more than one tab and you want to select an item in the right most tab for opening a new inspector on that item, the pane with the selected item scrolls away). nicolai

On Tue, Dec 23, 2014 at 10:44 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote: I miss the Tree View - being able to drill down in a _compact_ way. Could that be a tab of its own? I actually think this "might" have great potential - being able to navigate in both a vertical and horizontal direction - allowing you to skip some levels between opening a new pane horizontally.

cheers -ben

Tudor Girba wrote:

The Raw view is a tree :)

Doru

It works differently. See attached for example in both tools of... Smalltalk inspect. So I'll be more specific :) - I miss EyeTreeInspector form of tree view. btw, Congrats on getting Moose 5 out the door, for all the cool tools recently contributed to Pharo. cheers -ben cheers -ben

Hi Norbert, My reply is inlined. On Wed, Dec 24, 2014 at 5:15 PM, Norbert Hartl <norbert@hartl.name> wrote:

Am 23.12.2014 um 22:46 schrieb Tudor Girba <tudor@tudorgirba.com>:

The Raw view is a tree :)

It looks like shallow tree :) Maybe I miss the point but my appearance to this is something like that. Let's have a class

Object subclass: #TTT instanceVariableNames: 'col' classVariableNames: '' category: 'ZZZ'

and

TTT>>#initialize col := OrderedCollection new addAll: (1 to: 10); yourself

If I inspect "TTT new" I get

With the intention to examine the elements of the collection I unfold (1) the col

So instead of the elements I get the internal representation of OrderedCollection. Clicking array (2)

I get a new column with the representation of array (same as on the left side). And here Clement is right because it would be helpful to see the elements in the right column. By clicking the "10 items" tab (3) and then an element (4) I can see the content of that. So what I wanted to say is that I found it a lot of clicks necessary to get the information I want. I see it is a raw view and from that POV everything seems right.

The tree interface works only for a few elements in a collection, but it will fail for most real collections because it does not scale (you will have a hard time finding anything). Nevertheless, here is a simplistic solution (it will have to be extended a bit). Adding this method: Collection>>gtInspectorVariableValuePairs | pairs | pairs := super gtInspectorVariableValuePairs. self doWithIndex: [ :each :index | index > 42 ifTrue: [ ^ pairs ]. pairs add: (index asTwoCharacterString -> each) ]. ^ pairs [image: Inline image 1] In my opinion this makes the Raw view less "Raw". Coming from the old tools it is not a point of getting used to it or not.

This raw view is not an improvement over the old it is a completely different view.

As Ben sad it might good to think about providing a view compatible with

the old explorer view (fast drill down). Having that view be a default could be left to the user as it could be a setting.

Does that makes sense?

Your comparison is correct: the current Raw view does provide less than the old one. However, the raw view used to be the inspector, but now it is but one of the views in the inspector and it was not meant to replace or improve the old one. The inspector as a whole does want to improve on the old one, and I think this is where we should focus our comparisons on :). Nevertheless, let me know what you think about the extension proposed above. But, here is the other thing that the new inspector allows for. In the TTT class you can now add something like: TTT>>gtInspectorItemsIn: composite <gtInspectorPresentationOrder: 0> composite list title: 'Col'; display: [ col ] This is about as cheap as a printOn: and you get: [image: Inline image 2] You might say that you do not want to stop your inspection to do this, but actually you should not stop. You can write this method directly in the Meta tab and the inspector updates live and you can continue from where you left off with a tiny detour. Norbert

P.S.: Are the miller columns configurable. I want to play with amount of columns. Until now I preferred three columns if space is available. Any pointers to that would be great.

There are two things: 1. There is a setting to set the default amount of panes. 2. The columns are adjustable dynamically by resizing the scrollbar at the bottom. Cheers, Doru

Hi Norbert, Great. Please play with the extension and let us know how it goes. Cheers, Doru On Fri, Dec 26, 2014 at 3:31 PM, Norbert Hartl <norbert@hartl.name> wrote:

Doru,

Am 26.12.2014 um 14:38 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi Norbert,

My reply is inlined.

dito

On Wed, Dec 24, 2014 at 5:15 PM, Norbert Hartl <norbert@hartl.name> wrote:

...

Am 23.12.2014 um 22:46 schrieb Tudor Girba <tudor@tudorgirba.com>:

The Raw view is a tree :)

It looks like shallow tree :) Maybe I miss the point but my appearance to this is something like that. Let's have a class

Object subclass: #TTT instanceVariableNames: 'col' classVariableNames: '' category: 'ZZZ'

and

TTT>>#initialize col := OrderedCollection new addAll: (1 to: 10); yourself

If I inspect "TTT new" I get

With the intention to examine the elements of the collection I unfold (1) the col

So instead of the elements I get the internal representation of OrderedCollection. Clicking array (2)

I get a new column with the representation of array (same as on the left side). And here Clement is right because it would be helpful to see the elements in the right column. By clicking the "10 items" tab (3) and then an element (4) I can see the content of that. So what I wanted to say is that I found it a lot of clicks necessary to get the information I want. I see it is a raw view and from that POV everything seems right.

The tree interface works only for a few elements in a collection, but it will fail for most real collections because it does not scale (you will have a hard time finding anything).

Nevertheless, here is a simplistic solution (it will have to be extended a bit). Adding this method:

Collection>>gtInspectorVariableValuePairs | pairs | pairs := super gtInspectorVariableValuePairs. self doWithIndex: [ :each :index | index > 42 ifTrue: [ ^ pairs ]. pairs add: (index asTwoCharacterString -> each) ]. ^ pairs

<collection-items-in-raw.png>

In my opinion this makes the Raw view less "Raw".

Sure. I didn't mean to change the raw view because taken its name it is perfectly doing what it promises. It's just that in most of the cases I'm not really interested in a raw view but customized views that help examine/navigating (which is the point of having gt inspector in the first place, right?). Thanks for the code snippet. I'll take that as an entry point to play with it. Would have taken me some time to get that.

Coming from the old tools it is not a point of getting used to it or not.

...

This raw view is not an improvement over the old it is a completely different view.

As Ben sad it might good to think about providing a view compatible with

...

the old explorer view (fast drill down). Having that view be a default could be left to the user as it could be a setting.

Does that makes sense?

...

Your comparison is correct: the current Raw view does provide less than the old one. However, the raw view used to be the inspector, but now it is but one of the views in the inspector and it was not meant to replace or improve the old one. The inspector as a whole does want to improve on the old one, and I think this is where we should focus our comparisons on :). Nevertheless, let me know what you think about the extension proposed above.

But, here is the other thing that the new inspector allows for. In the TTT class you can now add something like:

TTT>>gtInspectorItemsIn: composite <gtInspectorPresentationOrder: 0> composite list title: 'Col'; display: [ col ]

This is about as cheap as a printOn: and you get:

<inspector-custom-col.png>

That's really good. I'm sure I gonna love it soon.

You might say that you do not want to stop your inspection to do this, but actually you should not stop. You can write this method directly in the Meta tab and the inspector updates live and you can continue from where you left off with a tiny detour.

Norbert

...

P.S.: Are the miller columns configurable. I want to play with amount of columns. Until now I preferred three columns if space is available. Any pointers to that would be great.

There are two things: 1. There is a setting to set the default amount of panes. 2. The columns are adjustable dynamically by resizing the scrollbar at the bottom.

Ok, I'll try all of that and then I return to 4.0. Thanks for the help!

Norbert

-- www.tudorgirba.com "Every thing has its own flow"

Hi, I think there must be a misunderstanding. There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. Cheers, Doru On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote:

I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

...

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com "Every thing has its own flow"

Hi Norbert, I must be missing something obvious, but fail to see how you are forced to extend the inspector. I think the inspector in 4.0 comes out of the box with many more capabilities than the one in 3.0. Even if there were things to improve, and I will reply soon to the other mail with a concrete solution, there seems to be no real issue in your specific case given that you could without any problems describing how to get to the item number "3" of the collection (which seemed to be the problem in the first place). Am I missing something? Cheers, Doru On Fri, Dec 26, 2014 at 1:40 PM, Norbert Hartl <norbert@hartl.name> wrote:

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote:

...

I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

...

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Am 26.12.2014 um 14:04 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi Norbert,

I must be missing something obvious, but fail to see how you are forced to extend the inspector. I think the inspector in 4.0 comes out of the box with many more capabilities than the one in 3.0.

Even if there were things to improve, and I will reply soon to the other mail with a concrete solution, there seems to be no real issue in your specific case given that you could without any problems describing how to get to the item number "3" of the collection (which seemed to be the problem in the first place). Am I missing something?

There are two kind of problems. One is if something is not working/possible. The other is if it is too cumbersome to achieve something. From user point of view both problems are really close if not equal. Probably I need to rephrase my first mail. I was opting for having an alternative view than the raw view which is more like the old inspector and making it possible to have it as a default. Norbert

Cheers, Doru

On Fri, Dec 26, 2014 at 1:40 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

On 26 Dec 2014, at 17:42, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

OK, I understand, but how is this different from any other radical changes that we did ? When we introduced the Eye inspectors we did not offer two options at the same time (and I can give 10s of examples). So what is best, we all together use and make the best tools, or we all work with different tools ?

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

Hi Kilon, Your premise is incorrect. Since two months we are gathering feedback and actively incorporating it in the tools. Quite some changes happened exactly because of this exercise, and they will continue to happen. Tools do get redesigned when there are enough arguments. You do not have to "suck it up". I have no interest in building something for my own needs only. I can do that by myself without going through all the trouble of asking people. We need to make explicit what does not work and the design emerges out of that. Your points of view matter. Your opinions will not be blindly incorporated and the final decision remains with the team that builds these tools, but the majority of times the design was agreed by everyone. This can work. I understand that it can be slightly inconvenient at times, but we want to get far fast, and for that we need everyone's help at least as feedback. If we keep the other tools around, the incentive to fall back on the existing habit is too great and feedback does not happen. Please put a bit more trust in us and we'll try to live up to your expectations. Cheers, Doru On Fri, Dec 26, 2014 at 7:40 PM, kilon alios <kilon.alios@gmail.com> wrote:

Why cant be both ? Why it has to be black and white ? What if we , I, someone does not like the design of a tool at a fundamental level ?

If you dont like a tool then you dont like a tool, its not as if the tool itself will be redesigned to fit your own needs . You have two choices a) suck it up and compromise with what you have b) suck it up go through the pain / pleasure of creating your own solution. One thing I learned with coding is that for other codes its usually "use the right tool for the right job" but for me is "the right tools for the right coder".

"Personal Preferences" is the name of the game. Plus I disagree that without variation of effort we can have high quality tools. Take a look at the software landscape , there is extremely variation out there, why you think Pharo is immune to that ?

On Fri, Dec 26, 2014 at 8:14 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

...

On 26 Dec 2014, at 17:42, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

OK, I understand, but how is this different from any other radical changes that we did ?

When we introduced the Eye inspectors we did not offer two options at the same time (and I can give 10s of examples). So what is best, we all together use and make the best tools, or we all work with different tools ?

...

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

One thing that upset me is the recursive opening of the same view again and again for example when you do something like 'foo' inspect, with the raw view self | 'foo' You must then learn to not click self, what use to this? There should be dead ends, when you can't go any deeper, you can't... 2014-12-26 21:56 GMT+01:00 kilon alios <kilon.alios@gmail.com>:

I have acknowledge the fact that after I mentioned things I missed from old workspace you were quick to integrate them back to Playground (copy, paste, implementors, senders etc). You dont understand my premise. My premise that in the end a tool can only satisfy some people but not all of them. To deny that is to deny the fabric of our reality. So my belief is that the answer to the question that Sven asked and I was replying it to ". So what is best, we all together use and make the best tools, or we all work with different tools ?" is "both". We as a community help GT tools evolve with our contributions (certainly I would love to contribute at some point too) and this is definitely the start of a long term evolution but also on the other hand individual of groups of pharo coder may create their own tools to fill the gaps and satisfy needs the existing tools do not .

Afterall one does not bother to use a fairly unpopular language / IDE that is easy to hack if he does not intend to at least do some hacking with it. The ease of building custom IDE tools with Pharo is what makes Pharo so much fun.

On Fri, Dec 26, 2014 at 10:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi Kilon,

Your premise is incorrect. Since two months we are gathering feedback and actively incorporating it in the tools. Quite some changes happened exactly because of this exercise, and they will continue to happen. Tools do get redesigned when there are enough arguments.

You do not have to "suck it up". I have no interest in building something for my own needs only. I can do that by myself without going through all the trouble of asking people.

We need to make explicit what does not work and the design emerges out of that. Your points of view matter. Your opinions will not be blindly incorporated and the final decision remains with the team that builds these tools, but the majority of times the design was agreed by everyone. This can work.

I understand that it can be slightly inconvenient at times, but we want to get far fast, and for that we need everyone's help at least as feedback. If we keep the other tools around, the incentive to fall back on the existing habit is too great and feedback does not happen. Please put a bit more trust in us and we'll try to live up to your expectations.

Cheers, Doru

On Fri, Dec 26, 2014 at 7:40 PM, kilon alios <kilon.alios@gmail.com> wrote:

...

Why cant be both ? Why it has to be black and white ? What if we , I, someone does not like the design of a tool at a fundamental level ?

If you dont like a tool then you dont like a tool, its not as if the tool itself will be redesigned to fit your own needs . You have two choices a) suck it up and compromise with what you have b) suck it up go through the pain / pleasure of creating your own solution. One thing I learned with coding is that for other codes its usually "use the right tool for the right job" but for me is "the right tools for the right coder".

"Personal Preferences" is the name of the game. Plus I disagree that without variation of effort we can have high quality tools. Take a look at the software landscape , there is extremely variation out there, why you think Pharo is immune to that ?

On Fri, Dec 26, 2014 at 8:14 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

...

On 26 Dec 2014, at 17:42, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

OK, I understand, but how is this different from any other radical changes that we did ?

When we introduced the Eye inspectors we did not offer two options at the same time (and I can give 10s of examples). So what is best, we all together use and make the best tools, or we all work with different tools ?

...

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

Kilon, You are right that tools will not satisfy "everyone" but I think Doru's point is we want the default tools to satisfy the majority. However the tool is new and there are _some_ gaps that _can_ be filled if people push the use case, so they want people to push back (even if sometimes it tends towards complaining). Now I wonder if the old inspector could somehow be embedded as a tab in GTInspector. Then rather than the Preference turning GTInspector off, it just changes the default view to the old inspector. So those people feeling the need for the old inspector still get exposed to GTInspector and become familiar with it in a progressive way. Doru, As I understand it, each tab is matched to a method definition on the object. So what about enhancing the explorability of the definitions for the existing tabs. Like a right click on the tab to open the definition for that tab. cheers -ben On Sat, Dec 27, 2014 at 4:56 AM, kilon alios <kilon.alios@gmail.com> wrote:

I have acknowledge the fact that after I mentioned things I missed from old workspace you were quick to integrate them back to Playground (copy, paste, implementors, senders etc). You dont understand my premise. My premise that in the end a tool can only satisfy some people but not all of them. To deny that is to deny the fabric of our reality. So my belief is that the answer to the question that Sven asked and I was replying it to ". So what is best, we all together use and make the best tools, or we all work with different tools ?" is "both". We as a community help GT te familiar with it in a progressive way.ools evolve with our contributions (certainly I would love to contribute at some point too) and this is definitely the start of a long term evolution but also on the other hand individual of groups of pharo coder may create their own tools to fill the gaps and satisfy needs the existing tools do not .

Afterall one does not bother to use a fairly unpopular language / IDE that is easy to hack if he does not intend to at least do some hacking with it. The ease of building custom IDE tools with Pharo is what makes Pharo so much fun.

On Fri, Dec 26, 2014 at 10:13 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi Kilon,

Your premise is incorrect. Since two months we are gathering feedback and actively incorporating it in the tools. Quite some changes happened exactly because of this exercise, and they will continue to happen. Tools do get redesigned when there are enough arguments.

You do not have to "suck it up". I have no interest in building something for my own needs only. I can do that by myself without going through all the trouble of asking people.

We need to make explicit what does not work and the design emerges out of that. Your points of view matter. Your opinions will not be blindly incorporated and the final decision remains with the team that builds these tools, but the majority of times the design was agreed by everyone. This can work.

I understand that it can be slightly inconvenient at times, but we want to get far fast, and for that we need everyone's help at least as feedback. If we keep the other tools around, the incentive to fall back on the existing habit is too great and feedback does not happen. Please put a bit more trust in us and we'll try to live up to your expectations.

Cheers, Doru

On Fri, Dec 26, 2014 at 7:40 PM, kilon alios <kilon.alios@gmail.com> wrote:

...

Why cant be both ? Why it has to be black and white ? What if we , I, someone does not like the design of a tool at a fundamental level ?

If you dont like a tool then you dont like a tool, its not as if the tool itself will be redesigned to fit your own needs . You have two choices a) suck it up and compromise with what you have b) suck it up go through the pain / pleasure of creating your own solution. One thing I learned with coding is that for other codes its usually "use the right tool for the right job" but for me is "the right tools for the right coder".

"Personal Preferences" is the name of the game. Plus I disagree that without variation of effort we can have high quality tools. Take a look at the software landscape , there is extremely variation out there, why you think Pharo is immune to that ?

On Fri, Dec 26, 2014 at 8:14 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

...

On 26 Dec 2014, at 17:42, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

OK, I understand, but how is this different from any other radical changes that we did ?

When we introduced the Eye inspectors we did not offer two options at the same time (and I can give 10s of examples). So what is best, we all together use and make the best tools, or we all work with different tools ?

...

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

+1 Remember that “old” also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule)

On Dec 26, 2014, at 2:42 PM, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity. In any case, sure, I can take notes on usability and share it with you. As a start and concrete example take anything that now requires one extra click or keystroke that before was not.

On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi Sebastian,

I really do not see how your reply applies to the case at hand.

If you have a concrete remark regarding how something is less useful now, please feel free to make it.

Cheers, Doru

On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: +1

Remember that “old” also means that it stands the test of time

We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology.

Make productivity go up, never down!

One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before.

UX is King.

No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule)

...

On Dec 26, 2014, at 2:42 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

Stef

...

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

...

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

On Jan 5, 2015, at 12:59 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 05 Jan 2015, at 15:31, Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:

since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that.

For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity.

In any case, sure, I can take notes on usability and share it with you.

As a start and concrete example take anything that now requires one extra click or keystroke that before was not.

Doru is anything but defensive. He literally asks for concrete examples. The goal is to make the workflow better for everyone.

I saw that, he doesn’t even need your defence :) I was reminding that to all of us because I want to see us doing more great work :)

Hi Sebastian, As I said, I do not see how your generic advice applies to the current situation. We went through concrete cases exactly to elucidate how people perceived the problems. If things would be as obvious as removing a click, we would not have this conversation, but it is not. That is why we have to talk about concrete scenarios. In the meantime, I addressed the two points raised in the thread: - adding dynamic variables to the Raw view, and - adding collection items in the Raw view. I will follow up with more details in the following days. Cheers, Doru On Mon, Jan 5, 2015 at 3:31 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

since you’re working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that.

For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and that’s the road to mediocrity.

In any case, sure, I can take notes on usability and share it with you.

As a start and concrete example take anything that now requires one extra click or keystroke that before was not.

On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi Sebastian,

I really do not see how your reply applies to the case at hand.

If you have a concrete remark regarding how something is less useful now, please feel free to make it.

Cheers, Doru

On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

...

+1

Remember that “old” also means that it *stands the test of time*

We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology.

Make productivity go up, never down!

One additional click doesn’t sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didn’t have before.

UX is King.

No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule)

On Dec 26, 2014, at 2:42 PM, stepharo <stepharo@free.fr> wrote:

+ 10000

Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. Let people decide!!!

Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge.

Stef

Doru,

I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0.

So I think the only possibility is to "offer" a new way of doing things and give people time to adjust.

Norbert

Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote:

...

I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

...

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Yes, we did not have this choice problem when the eye inspectors were introduced. I am against going along two paths. GT's main goal is easy customisation, we (together) must find ways to make this the best inspector possible, and that can only happen by actually using it. Everyone who is not happy should continue to voice their opinion. The discussion should be constructive and informed - which also means that everyone should give the new tools a fair chance. And I fully agree with the 'emergency inspector' idea.

On 26 Dec 2014, at 13:18, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo@free.fr> wrote: I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert

-- www.tudorgirba.com

"Every thing has its own flow"

On Fri, Dec 26, 2014 at 8:18 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool.

I am guilty :) I try now to think why this is and the word that seems most appropriate is "inertia". By that I mean, at times previous I think you've published some tutorials, but I've had too many things on my plate to check it out - then when it comes to needing something, it takes time to find the tutorial, so I push on working aroud it. Poor habit maybe.... but there you go :) Alternatively, sometimes I've done a tutorial a long time before I have an actual need for it, and by the time I need to use it, I've forgotten and can't find the reference. The best time for a tutorial is when you need to use it. I wonder if there could be a button that linked to a ProfStef type tutorial that described how to customise it. Perhaps a help button that flashes once in a new image - just to draw the eye to investigate it. Then at the time I want/need to do it, its there in the image, with the least friction to learning what I need to know at the time I need to do it. Now sorry I'm on a new computer for the xmas season and I'm having a problem getting PharoLauncher up an running** to check what I've said against what is currently shown on the tool. cheers -ben **see other thread. I will try to work on a tutorial to see if it gets better, but do you find

the moldability proposition not valuable or just unclear?

2014-12-26 13:18 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

I think there must be a misunderstanding.

There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use.

There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore.

What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear?

I think this is pretty clear and we have already many examples on how to extend the inspector (marcus made some great addition for the compiled method view (source code / bytecde / block scope trees) I don't think "inspector as a black box tool" is the problem, eye inspector has this possibility and there were already some "special" views used. But sometimes I just want one tool to inspect or explore an object, without multiple scrolling pages, maybe I am just used to it.

But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger.

Cheers, Doru

yes yes yes! Le 25 déc. 2014 11:43, "stepharo" <stepharo@free.fr> a écrit :

I will add basicInspect in Object so that we can get access to the old inspector. I like that people can choose their tools! I mentioned that 20 times but people do not care apparently.

Stef

Le 23/12/14 11:50, Norbert Hartl a écrit :

...

Is there a way to get the old tools via shortcut?

I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools.

Norbert