Smalltalk › Pharo › Pharo Smalltalk Users

Pharo 4 Playground open file menu

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

47 messages Options

123

Ben Coman

Re: Pharo 4 Playground open file menu

On Sat, May 2, 2015 at 11:46 AM, Sean P. DeNigris <[hidden email]> wrote:

Sean P. DeNigris wrote
> If so, what would you write there to explain the situation?

And maybe after that snippet we can put the link to
http://www.humane-assessment.com/blog/introducing-the-gtplayground/

Putting more links in the Welcome message to significant introductory videos would be a great idea. Even better if you could click on them and it spawns the host OS web browser.

cheers -ben

Sean P. DeNigris

Re: Pharo 4 Playground open file menu

Administrator

In reply to this post by Sergio Fedi

15468: Add links to Welcome window
https://pharo.fogbugz.com/default.asp?15468

Cheers,
Sean

Sean P. DeNigris

Re: Pharo 4 Playground open file menu

Administrator

Sean P. DeNigris wrote

15468: Enhance the Welcome window

I changed the title since online descriptions in addition to links would be nice.
Also, I copied the text to https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo40WelcomeWindow.md to make it wasy to edit and version until it is ready

Cheers,
Sean

Sergio Fedi

Re: Pharo 4 Playground open file menu

From a usability and design point of view adding more elements to something does not necessarily improve it (i.e. the famous "less is more")

The human attention is a limited resource and it has to be managed accordingly.

The "About" option in the Playground (and in another tools) is a good place to put information about the tool it's purpose, how to use it, how it is related to other tools and external links.

But it is an option that is not immediately obvious to access.

So one thing I would do is give it more exposition, more readily access.

Another typical feature in introducing new features to a user is to make it glow/shine/animate/pop up a message the first time it opens, introducing it's purpose and usage and allowing the user to bypass the message or let it keep coming back (later this information could be accessed via the About or Help option, as it is now)

Sean P. DeNigris

Re: Pharo 4 Playground open file menu

Administrator

In reply to this post by Sean P. DeNigris

Sean P. DeNigris wrote

https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo40WelcomeWindow.md

I added some one-liners and links...

New stuff

