Smalltalk › Squeak › Squeak - Dev

Injecting objects into Workspace bindings

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Jakob Reschke-2

Injecting objects into Workspace bindings

Hi all,

is there a convenient way to bind some object (e. g. one that I
inspect at the moment) to a variable in a new or existing Workspace?

Use Case: I would like to read something from an XML file and have
never done that before in Squeak. After installing the XMLParsers
stuff from SqueakMap I dragged my XML file into the image. It shows
the file content in a Workspace, great! Now I want to get that content
as a string object to later supply it to an appropriate parser. I
found the string by inspecting the morphs of the Workspace (is there
an easier way?), but now I would like to have a new workspace where I
can work with that string.

Printing the string in the inspector and copy&pasting would be an
option, but the XML file is quite large and performance issues already
arise when I navigate around in the Workspace where the content was
loaded. For the sake of having tried it out, I attempted to print the
#fullPrintString of the string, but my VM crashed... So, is there a
way to bind arbitrary objects at hand to a Workspace, other than
copying and pasting serialized representations around or fiddling with
"global variables"?

Of course, I could have done the file reading myself with FileStream
etc. to obtain a string, but I wondered if there is a more "tangible"
approach.

Best regards,
Jakob

Hannes Hirzel

Re: Injecting objects into Workspace bindings

Hello Jakob

Does this
http://wiki.squeak.org/squeak/6338
and this
http://wiki.squeak.org/squeak/6342

help for zour problem?

Regards
Hannes

On 3/14/16, Jakob Reschke <[hidden email]> wrote:

> Hi all,
>
> is there a convenient way to bind some object (e. g. one that I
> inspect at the moment) to a variable in a new or existing Workspace?
>
> Use Case: I would like to read something from an XML file and have
> never done that before in Squeak. After installing the XMLParsers
> stuff from SqueakMap I dragged my XML file into the image. It shows
> the file content in a Workspace, great! Now I want to get that content
> as a string object to later supply it to an appropriate parser. I
> found the string by inspecting the morphs of the Workspace (is there
> an easier way?), but now I would like to have a new workspace where I
> can work with that string.
>
> Printing the string in the inspector and copy&pasting would be an
> option, but the XML file is quite large and performance issues already
> arise when I navigate around in the Workspace where the content was
> loaded. For the sake of having tried it out, I attempted to print the
> #fullPrintString of the string, but my VM crashed... So, is there a
> way to bind arbitrary objects at hand to a Workspace, other than
> copying and pasting serialized representations around or fiddling with
> "global variables"?
>
> Of course, I could have done the file reading myself with FileStream
> etc. to obtain a string, but I wondered if there is a more "tangible"
> approach.
>
> Best regards,
> Jakob
>
>

Karl Ramberg

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

I would right click the file name in FileList. You get the option copy name to clipboard.

From there I would open a Workspace and assign to variables as I go.

Best,

Karl

On Mon, Mar 14, 2016 at 2:43 PM, Jakob Reschke <[hidden email]> wrote:

Hi all,

is there a convenient way to bind some object (e. g. one that I
inspect at the moment) to a variable in a new or existing Workspace?

Use Case: I would like to read something from an XML file and have
never done that before in Squeak. After installing the XMLParsers
stuff from SqueakMap I dragged my XML file into the image. It shows
the file content in a Workspace, great! Now I want to get that content
as a string object to later supply it to an appropriate parser. I
found the string by inspecting the morphs of the Workspace (is there
an easier way?), but now I would like to have a new workspace where I
can work with that string.

Printing the string in the inspector and copy&pasting would be an
option, but the XML file is quite large and performance issues already
arise when I navigate around in the Workspace where the content was
loaded. For the sake of having tried it out, I attempted to print the
#fullPrintString of the string, but my VM crashed... So, is there a
way to bind arbitrary objects at hand to a Workspace, other than
copying and pasting serialized representations around or fiddling with
"global variables"?

Of course, I could have done the file reading myself with FileStream
etc. to obtain a string, but I wondered if there is a more "tangible"
approach.

Best regards,
Jakob

Jakob Reschke-2

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

Thank you, but my question was not about how to read XML files (even
though I do this for the first time in Squeak). As I pointed out, I am
aware of the possibility to use FileStream to read the file contents
into a string (and then do the parsing).

