Hi, Thanks. Indeed, the rendering of "i" is not yet satisfying. The "i" is about inspecting which in the GT environment always spawns another inspection session - and at this moment, this maps on a new window. Appearing to the right of the playground, you do "open". I still want this to come, but the thing is that the current behavior is implemented independently of the (gt)playground, and this is why we cannot yet open. But, we will work on this. About "i" and "e", in GT there is no hardcoded explore. There exists only an inspect which leads you to object specific views. Hence, everywhere in the GT environment, you will see either "i" or the triangle for "open". Cheers, Doru On Mon, Jul 28, 2014 at 9:57 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

I tried it and I have some feedback:

I have a problem with the i : it's barely visible as a part of the print it float above and gave me the feeling that some text was added to the playground.

I also expected the inspector to appear at the right of the playground.

Why couldn't I explore the result ? (i.e. why just an i, not i and e)

Thierry

Le 28/07/2014 01:33, Tudor Girba a écrit :

Hi,

In the course of revamping the Pharo environment, we stumbled across the print it action and we (Andrei and I) decided to rethink it. [image: Inline image 1]

You can find more details here: http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo

Let us know what you think.

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

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

On Mon, Jul 28, 2014 at 9:58 PM, Chris Muller <asqueaker@gmail.com> wrote:

Maybe remapping Command+p to inspect would solve it equally? :)

This is a point worth debating (I really love when we allocate time to talk about our UI - this is the one interface that we, in this community, use every day). The goal of "Print it" serves as a quick and light readonly feedback, and I think it has a distinct place that is separate from the inspector which is a place where you interact and manipulate the object. Furthermore, in the current implementation, the "print it" is floating and non intrusive (it goes away easily) while the inspector is at the moment a lasting piece. Of course, we could imagine an inspector that could be embedded in the popper window (in fact, I have that implementation, too :)), but the problem is that in its current form, the inspector is not made to be easily scalable. This might change with the adoption of Athens. In the meantime, one direction I think we could take is to produce several scalable "printouts" that can also be visual.

Both of the example cases justifying it were that the user pressed the wrong key. UI's should not try to solve problems between the human <--> hardware interface.

I am not sure I follow. Could you elaborate please? Cheers, Doru

On Sun, Jul 27, 2014 at 6:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

In the course of revamping the Pharo environment, we stumbled across the print it action and we (Andrei and I) decided to rethink it. [image: Inline image 1]

You can find more details here: http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo

Let us know what you think.

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

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

Kind of back to the Future. Why not have a console rectangle scrollable area at the bottom of the workspace window, that can be persistent on clicking on it and gives the result of "print it" accumulating till a clear is called. Setting to clear on every run or retain text can be done. This is a bit like in Eclipse transient window on inspect but simpler and retains the printed text if reqd. On Tue, Jul 29, 2014 at 1:49 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

On Mon, Jul 28, 2014 at 9:58 PM, Chris Muller <asqueaker@gmail.com> wrote:

...

Maybe remapping Command+p to inspect would solve it equally? :)

This is a point worth debating (I really love when we allocate time to talk about our UI - this is the one interface that we, in this community, use every day).

The goal of "Print it" serves as a quick and light readonly feedback, and I think it has a distinct place that is separate from the inspector which is a place where you interact and manipulate the object. Furthermore, in the current implementation, the "print it" is floating and non intrusive (it goes away easily) while the inspector is at the moment a lasting piece.

Of course, we could imagine an inspector that could be embedded in the popper window (in fact, I have that implementation, too :)), but the problem is that in its current form, the inspector is not made to be easily scalable. This might change with the adoption of Athens.

In the meantime, one direction I think we could take is to produce several scalable "printouts" that can also be visual.

...

Both of the example cases justifying it were that the user pressed the wrong key. UI's should not try to solve problems between the human <--> hardware interface.

I am not sure I follow. Could you elaborate please?

Cheers, Doru

...

On Sun, Jul 27, 2014 at 6:33 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

In the course of revamping the Pharo environment, we stumbled across the print it action and we (Andrei and I) decided to rethink it. [image: Inline image 1]

You can find more details here: http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo

Let us know what you think.

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"