GTools - a revolutionary suite of moldable development tools
Playground - one tool, with all the features of and Inspector and a Workspace, which manages an entire workflow in a single window showing custom domain presentations for each object (https://www.google.com/search?q=allinurl:+GTPlayground+site:humane-assessment.com)
Inspector (https://www.google.com/search?q=allinurl:+GTInspector+site:humane-assessment.com)
Spotter - a uniform yet moldable search interface that works on any object, through arbitrary levels of nesting (https://www.google.com/search?q=allinurl:+GTSpotter+site:humane-assessment.com)
Slots - model instance variables as first class enities and enable meta-programming on this level. Read the paper at http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf
ShoreLine reporter - submit information automatically when errors happen (http://forum.world.st/ShoreLine-Reporter-is-in-Pharo-4-td4794723.html)
[Preview] TxText - a modern text model which works with Athens
[Preview] OSWindow - a new way to handle windows and input events (http://forum.world.st/Initial-versions-for-OSWindow-and-Woden-td4761069.html)
Glamour - a mature declarative browser builder (http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Glamour.pdf)
Dark theme (https://d262ilb51hltx0.cloudfront.net/max/2000/1*ezJrwvvvCaLCMumPQTKU1Q.png)

Updated stuff

Zinc/Zodiac - a mature HTTP toolkit (http://zn.stfx.eu/zn/index.html)
Fuel - a fast object serializer (http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf)
Versionner - a GUI tool for Metacello, our package management tool (https://www.youtube.com/watch?v=cFRJDuWL-Q0)

Cheers,
Sean

Esteban A. Maringolo

Re: Pharo 4 Playground open file menu

In reply to this post by Sergio Fedi

"A good UI is like a joke, if you have to explain it then you did something wrong."

El may 2, 2015 1:49 AM, "Sergio Fedi" <[hidden email]> escribió:

Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

Esteban A. Maringolo

Re: Pharo 4 Playground open file menu

In reply to this post by philippeback

Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:

playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

Sean P. DeNigris

Re: Pharo 4 Playground open file menu

Administrator

In reply to this post by Sean P. DeNigris

Sean P. DeNigris wrote

I added some one-liners and links...

It seems like a good improvement and reasonably complete. Please review https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo40WelcomeWindow.md so we can support these new users we've attracted!

Cheers,
Sean

philippeback

Re: Pharo 4 Playground open file menu

In reply to this post by Esteban A. Maringolo

Esteban,

Nice to see we are in the same boat :-)

Phil

Le 2 mai 2015 15:17, "Esteban A. Maringolo" <[hidden email]> a écrit :

Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

EstebanLM

Re: Pharo 4 Playground open file menu

In reply to this post by Esteban A. Maringolo

well… IMO those scripts also should be in a method.

Probably under a class named: MyCoolProjectRunScripts or something like that… but in a class.

If they are in a class you can:

- save them with your project

- version them

- if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).

so… even if you might have a case where you want the save/load… you actually have (what I consider) a better option.

Esteban

On 02 May 2015, at 15:17, Esteban A. Maringolo <[hidden email]> wrote:

Ditto here.
I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
I have scripts to do lots of cli things and I like the save as of the workspace.
But I have done extra key bindings for getting the ws or the playground.
Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

Ben Coman

Re: Pharo 4 Playground open file menu

Those links turned out a bit ugly. What about trying a tiny url via a HTTP level redirect [1]?

[1] http://www.web-source.net/html_redirect.htm#.VUT0c9qqpBd

So it would look like...

GTools - a revolutionary suite of moldable development tools

Playground - one tool, with all the features of and Inspector and a
Workspace, which manages an entire workflow in a single window showing
custom domain presentations for each object (http://pharo.org/link/4/playground)

Inspector (http://pharo.org/link/4/inspector)

Spotter - a uniform yet moldable search interface that works on any
object, through arbitrary levels of nesting (http://pharo.org/link/4/spotter)

Slots - model instance variables as first class enities and enable
meta-programming on this level. Read the paper at (http://pharo.org/link/4/slots)

ShoreLine reporter - submit information automatically when errors happen
(http://pharo.org/link/4/shoreline)

[Preview] TxText - a modern text model which works with Athens

[Preview] OSWindow - a new way to handle windows and input events
(http://pharo.org/link/4/shoreline)

Glamour - a mature declarative browser builder (http://pharo.org/link/4/glamour)

Dark theme (http://pharo.org/link/4/darktheme)

Disclaimer - I haven't tried this in practice.

cheers -ben

On Sat, May 2, 2015 at 11:56 PM, Esteban Lorenzano <[hidden email]> wrote:

well… IMO those scripts also should be in a method.
Probably under a class named: MyCoolProjectRunScripts or something like that… but in a class.
If they are in a class you can:
- save them with your project
- version them
- if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).

so… even if you might have a case where you want the save/load… you actually have (what I consider) a better option.

Esteban

On 02 May 2015, at 15:17, Esteban A. Maringolo <[hidden email]> wrote:

Ditto here.
I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
I have scripts to do lots of cli things and I like the save as of the workspace.
But I have done extra key bindings for getting the ws or the playground.
Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

Sean P. DeNigris

Re: Pharo 4 Playground open file menu

Administrator

Ben Coman wrote

Those links turned out a bit ugly. What about trying a tiny url via a HTTP
level redirect [1]?

That looks cool but I wouldn't hold it up unless we can implement that immediately. Ugly links are better than no links. Of course for Pharo 5.0 with Tx and Pillar we can have pretty contextual links instead of raw text anyway ;)

Cheers,
Sean

Tudor Girba-2

Re: Pharo 4 Playground open file menu

In reply to this post by Esteban A. Maringolo

Hi,

Did you try renaming the playground page as explained before? If yes, besides the fact that in order to open it you have to search it by the name, is there something else that is not working for you?

Cheers,

Doru

On Sat, May 2, 2015 at 3:17 PM, Esteban A. Maringolo <[hidden email]> wrote:

Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

www.tudorgirba.com

"Every thing has its own flow"

philippeback

Re: Pharo 4 Playground open file menu

In reply to this post by EstebanLM

When some sysadmin has to edit them on servers, you want them in .st files.

No class. No IDE. Not too much Smalltalk.

Just the DSL on an as needed to know basis to configure things.

That's better that XML/YAML/JSON...

So, that's the case.

Startup scripts same story.

Phil

Le 2 mai 2015 17:56, "Esteban Lorenzano" <[hidden email]> a écrit :

well… IMO those scripts also should be in a method.
Probably under a class named: MyCoolProjectRunScripts or something like that… but in a class.
If they are in a class you can:
- save them with your project
- version them
- if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).

so… even if you might have a case where you want the save/load… you actually have (what I consider) a better option.

Esteban

On 02 May 2015, at 15:17, Esteban A. Maringolo <[hidden email]> wrote:

Ditto here.
I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
I have scripts to do lots of cli things and I like the save as of the workspace.
But I have done extra key bindings for getting the ws or the playground.
Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

philippeback

Re: Pharo 4 Playground open file menu

In reply to this post by Tudor Girba-2

never tought of renaming the tab.
I was somewhat aware of the feature.

But I have the cache in my .gitignore

Phil

Le 2 mai 2015 22:10, "Tudor Girba" <[hidden email]> a écrit :

Hi,

Did you try renaming the playground page as explained before? If yes, besides the fact that in order to open it you have to search it by the name, is there something else that is not working for you?

Cheers,
Doru

On Sat, May 2, 2015 at 3:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

--
www.tudorgirba.com

"Every thing has its own flow"

philippeback

Re: Pharo 4 Playground open file menu

In reply to this post by Tudor Girba-2

Bit I use GToolkit all the time :-)

Found it cool to see that it displays configurations very well for example!!

Le 2 mai 2015 22:10, "Tudor Girba" <[hidden email]> a écrit :

Hi,

Did you try renaming the playground page as explained before? If yes, besides the fact that in order to open it you have to search it by the name, is there something else that is not working for you?

Cheers,
Doru

On Sat, May 2, 2015 at 3:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

--
www.tudorgirba.com

"Every thing has its own flow"

Tudor Girba-2

Re: Pharo 4 Playground open file menu

In reply to this post by philippeback

As explained before by Andrei and I, if you rename the tab, you will get a named file in play-stash and you can find this file afterwards by name via Spotter. You can also choose a custom location for play-stash in the settings browser.

Cheers,

Doru

On Sat, May 2, 2015 at 11:30 PM, [hidden email] <[hidden email]> wrote:

never tought of renaming the tab.
I was somewhat aware of the feature.

But I have the cache in my .gitignore

Phil

Le 2 mai 2015 22:10, "Tudor Girba" <[hidden email]> a écrit :
Hi,

Did you try renaming the playground page as explained before? If yes, besides the fact that in order to open it you have to search it by the name, is there something else that is not working for you?

Cheers,
Doru

On Sat, May 2, 2015 at 3:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Ditto here.

I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.

I have scripts to do lots of cli things and I like the save as of the workspace.

But I have done extra key bindings for getting the ws or the playground.

Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

--
www.tudorgirba.com

"Every thing has its own flow"

www.tudorgirba.com

"Every thing has its own flow"

marten

Re: Pharo 4 Playground open file menu

In reply to this post by philippeback

Am 02.05.2015 um 23:28 schrieb [hidden email]:

> When some sysadmin has to edit them on servers, you want them in .st files.
>
> No class. No IDE. Not too much Smalltalk.
>
> Just the DSL on an as needed to know basis to configure things.
>
> That's better that XML/YAML/JSON...
>
> So, that's the case.
>
> Startup scripts same story.
>

More or less the same use case as I have ....

Marten

--
Marten Feldtmann

EstebanLM

Re: Pharo 4 Playground open file menu

In reply to this post by philippeback

On 02 May 2015, at 23:28, [hidden email] wrote:

When some sysadmin has to edit them on servers, you want them in .st files.
No class. No IDE. Not too much Smalltalk.

but then

- if not smalltalk, the scripts should not be in the image… even in workspaces

- if the sysadmin has to edit them, he can always do something like:

#! /bin/bash

pharo MyImage.image eval “

multilined

more or less smalltalk

script”

- you can always see and edit your scripts by doing:

'play-cache' asFileReference inspect

(instead ‘play-cache’ you can put: ‘my-script-folder’, whatever)

and you will have a complete inspector that allows you to see and edit your scripts (who are in the file system, where a sysadmin can find them, and not in an obscure workspace).

also I bet you would take no more than 5’ to add functionality to gtinspector (it is designed to be moldable, after all) to add new scripts, and no matter what other functionality you need… and the result will be a lot more “pharoish” than storing it in a workspace.

Esteban

Just the DSL on an as needed to know basis to configure things.
That's better that XML/YAML/JSON...
So, that's the case.
Startup scripts same story.
Phil

Le 2 mai 2015 17:56, "Esteban Lorenzano" <[hidden email]> a écrit :
well… IMO those scripts also should be in a method.
Probably under a class named: MyCoolProjectRunScripts or something like that… but in a class.
If they are in a class you can:
- save them with your project
- version them
- if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).

so… even if you might have a case where you want the save/load… you actually have (what I consider) a better option.

Esteban

On 02 May 2015, at 15:17, Esteban A. Maringolo <[hidden email]> wrote:

Ditto here.
I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.

El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
I have scripts to do lots of cli things and I like the save as of the workspace.
But I have done extra key bindings for getting the ws or the playground.
Phil

Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
Oh! That link gives a GREAT explanation! Thanks.

On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
so I'll ask him for some insights on the matter.

For now, he pointed out some issues like lack of consistency on some interfaces
and some other details.

philippeback

Re: Pharo 4 Playground open file menu

Le 3 mai 2015 12:28, "Esteban Lorenzano" <[hidden email]> a écrit :
>
>
>> On 02 May 2015, at 23:28, [hidden email] wrote:
>>
>> When some sysadmin has to edit them on servers, you want them in .st files.
>>
>> No class. No IDE. Not too much Smalltalk.
>
>
> but then
> - if not smalltalk, the scripts should not be in the image… even in workspaces
> - if the sysadmin has to edit them, he can always do something like:
>
> #! /bin/bash
>
> pharo MyImage.image eval “
> my
> multilined
> more or less smalltalk
> script”
>
> - you can always see and edit your scripts by doing:
>
> 'play-cache' asFileReference inspect
>
> (instead ‘play-cache’ you can put: ‘my-script-folder’, whatever)
>
> and you will have a complete inspector that allows you to see and edit your scripts (who are in the file system, where a sysadmin can find them, and not in an obscure workspace).
>
> also I bet you would take no more than 5’ to add functionality to gtinspector (it is designed to be moldable, after all) to add new scripts, and no matter what other functionality you need… and the result will be a lot more “pharoish” than storing it in a workspace.

I agree to these things for the Pharoish experience.

Just that those scripts are to be edited with Vim on remote boxes.

I don't want to convert a sysadmin to pharo.

I want pharo to be used as any other tool in the lineup.

My image builder is fullly in a class etc.

Also I am using Sebastian Sastre's ConfigurationFiles that do load conf/SomeConfFile.st

I have several such files:

- email addresses
- mongodb conf
- seaside ports, debug level..
- API config
- configuration file for a tree structure
- preferences

These are using code that get eval'd because it is practical to use variables etc.

e.g.

defaultBandwidth := 50 megabitsPerSecond.

....

#(10 20 30 40) do: [:id |
config add: SomeModule new bandwidth: defaultBandwidth; id: id asString; label: 'SomeLab', is asString; picture:'some.jpg'; geoLocation: 45.55@44.42; yourself]

....

^config

I am preparing them in with Playground etc.

So nothing wrong with Playground.

I just like the simple workspace too.

I also added a : prefix in Spotlight to execute what I do type.

Going 4.0 is not yet done here.
I am using 3.0 with GToolkit.

Phil

>
> Esteban
>
>
>> Just the DSL on an as needed to know basis to configure things.
>>
>> That's better that XML/YAML/JSON...
>>
>> So, that's the case.
>>
>> Startup scripts same story.
>>
>> Phil
>>
>> Le 2 mai 2015 17:56, "Esteban Lorenzano" <[hidden email]> a écrit :
>>>
>>> well… IMO those scripts also should be in a method.
>>> Probably under a class named: MyCoolProjectRunScripts or something like that… but in a class.
>>> If they are in a class you can:
>>> - save them with your project
>>> - version them
>>> - if you add <script> pragma, you can even execute them by clicking on it (Pharo 4).
>>>
>>> so… even if you might have a case where you want the save/load… you actually have (what I consider) a better option.
>>>
>>> Esteban
>>>
>>>> On 02 May 2015, at 15:17, Esteban A. Maringolo <[hidden email]> wrote:
>>>>
>>>> Ditto here.
>>>>
>>>> I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace.
>>>>
>>>> El may 2, 2015 4:38 AM, "[hidden email]" <[hidden email]> escribió:
>>>>>
>>>>> playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which.
>>>>>
>>>>> I have scripts to do lots of cli things and I like the save as of the workspace.
>>>>>
>>>>> But I have done extra key bindings for getting the ws or the playground.
>>>>>
>>>>> Phil
>>>>>
>>>>> Le 2 mai 2015 06:49, "Sergio Fedi" <[hidden email]> a écrit :
>>>>>>
>>>>>> Oh! That link gives a GREAT explanation! Thanks.
>>>>>>
>>>>>> On the subject of how to show it better, I'm not a graphic designer (although I'm working with one)
>>>>>> so I'll ask him for some insights on the matter.
>>>>>>
>>>>>>
>>>>>> For now, he pointed out some issues like lack of consistency on some interfaces
>>>>>> and some other details.
>>>>>>
>>>
>

123