After getting the contents in a Workspace window by dragging the file
into the image, I hoped there were some interactive facility to bind
that text to a variable. In my experience, Squeak is full of useful,
but sometimes hidden, functionality and I silently wished more than
once to create such a variable from an inspected object without
abusing the object explorer as my surrogate Workspace.

2016-03-14 15:51 GMT+01:00 H. Hirzel <[hidden email]>:

> Hello Jakob
>
> Does this
> http://wiki.squeak.org/squeak/6338
> and this
> http://wiki.squeak.org/squeak/6342
>
> help for zour problem?
>
> Regards
> Hannes
>
> On 3/14/16, Jakob Reschke <[hidden email]> wrote:
>> Hi all,
>>
>> is there a convenient way to bind some object (e. g. one that I
>> inspect at the moment) to a variable in a new or existing Workspace?
>>
>> Use Case: I would like to read something from an XML file and have
>> never done that before in Squeak. After installing the XMLParsers
>> stuff from SqueakMap I dragged my XML file into the image. It shows
>> the file content in a Workspace, great! Now I want to get that content
>> as a string object to later supply it to an appropriate parser. I
>> found the string by inspecting the morphs of the Workspace (is there
>> an easier way?), but now I would like to have a new workspace where I
>> can work with that string.
>>
>> Printing the string in the inspector and copy&pasting would be an
>> option, but the XML file is quite large and performance issues already
>> arise when I navigate around in the Workspace where the content was
>> loaded. For the sake of having tried it out, I attempted to print the
>> #fullPrintString of the string, but my VM crashed... So, is there a
>> way to bind arbitrary objects at hand to a Workspace, other than
>> copying and pasting serialized representations around or fiddling with
>> "global variables"?
>>
>> Of course, I could have done the file reading myself with FileStream
>> etc. to obtain a string, but I wondered if there is a more "tangible"
>> approach.
>>
>> Best regards,
>> Jakob
>>
>>
>

Jakob Reschke-2

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

2016-03-14 16:04 GMT+01:00 karl ramberg <[hidden email]>:
> I would right click the file name in FileList. You get the option copy name
> to clipboard.
> From there I would open a Workspace and assign to variables as I go.

This will save me from typing the file name, which is also good, but
see my other response. I would still have to do the file reading
stuff, which is perfectly adequate for the task, but I am looking for
a way to create a variable binding from an already obtained piece of
text (which might contain single quotes, so just putting quotes around
it to get a string literal is not an option). In the Morphs I have
already found a suitable string instance that now is accessible in an
Object Explorer or Inspector. I would like to get that back into a
Workspace. So even more generally, I would like to create a Workspace
binding to an arbitrary object that is accessible in another context.

If such thing is not possible - I would be positively surprised if it
were - I wonder if I am the only one who has ever wished for such
thing, or if there is an alternative elegant approach.

>
> On Mon, Mar 14, 2016 at 2:43 PM, Jakob Reschke
> <[hidden email]> wrote:
>>
>> Hi all,
>>
>> is there a convenient way to bind some object (e. g. one that I
>> inspect at the moment) to a variable in a new or existing Workspace?
>>
>> Use Case: I would like to read something from an XML file and have
>> never done that before in Squeak. After installing the XMLParsers
>> stuff from SqueakMap I dragged my XML file into the image. It shows
>> the file content in a Workspace, great! Now I want to get that content
>> as a string object to later supply it to an appropriate parser. I
>> found the string by inspecting the morphs of the Workspace (is there
>> an easier way?), but now I would like to have a new workspace where I
>> can work with that string.
>>
>> Printing the string in the inspector and copy&pasting would be an
>> option, but the XML file is quite large and performance issues already
>> arise when I navigate around in the Workspace where the content was
>> loaded. For the sake of having tried it out, I attempted to print the
>> #fullPrintString of the string, but my VM crashed... So, is there a
>> way to bind arbitrary objects at hand to a Workspace, other than
>> copying and pasting serialized representations around or fiddling with
>> "global variables"?
>>
>> Of course, I could have done the file reading myself with FileStream
>> etc. to obtain a string, but I wondered if there is a more "tangible"
>> approach.
>>
>> Best regards,
>> Jakob
>>
>

Bert Freudenberg

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

You can enable "create textual references to dropped morphs” in a workspace window’s menu (blue title bar button). Then, from the inspector, drag the field name (or ‘self’) onto the workspace. It creates a variable named like ‘transfer2694476’ pointing to the transfer morph (the thing you dragged). Access the string using 'transfer2694476 passenger’. Done.

