Smalltalk › Pharo › Pharo Smalltalk Users

How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Tim Mackinnon

How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Denis Kudriashov

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Hi.

I dont't know answer to your question. But for the note:

Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.

So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:

Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Tim Mackinnon

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too? If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Denis Kudriashov

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:

Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too? If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

I think in that case your commands can have inst var textMorph because they work with it, they modify its state (cursor). Idea behind commands that they should be self contained objects. You should be able create them in workspace, initialize them with required state without any notion of context and #execute them. Context is only clue to access commands from application.

So try to retrieve state in prepare method like:

prepareFullExecutionInContext: aToolContext

textMorph := aToolContext tool textMorph

(chain is not good but it is what exists for now).

It also possible that I misunderstood your problem :)

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Denis Kudriashov

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

In reply to this post by Tim Mackinnon

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:

Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too?

No.

What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools.

If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

EstebanLM

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Hi,

On 20 Aug 2018, at 00:39, Denis Kudriashov <[hidden email]> wrote:

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:
Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too?

No.
What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools.

Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around).

With enough time to implement, all tools will use same command mechanism.

Esteban

If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Tim Mackinnon

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

AH - this makes sense then that SystemCommands is in its own Repo then (although all these tiny repos get quite difficult the track so you can understand where/how to contribute).

This leads to another question - if I stick my commands for extend selection and jump to keyword in SystemCommands - is the load order such that RubSmalltalkEditor can safely access those commands (I know that for Calypso its ok, but can I reference those commands in the older RubSmalltalkEditor). Otherwise I will need to put the guts of my commands in the RubSmalltalkCodeMode which is shared by al editors (but it feels a bit too generic place for textMorph navigation stuff).

Tim

On 21 Aug 2018, at 05:48, Esteban Lorenzano <[hidden email]> wrote:

Hi,

On 20 Aug 2018, at 00:39, Denis Kudriashov <[hidden email]> wrote:

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:
Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too?

No.
What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools.

Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around).
With enough time to implement, all tools will use same command mechanism.

Esteban

If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Denis Kudriashov

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Hi Tim.

Currently commands are loaded after rubric. So RubSmalltalkEditor can't use them directly.

2018-08-21 13:03 GMT+01:00 Tim Mackinnon <[hidden email]>:

AH - this makes sense then that SystemCommands is in its own Repo then (although all these tiny repos get quite difficult the track so you can understand where/how to contribute).

This leads to another question - if I stick my commands for extend selection and jump to keyword in SystemCommands - is the load order such that RubSmalltalkEditor can safely access those commands (I know that for Calypso its ok, but can I reference those commands in the older RubSmalltalkEditor). Otherwise I will need to put the guts of my commands in the RubSmalltalkCodeMode which is shared by al editors (but it feels a bit too generic place for textMorph navigation stuff).

Tim

On 21 Aug 2018, at 05:48, Esteban Lorenzano <[hidden email]> wrote:

Hi,

On 20 Aug 2018, at 00:39, Denis Kudriashov <[hidden email]> wrote:

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:
Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too?

No.
What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools.

Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around).
With enough time to implement, all tools will use same command mechanism.

Esteban

If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim

Tim Mackinnon

Re: How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

Denis - I’ve hopefully corruptly issues a PR on SystemCommands that shows how I approached this. I think its come out quite neat - but it will need the lower level Rubric based PR to be approved first (and then Calypso will have some useful jump to next keyword and intelligently widen selection commands).

Tim

On 21 Aug 2018, at 20:12, Tim Mackinnon <[hidden email]> wrote:

Thanks Denis - I figured that might be the case. As it turns out - the text selection protocol for the 2 editors is different so I can delegate that to a code block and put it in the
Code mode.

Anyway I’ll figure it out and show you guys in a or (I’m almost there)

Tim

Sent from my iPhone

On 21 Aug 2018, at 17:16, Denis Kudriashov <[hidden email]> wrote:

Hi Tim.

Currently commands are loaded after rubric. So RubSmalltalkEditor can't use them directly.

2018-08-21 13:03 GMT+01:00 Tim Mackinnon <[hidden email]>:
AH - this makes sense then that SystemCommands is in its own Repo then (although all these tiny repos get quite difficult the track so you can understand where/how to contribute).

This leads to another question - if I stick my commands for extend selection and jump to keyword in SystemCommands - is the load order such that RubSmalltalkEditor can safely access those commands (I know that for Calypso its ok, but can I reference those commands in the older RubSmalltalkEditor). Otherwise I will need to put the guts of my commands in the RubSmalltalkCodeMode which is shared by al editors (but it feels a bit too generic place for textMorph navigation stuff).

Tim

On 21 Aug 2018, at 05:48, Esteban Lorenzano <[hidden email]> wrote:

Hi,

On 20 Aug 2018, at 00:39, Denis Kudriashov <[hidden email]> wrote:

2018-08-19 23:12 GMT+01:00 Tim Mackinnon <[hidden email]>:
Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods).

Is the idea that playground will become part of Calypso too?

No.
What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools.

Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around).
With enough time to implement, all tools will use same command mechanism.

Esteban

If so, I can add the methods I need as an extension (although I guess this won’t work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas).

I’ll do something as a pr and we can figure it out.

It’s worth saying, that for my Calypso plugins I’ve had to abuse your mechanism a bit as the simple #execute mechanism doesn’t give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just don’t show any ui prompt).

Tim

Sent from my iPhone

On 19 Aug 2018, at 14:28, Denis Kudriashov <[hidden email]> wrote:

Hi.

I dont't know answer to your question. But for the note:
Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods.
So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them.

2018-08-19 16:55 GMT+01:00 Tim Mackinnon <[hidden email]>:
Hi I’m trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code.

I have commands that should/can work in both the playground as well as code method editor (in Calypso).

Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now I’m not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor.

I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top).

Anyone have some good suggestions?

Tim