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
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 <tim@testit.works>:
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
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 <dionisiydk@gmail.com> 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 <tim@testit.works>:
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
2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works>:
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 <dionisiydk@gmail.com> 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 <tim@testit.works>:
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
2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works>:
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 <dionisiydk@gmail.com> 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 <tim@testit.works>:
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
Hi,
On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>>: 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 <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> 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 <tim@testit.works <mailto:tim@testit.works>>: 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
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 <estebanlm@gmail.com> wrote:
Hi,
On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works <mailto:tim@testit.works>>: 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 <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> 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 <tim@testit.works <mailto:tim@testit.works>>: 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
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 <tim@testit.works>:
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 <estebanlm@gmail.com> wrote:
Hi,
On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim@testit.works>:
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 <dionisiydk@gmail.com> 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 <tim@testit.works>:
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
participants (3)
-
Denis Kudriashov -
Esteban Lorenzano -
Tim Mackinnon