Arguably we should make workspaces know about TransferMorphs and insert a reference to the morph’s passenger automatically (and independently of the “create refs” flag).

- Bert -

> On 14.03.2016, at 17:15, Jakob Reschke <[hidden email]> wrote:
>
> Thank you, but my question was not about how to read XML files (even
> though I do this for the first time in Squeak). As I pointed out, I am
> aware of the possibility to use FileStream to read the file contents
> into a string (and then do the parsing).
>
> After getting the contents in a Workspace window by dragging the file
> into the image, I hoped there were some interactive facility to bind
> that text to a variable. In my experience, Squeak is full of useful,
> but sometimes hidden, functionality and I silently wished more than
> once to create such a variable from an inspected object without
> abusing the object explorer as my surrogate Workspace.
>
> 2016-03-14 15:51 GMT+01:00 H. Hirzel <[hidden email]>:
>> Hello Jakob
>>
>> Does this
>> http://wiki.squeak.org/squeak/6338
>> and this
>> http://wiki.squeak.org/squeak/6342
>>
>> help for zour problem?
>>
>> Regards
>> Hannes
>>
>> On 3/14/16, Jakob Reschke <[hidden email]> wrote:
>>> Hi all,
>>>
>>> is there a convenient way to bind some object (e. g. one that I
>>> inspect at the moment) to a variable in a new or existing Workspace?
>>>
>>> Use Case: I would like to read something from an XML file and have
>>> never done that before in Squeak. After installing the XMLParsers
>>> stuff from SqueakMap I dragged my XML file into the image. It shows
>>> the file content in a Workspace, great! Now I want to get that content
>>> as a string object to later supply it to an appropriate parser. I
>>> found the string by inspecting the morphs of the Workspace (is there
>>> an easier way?), but now I would like to have a new workspace where I
>>> can work with that string.
>>>
>>> Printing the string in the inspector and copy&pasting would be an
>>> option, but the XML file is quite large and performance issues already
>>> arise when I navigate around in the Workspace where the content was
>>> loaded. For the sake of having tried it out, I attempted to print the
>>> #fullPrintString of the string, but my VM crashed... So, is there a
>>> way to bind arbitrary objects at hand to a Workspace, other than
>>> copying and pasting serialized representations around or fiddling with
>>> "global variables"?
>>>
>>> Of course, I could have done the file reading myself with FileStream
>>> etc. to obtain a string, but I wondered if there is a more "tangible"
>>> approach.
>>>
>>> Best regards,
>>> Jakob
>>>
>>>
>>
>

smime.p7s (5K) Download Attachment

Jakob Reschke-2

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

Fabulous! That is exactly the kind of useful but hidden functionality
I was talking about. ;-) Thank you very much!

Now the only UI annoyance left here is that dragging only works from
Inspector but not from Object Explorer, but I can live with that.

2016-03-14 17:44 GMT+01:00 Bert Freudenberg <[hidden email]>:

