Hi,

This was a long mail :). I tried to address your points below.

On Mon, Dec 8, 2014 at 10:55 AM, Torsten Bergmann <astares@gmx.de> wrote:

I would go the opposite direction and rename the "Playground" window to
"Workspace".

Several reasons:

�� 1. "Playground" reminds me too much on toyish things (and we had too much of this
�� in the past already, thats why Pharo was forked). The windows intention is to be
�� used for both: prototyping and serious stuff.

Yes, I agree that it is where work can happen. But, it is not the only place where work happens: the debugger or the code is also where work happens :). This is why I find the workspace term misleading. And Playground would match so well the marketing term of "playing with live objects". You might say that Playground is not the only place where people can play with objects, but��

�� 2. "Workspace" depicts the area where you usually work and this term is IMHO much much
�� better suited. It is also a common concept known not only in Smalltalk but also
�� other IDE's.

Not all. Swift calls it Playground (yes, they copied us ;))

�� 3. I do not understand where the significant shift is (that justifies a new name) as
�� we had similar tools already in the past. Basically it is a script space merged with
�� an inspector, so more an evolution instead of a revolution.

�� (This does not mean that I'm not happy that the GT tools are now in and provide
�� such an easy to use extensibility!)

You are looking at it from a technical point of view. Yes, it's just a merge of two features, but it is the end experience that is so much different. That is why I think we have conceptually a different solution than we ever had.

��

�� 3. There is a "Workspace open" but no "Playground open" possibility.

I think I do not get this point. What do you mean?

��

�� 4. Having two separate tools "Workspace" and "Playground" with nearly similar
�� goals (write scripts and inspect objects) would be confusing for newbees.

Maybe we could set up a "community voting" somewhere.

Perhaps.

��

Other things I would like to see:
=================================
�� A. Change to "double clicking" behavior instead of "single clicking" when diving
�� deeper into the iVars of objects.

�� This would allow to use it as a normal inspector first without having
�� directly more and more panes opening to the right.

�� Anytime I start with a script in the initial code pane it is moving away
�� when using "Do it and go" and clicking on my objects iVars in the right
�� list view.

�� With a "double click" the user could decide hisself if he just wants to select
�� (single click to do any other menu item action) or dive deeper into the
�� object (double click).

The double click is not a good solution because it would interfere with several use cases. One of them is the ability to go through a list and see the preview to the right. If you would have to double-click or press Enter to get the preview, it would be too hard. I am considering though to allow a pseudo-mode and trigger the selection only when Cmd is pressed, but that is tricky because it can conflict with multiple selections. Another thing we consider is to freeze the first pane. This will likely solve most problems.

�� B. Possibility to have splitters between the opened panes because sometimes the
�� area is not wide enough.

This is hard to do because having full panes visible at all times (no possibility of seeing half of a pane) is more important. I do not have a solution to marry both of these concerns.

��

�� C. When several windows are open the "playgrounds" can not be distinguished by
�� title in the world tool bar.

�� Note that when I save a workspace contents the title of the workspace window
�� is changed to the *.ws file.

Point taken. This is an area of work that is not finished yet.

��

�� D. Change the initial tab name to something more meaninful (related to C).
�� Or use a better timestamp representation as the current precision. As a human
�� I do not distinguish up to milliseconds when opening such a window. Maybe up to
�� seconds is enough.

�� Using a tab is questionable by itself - we never have more than one on the
�� initial code pane...

This is indeed another area that is not yet quite finished. The time stamp shows the actual name of the file from the play-cache folder. It is not about precision. It is about uniqueness. We could imagine a different scheme that provide a counter, but I do not think this would be any better. We have a "tab" because I would like to get to having multiple playgrounds in the same window. Likely, we should end up being able to change the name of that playground and this will transparently map to a file that will be placed in another dedicated folder (I think of calling it play-stash). At that moment, having the technical label as it is now will be useful to easily distinguish between explicitly labelled and unlabelled playground pages. But, this part clearly needs more work.

��

�� E. Easily saving in the cloud is nice - but I would ask the user before sending
�� it. This prevents wrong usage by accidentially clicking.

�� Think of usage in a business scenario where you may work with confidential
�� data that would otherwise be posted on the web...

Good point! Can you add a bug issue for this?

Cheers,

Doru

��

Thanks
T.

www.tudorgirba.com

"Every thing has its own flow"