Hi Bert,

> On Mar 17, 2016, at 2:58 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
> 
>> On 17.03.2016, at 01:43, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> 
>> 
>> On Wed, Mar 16, 2016 at 11:58 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> 
>>> > On 16.03.2016, at 18:48, marcel.taeumel <Marcel.Taeumel at hpi.de> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160317/30ca18dc/attachment.htm