> You can enable "create textual references to dropped morphs” in a workspace window’s menu (blue title bar button). Then, from the inspector, drag the field name (or ‘self’) onto the workspace. It creates a variable named like ‘transfer2694476’ pointing to the transfer morph (the thing you dragged). Access the string using 'transfer2694476 passenger’. Done.
>
> Arguably we should make workspaces know about TransferMorphs and insert a reference to the morph’s passenger automatically (and independently of the “create refs” flag).
>
> - Bert -
>
>> On 14.03.2016, at 17:15, Jakob Reschke <[hidden email]> wrote:
>>
>> Thank you, but my question was not about how to read XML files (even
>> though I do this for the first time in Squeak). As I pointed out, I am
>> aware of the possibility to use FileStream to read the file contents
>> into a string (and then do the parsing).
>>
>> After getting the contents in a Workspace window by dragging the file
>> into the image, I hoped there were some interactive facility to bind
>> that text to a variable. In my experience, Squeak is full of useful,
>> but sometimes hidden, functionality and I silently wished more than
>> once to create such a variable from an inspected object without
>> abusing the object explorer as my surrogate Workspace.
>>
>> 2016-03-14 15:51 GMT+01:00 H. Hirzel <[hidden email]>:
>>> Hello Jakob
>>>
>>> Does this
>>> http://wiki.squeak.org/squeak/6338
>>> and this
>>> http://wiki.squeak.org/squeak/6342
>>>
>>> help for zour problem?
>>>
>>> Regards
>>> Hannes
>>>
>>> On 3/14/16, Jakob Reschke <[hidden email]> wrote:
>>>> Hi all,
>>>>
>>>> is there a convenient way to bind some object (e. g. one that I
>>>> inspect at the moment) to a variable in a new or existing Workspace?
>>>>
>>>> Use Case: I would like to read something from an XML file and have
>>>> never done that before in Squeak. After installing the XMLParsers
>>>> stuff from SqueakMap I dragged my XML file into the image. It shows
>>>> the file content in a Workspace, great! Now I want to get that content
>>>> as a string object to later supply it to an appropriate parser. I
>>>> found the string by inspecting the morphs of the Workspace (is there
>>>> an easier way?), but now I would like to have a new workspace where I
>>>> can work with that string.
>>>>
>>>> Printing the string in the inspector and copy&pasting would be an
>>>> option, but the XML file is quite large and performance issues already
>>>> arise when I navigate around in the Workspace where the content was
>>>> loaded. For the sake of having tried it out, I attempted to print the
>>>> #fullPrintString of the string, but my VM crashed... So, is there a
>>>> way to bind arbitrary objects at hand to a Workspace, other than
>>>> copying and pasting serialized representations around or fiddling with
>>>> "global variables"?
>>>>
>>>> Of course, I could have done the file reading myself with FileStream
>>>> etc. to obtain a string, but I wondered if there is a more "tangible"
>>>> approach.
>>>>
>>>> Best regards,
>>>> Jakob
>>>>
>>>>
>>>
>>
>
>

Chris Muller-3

Re: Injecting objects into Workspace bindings

In reply to this post by Jakob Reschke-2

Jakob, you can simply assign the string to a var in your workspace
just once, and then you'll have access to it. Make sure
"automatically create variable declaration" is enabled in your
workspace menu.

Having said that, this presents the opportunity to share my own
solution to the shortcomings of workspaces: I don't use them. Not
for code, anyway, just for notes.

For code, just put it in a class. You get storage, method
composition, change history, and the ability to save it in the SCM
tool later, if you decide.

On Mon, Mar 14, 2016 at 8:43 AM, Jakob Reschke
<[hidden email]> wrote:

marcel.taeumel

Re: Injecting objects into Workspace bindings

Mabye we need a simple way to link bindings across tools. Then, for example, we could simple connect a Workspace window to the text box in the Inspector (resp. Object Explorer) and all would share the same bindings. Then, you could simply select stuff in the Object Explorer, evaluate "x := self" and you would have access to x in that other Workspace (resp. Inspector's text box).

The drag-and-drop idea is also nice.

Best,
Marcel

Bert Freudenberg

Re: Injecting objects into Workspace bindings

> On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>
> Mabye we need a simple way to link bindings across tools. Then, for example,
> we could simple connect a Workspace window to the text box in the Inspector
> (resp. Object Explorer) and all would share the same bindings. Then, you
> could simply select stuff in the Object Explorer, evaluate "x := self" and
> you would have access to x in that other Workspace (resp. Inspector's text
> box).

Not a bad idea … what could be a UI for connecting workspaces?

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: Injecting objects into Workspace bindings

On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]> wrote:

> On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>
> Mabye we need a simple way to link bindings across tools. Then, for example,
> we could simple connect a Workspace window to the text box in the Inspector
> (resp. Object Explorer) and all would share the same bindings. Then, you
> could simply select stuff in the Object Explorer, evaluate "x := self" and
> you would have access to x in that other Workspace (resp. Inspector's text
> box).

Not a bad idea … what could be a UI for connecting workspaces?

How about a test for Environments? Create a subclass of Environment with a singleton called, say, Grabbag. Implement a doesNotUnderstand: method in Grabbag that turns one-argument keyword messages such as Grabbag theSelector: theValue into at: theSelector put: theValue and unary messages into at: so that Grabbag theSelector is equivalent to Grabbag at: theSelector. Then include Grabbag in all workspaces. From Smalltalk one can do Grabbag at: #mine put: greedySeagull or Grabbag mineMineMine: flockOfGreedySeagulls, but in Workspaces (with the default option of importing Grabbag on) one can simply say dorysLocation := #whatWasTheQuestionAgain

