Maybe use��

Smalltalk tools workspace��

instead of the direct reference���

In the long run, for GT, people will use the the FileList less and less and instead just use Spotter to explore the filesystem and then

GT to look at files�����

We should try to replace the FileList by Spotter for Pharo5��� less code to maintain.

Marcus

On 07 Jun 2015, at 17:39, volkert <volkert@komponentenwerkstatt.de> wrote:

I have found a bug and opened new case for it: https://pharo.fogbugz.com/f/cases/15711/
I also what to send a fix.
But i am not sure, if the fix is as simple as i described it (see tail of this mail).
My Question: Is the bug in the UIManager or only on the sender FileList>>viewContentsInWorkspace. I think, in the sender. So i can simply replace "UIManager default edit: aString label: 'Workspace from ', self reference basename " with " Workspace openContents: aString label: 'Workspace from ', self reference basename".

Am 07.06.2015 um 17:20 schrieb stepharo:

UIManager was an attempt to support a way to theme widgets.
And also to be able to run Pharo headless but providing a DummyManager.
What is the original problem you faced?

Stef

Le 6/6/15 16:37, volkert a ��crit��:

Is this change resonable. I have no idea, what the Design-Idea behind the UIManager what services is should provide. May be it make sense to have the extra services on UIManager, but think the bug is in FileList>>viewContentsInWorkspace and not in UIManager.

----
I propose for Workspace to change the current code:

FileList>>viewContentsInWorkspace
������ "View the contents of my selected file in a new workspace"������
������ | aString |
������ self reference streamWritable: false do: [ :stream|
������ ������ aString := stream setConverterForCode contentsOfEntireFile ].
������ UIManager default edit: aString label: 'Workspace from ', self reference basename�� <----- WRONG

to :

FileList>>viewContentsInWorkspace
������ "View the contents of my selected file in a new workspace"
������ | aString |��
������ self reference streamWritable: false do: [ :stream|
������ ������ aString := stream setConverterForCode contentsOfEntireFile ].
������ Workspace openContents: aString label: 'Workspace from ', self reference basename

And i also proposse the add a Playground case.

New Method:

FileList>>viewContentsInPlayground
������ "View the contents of my selected file in a new playground"
������ | aString |��
������ self reference streamWritable: false do: [ :stream|
������ ������ aString := stream setConverterForCode contentsOfEntireFile ].
������ GTPlayground openContents: aString label: 'Playground from ', self reference basename.

and also FileList>>serviceViewContentsInPlayground and the case in ListList>>itemsForAnyFile.

If ok, i can fix Workspace and add Playground menu to FileList, after i have figured out how to send an fix ;-)

BW,
Volkert

Am 03.06.2015 um 16:40 schrieb Ben Coman:

Or do we now want such to open in Playground?

btw, these are the relevant methods.
FileList>>FileList>>viewContentsInWorkspace
FileList>>viewContentsInWorkspace

cheers -ben

On Wed, Jun 3, 2015 at 6:57 PM, volkert <volkert@komponentenwerkstatt.de> wrote:

The File Browser has a Context Menu "Workspace with Contents". It opens an
Edit Window (String Morph), but not a Workspace ...

Is the Menu-Title wrong or the implementation?

BW,
Volkert