- Bert -

_,,,^..^,,,_

best, Eliot

Bert Freudenberg

Re: Injecting objects into Workspace bindings

On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:

On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]> wrote:

> On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>
> Mabye we need a simple way to link bindings across tools. Then, for example,
> we could simple connect a Workspace window to the text box in the Inspector
> (resp. Object Explorer) and all would share the same bindings. Then, you
> could simply select stuff in the Object Explorer, evaluate "x := self" and
> you would have access to x in that other Workspace (resp. Inspector's text
> box).

Not a bad idea … what could be a UI for connecting workspaces?

How about a test for Environments? Create a subclass of Environment with a singleton called, say, Grabbag. Implement a doesNotUnderstand: method in Grabbag that turns one-argument keyword messages such as Grabbag theSelector: theValue into at: theSelector put: theValue and unary messages into at: so that Grabbag theSelector is equivalent to Grabbag at: theSelector. Then include Grabbag in all workspaces. From Smalltalk one can do Grabbag at: #mine put: greedySeagull or Grabbag mineMineMine: flockOfGreedySeagulls, but in Workspaces (with the default option of importing Grabbag on) one can simply say dorysLocation := #whatWasTheQuestionAgain

That’s for when we wanted to always share bindings by default, sure. Not much UI needed for that.

But I think I’d like workspaces to be isolated by default. And in that case we’d need some discoverable UI for making them shared.

Another idea would be to only share selected bindings. We could always show a workspace’s bindings in a side panel (which may be useful in its own right) and then dragging a binding to another workspace would make it shared, so changes to it on one would be reflected in the other.

- Bert -

smime.p7s (5K) Download Attachment

Karl Ramberg

Re: Injecting objects into Workspace bindings

On Thu, Mar 17, 2016 at 10:58 AM, Bert Freudenberg <[hidden email]> wrote:

On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:

On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]> wrote:

> On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>
> Mabye we need a simple way to link bindings across tools. Then, for example,
> we could simple connect a Workspace window to the text box in the Inspector
> (resp. Object Explorer) and all would share the same bindings. Then, you
> could simply select stuff in the Object Explorer, evaluate "x := self" and
> you would have access to x in that other Workspace (resp. Inspector's text
> box).

Not a bad idea … what could be a UI for connecting workspaces?

How about a test for Environments? Create a subclass of Environment with a singleton called, say, Grabbag. Implement a doesNotUnderstand: method in Grabbag that turns one-argument keyword messages such as Grabbag theSelector: theValue into at: theSelector put: theValue and unary messages into at: so that Grabbag theSelector is equivalent to Grabbag at: theSelector. Then include Grabbag in all workspaces. From Smalltalk one can do Grabbag at: #mine put: greedySeagull or Grabbag mineMineMine: flockOfGreedySeagulls, but in Workspaces (with the default option of importing Grabbag on) one can simply say dorysLocation := #whatWasTheQuestionAgain

That’s for when we wanted to always share bindings by default, sure. Not much UI needed for that.

But I think I’d like workspaces to be isolated by default. And in that case we’d need some discoverable UI for making them shared.

Another idea would be to only share selected bindings. We could always show a workspace’s bindings in a side panel (which may be useful in its own right) and then dragging a binding to another workspace would make it shared, so changes to it on one would be reflected in the other.

Best,

Karl

- Bert -

Chris Muller-3

Re: Injecting objects into Workspace bindings

In reply to this post by Bert Freudenberg

On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]> wrote:

>
> On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]>
> wrote:
>>
>>
>> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>> >
>> > Mabye we need a simple way to link bindings across tools. Then, for
>> > example,
>> > we could simple connect a Workspace window to the text box in the
>> > Inspector
>> > (resp. Object Explorer) and all would share the same bindings. Then, you
>> > could simply select stuff in the Object Explorer, evaluate "x := self"
>> > and
>> > you would have access to x in that other Workspace (resp. Inspector's
>> > text
>> > box).
>>
>> Not a bad idea … what could be a UI for connecting workspaces?

Why not just invoke the halos on the inspectors built-in workspace and
clone it with the upper-green button and use that?

Karl Ramberg

Re: Injecting objects into Workspace bindings

On Thu, Mar 17, 2016 at 4:39 PM, Chris Muller <[hidden email]> wrote:

On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]> wrote:
>
> On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]>
> wrote:
>>
>>
>> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>> >
>> > Mabye we need a simple way to link bindings across tools. Then, for
>> > example,
>> > we could simple connect a Workspace window to the text box in the
>> > Inspector
>> > (resp. Object Explorer) and all would share the same bindings. Then, you
>> > could simply select stuff in the Object Explorer, evaluate "x := self"
>> > and
>> > you would have access to x in that other Workspace (resp. Inspector's
>> > text
>> > box).
>>
>> Not a bad idea … what could be a UI for connecting workspaces?

Why not just invoke the halos on the inspectors built-in workspace and
clone it with the upper-green button and use that?

This would break workflow I think because like Jacob wrote, you open a file in a Workspace and you need a reference to that from another already open Workspace.

How about another copy command, like 'copy as reference' and then you could paste it in another Workspace ?

Best,

Karl

Karl Ramberg

Re: Injecting objects into Workspace bindings

Actually most is all ready implemented.

You can open a inspector on variable bindings in a Workspace and drag out TransferMorphs from that.

The only thing needed is for Workspaces to bind to the passenger instead of the dropped TransferMorph.

Best,

Karl

On Thu, Mar 17, 2016 at 5:28 PM, karl ramberg <[hidden email]> wrote:

On Thu, Mar 17, 2016 at 4:39 PM, Chris Muller <[hidden email]> wrote:
On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]> wrote:
>
> On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]>
> wrote:
>>
>>
>> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>> >
>> > Mabye we need a simple way to link bindings across tools. Then, for
>> > example,
>> > we could simple connect a Workspace window to the text box in the
>> > Inspector
>> > (resp. Object Explorer) and all would share the same bindings. Then, you
>> > could simply select stuff in the Object Explorer, evaluate "x := self"
>> > and
>> > you would have access to x in that other Workspace (resp. Inspector's
>> > text
>> > box).
>>
>> Not a bad idea … what could be a UI for connecting workspaces?

Why not just invoke the halos on the inspectors built-in workspace and
clone it with the upper-green button and use that?

This would break workflow I think because like Jacob wrote, you open a file in a Workspace and you need a reference to that from another already open Workspace.

How about another copy command, like 'copy as reference' and then you could paste it in another Workspace ?

Best,
Karl

Chris Muller-4

Re: Injecting objects into Workspace bindings

In reply to this post by Karl Ramberg

All Jakob had to do was "do it" on:

myXml := '<SomeElement>.... all kinds of XML ... </SomeElement>'

He now has access to myXml. Then replace all the text in the
workspace with that from the other workspace. Done.

I guess I see Workspaces for learning and discovery for newbies.
Short, simple, explorations of syntax and class library.

Attempting to do work as complex as parsing a large XML is going to
present further challenges above and beyond accessing an object. If
someone feels the need to "link workspaces" they really should stop
and consider just making a class. In fact, I think linked workspaces
would lead a newbie down the wrong path..

On Thu, Mar 17, 2016 at 11:28 AM, karl ramberg <[hidden email]> wrote:

>
>
> On Thu, Mar 17, 2016 at 4:39 PM, Chris Muller <[hidden email]> wrote:
>>
>> On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>> >
>> > On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg
>> > <[hidden email]>
>> > wrote:
>> >>
>> >>
>> >> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]>
>> >> > wrote:
>> >> >
>> >> > Mabye we need a simple way to link bindings across tools. Then, for
>> >> > example,
>> >> > we could simple connect a Workspace window to the text box in the
>> >> > Inspector
>> >> > (resp. Object Explorer) and all would share the same bindings. Then,
>> >> > you
>> >> > could simply select stuff in the Object Explorer, evaluate "x :=
>> >> > self"
>> >> > and
>> >> > you would have access to x in that other Workspace (resp. Inspector's
>> >> > text
>> >> > box).
>> >>
>> >> Not a bad idea … what could be a UI for connecting workspaces?
>>
>> Why not just invoke the halos on the inspectors built-in workspace and
>> clone it with the upper-green button and use that?
>>
> This would break workflow I think because like Jacob wrote, you open a file
> in a Workspace and you need a reference to that from another already open
> Workspace.
>
> How about another copy command, like 'copy as reference' and then you could
> paste it in another Workspace ?
>
>
> Best,
> Karl

Karl Ramberg

Re: Injecting objects into Workspace bindings

Workspaces are great for scripting and exploring ideas etc. And working with already existing objects. It's not so good for developing but very good for other important computing and learning needs.

Best,

Karl

On Thu, Mar 17, 2016 at 5:55 PM, Chris Muller <[hidden email]> wrote:

All Jakob had to do was "do it" on:

myXml := '<SomeElement>.... all kinds of XML ... </SomeElement>'

He now has access to myXml. Then replace all the text in the
workspace with that from the other workspace. Done.

I guess I see Workspaces for learning and discovery for newbies.
Short, simple, explorations of syntax and class library.

Attempting to do work as complex as parsing a large XML is going to
present further challenges above and beyond accessing an object. If
someone feels the need to "link workspaces" they really should stop
and consider just making a class. In fact, I think linked workspaces
would lead a newbie down the wrong path..

On Thu, Mar 17, 2016 at 11:28 AM, karl ramberg <[hidden email]> wrote:
>
>
> On Thu, Mar 17, 2016 at 4:39 PM, Chris Muller <[hidden email]> wrote:
>>
>> On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>> >
>> > On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg
>> > <[hidden email]>
>> > wrote:
>> >>
>> >>
>> >> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]>
>> >> > wrote:
>> >> >
>> >> > Mabye we need a simple way to link bindings across tools. Then, for
>> >> > example,
>> >> > we could simple connect a Workspace window to the text box in the
>> >> > Inspector
>> >> > (resp. Object Explorer) and all would share the same bindings. Then,
>> >> > you
>> >> > could simply select stuff in the Object Explorer, evaluate "x :=
>> >> > self"
>> >> > and
>> >> > you would have access to x in that other Workspace (resp. Inspector's
>> >> > text
>> >> > box).
>> >>
>> >> Not a bad idea … what could be a UI for connecting workspaces?
>>
>> Why not just invoke the halos on the inspectors built-in workspace and
>> clone it with the upper-green button and use that?
>>
> This would break workflow I think because like Jacob wrote, you open a file
> in a Workspace and you need a reference to that from another already open
> Workspace.
>
> How about another copy command, like 'copy as reference' and then you could
> paste it in another Workspace ?
>
>
> Best,
> Karl

Eliot Miranda-2

Re: Injecting objects into Workspace bindings

In reply to this post by Bert Freudenberg

Hi Bert,

On Mar 17, 2016, at 2:58 AM, Bert Freudenberg <[hidden email]> wrote:

On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:

On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <[hidden email]> wrote:

> On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]> wrote:
>
> Mabye we need a simple way to link bindings across tools. Then, for example,
> we could simple connect a Workspace window to the text box in the Inspector
> (resp. Object Explorer) and all would share the same bindings. Then, you
> could simply select stuff in the Object Explorer, evaluate "x := self" and
> you would have access to x in that other Workspace (resp. Inspector's text
> box).

Not a bad idea … what could be a UI for connecting workspaces?

How about a test for Environments? Create a subclass of Environment with a singleton called, say, Grabbag. Implement a doesNotUnderstand: method in Grabbag that turns one-argument keyword messages such as Grabbag theSelector: theValue into at: theSelector put: theValue and unary messages into at: so that Grabbag theSelector is equivalent to Grabbag at: theSelector. Then include Grabbag in all workspaces. From Smalltalk one can do Grabbag at: #mine put: greedySeagull or Grabbag mineMineMine: flockOfGreedySeagulls, but in Workspaces (with the default option of importing Grabbag on) one can simply say dorysLocation := #whatWasTheQuestionAgain

That’s for when we wanted to always share bindings by default, sure. Not much UI needed for that.

But I think I’d like workspaces to be isolated by default. And in that case we’d need some discoverable UI for making them shared.

Another idea would be to only share selected bindings. We could always show a workspace’s bindings in a side panel (which may be useful in its own right) and then dragging a binding to another workspace would make it shared, so changes to it on one would be reflected in the other.

Ok, then how about generalizing my scheme above to replace the clipboard (copy paste buffer). The environment is called Clipboard; it responds to the existing API (I'm on my phone, I'm not checking, but I guess the singleton can support the existing API without too much distortion).

Different default copy/paste types are stored in well-named bindings in the Clipboard environment such as #LastCutText #PreviousFiveClippedTexts #LastDeletedMorph etc. implement its of editing functionality are encouraged to follow conventions around this Clipboard environment.

Paste menu items can choose a default binding to/from which to paste/copy, but a consistent gesture (eg shift) opens a menu on all potential sources in Clipboard.

Clipboard is accessible from code, and by being an environment it is more accessible than the existing class Clipboard, with a more consistent API (and it doesn't /have/ to provide the MNU truck for convenient access, but it's nice to have).

Clipboard gets its own inspector/explorer equipped with convenient shortcuts for flushing values, deleting stale keys, etc.

Then for workspaces the paste operation can support things like pasting a value from Clipboard into a workspace-local variable if that variable name is selected, etc, so through paste and the shift gesture we can distinguish between replacing referent (the variable named by the text selection) or refacing signifier (the text that happens to be the name of the variable).

- Bert -

_,,,^..^,,,_ (phone)

Karl Ramberg

Re: Injecting objects into Workspace bindings

In reply to this post by Karl Ramberg

A little ugly with the code duplication but it works ;-)

Workspace>>acceptDroppingMorph: dropee event: evt inMorph: targetMorph

"Return the dropee to its old position, and add a reference to it at the

cursor point."

| bindingName externalName |

(dropee isKindOf: TransferMorph)

ifTrue: [externalName := dropee passenger className.

externalName := externalName isOctetString

ifTrue: [externalName]

ifFalse: ['a' , externalName].

bindingName := externalName translateToLowercase , dropee passenger identityHash printString.

targetMorph correctSelectionWithString: bindingName , ' '.

(self bindingOf: bindingName)

value: dropee passenger]

ifFalse: [externalName := dropee externalName.

externalName := externalName isOctetString

ifTrue: [externalName]

ifFalse: ['a' , externalName].

bindingName := externalName translateToLowercase , dropee identityHash printString.

targetMorph correctSelectionWithString: bindingName , ' '.

(self bindingOf: bindingName)

value: dropee].

dropee rejectDropMorphEvent: evt.

^ true"success"

On Thu, Mar 17, 2016 at 6:06 PM, karl ramberg <[hidden email]> wrote:

Workspaces are great for scripting and exploring ideas etc. And working with already existing objects. It's not so good for developing but very good for other important computing and learning needs.

Best,
Karl

On Thu, Mar 17, 2016 at 5:55 PM, Chris Muller <[hidden email]> wrote:
All Jakob had to do was "do it" on:

myXml := '<SomeElement>.... all kinds of XML ... </SomeElement>'

He now has access to myXml. Then replace all the text in the
workspace with that from the other workspace. Done.

I guess I see Workspaces for learning and discovery for newbies.
Short, simple, explorations of syntax and class library.

Attempting to do work as complex as parsing a large XML is going to
present further challenges above and beyond accessing an object. If
someone feels the need to "link workspaces" they really should stop
and consider just making a class. In fact, I think linked workspaces
would lead a newbie down the wrong path..

On Thu, Mar 17, 2016 at 11:28 AM, karl ramberg <[hidden email]> wrote:
>
>
> On Thu, Mar 17, 2016 at 4:39 PM, Chris Muller <[hidden email]> wrote:
>>
>> On Thu, Mar 17, 2016 at 4:58 AM, Bert Freudenberg <[hidden email]>
>> wrote:
>> >
>> > On 17.03.2016, at 01:43, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg
>> > <[hidden email]>
>> > wrote:
>> >>
>> >>
>> >> > On 16.03.2016, at 18:48, marcel.taeumel <[hidden email]>
>> >> > wrote:
>> >> >
>> >> > Mabye we need a simple way to link bindings across tools. Then, for
>> >> > example,
>> >> > we could simple connect a Workspace window to the text box in the
>> >> > Inspector
>> >> > (resp. Object Explorer) and all would share the same bindings. Then,
>> >> > you
>> >> > could simply select stuff in the Object Explorer, evaluate "x :=
>> >> > self"
>> >> > and
>> >> > you would have access to x in that other Workspace (resp. Inspector's
>> >> > text
>> >> > box).
>> >>
>> >> Not a bad idea … what could be a UI for connecting workspaces?
>>
>> Why not just invoke the halos on the inspectors built-in workspace and
>> clone it with the upper-green button and use that?
>>
> This would break workflow I think because like Jacob wrote, you open a file
> in a Workspace and you need a reference to that from another already open
> Workspace.
>
> How about another copy command, like 'copy as reference' and then you could
> paste it in another Workspace ?
>
>
> Best,
> Karl