cleanup rubric

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

cleanup rubric

Nicolai Hess
Maybe I am wrong, but it looks like there are many
classes and code in rubric that are the same as in the old Text classes.

Rub is used in GT and now in the Core image. Shouldn't we clean this up
before it used everywhere?

Some examples:

All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)

MorphAnnouncement subclass: #RubMorphAnnouncement
RubMorphAnnouncment adds nothing

FindReplaceService <-> RubFindReplaceService
They look very similar, I don't understand why so much code is
just the same in both, why not extract that into a base class?
(and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
and some many too)

RubEditingState / EditingState.

What this makes it even worse, Rubs class comment doesn't indicate how
they differ from the old other one.

It is really difficult to understand,
- which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework.
- wich classes are used but could be replaced with the existing one (TextLink for example)
- which classes had to be changed, and therefore only the Rub-classes can work with rubric.
- which classes are similiar named like the old Text classes and share some code but may work
totally different.

(For example TextEditor vs. RubTextEditor there are some methods in both that aren't used
anywhere, it looks like RubTextEditor is just
- a copy from TextEditor,
- changed where it was needed
- unchanged otherwise

Rubric really adds some great new things and if you look at where it is used, it
is really a great step forward, but the code is in a bad state.
This needs to be cleaned up.






Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

EstebanLM
Hi,

the idea is to replace all old text classes usage, then remove them (and Rubric will became the unique text editor in Pharo)
so… I *think* (not sure about it), the duplication of classes is in this case on purpose, and a temporal thing.

Esteban

> On 31 Jul 2015, at 12:17, Nicolai Hess <[hidden email]> wrote:
>
> Maybe I am wrong, but it looks like there are many
> classes and code in rubric that are the same as in the old Text classes.
>
> Rub is used in GT and now in the Core image. Shouldn't we clean this up
> before it used everywhere?
>
> Some examples:
>
> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
>
> MorphAnnouncement subclass: #RubMorphAnnouncement
> RubMorphAnnouncment adds nothing
>
> FindReplaceService <-> RubFindReplaceService
> They look very similar, I don't understand why so much code is
> just the same in both, why not extract that into a base class?
> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
> and some many too)
>
> RubEditingState / EditingState.
>
> What this makes it even worse, Rubs class comment doesn't indicate how
> they differ from the old other one.
>
> It is really difficult to understand,
> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework.
> - wich classes are used but could be replaced with the existing one (TextLink for example)
> - which classes had to be changed, and therefore only the Rub-classes can work with rubric.
> - which classes are similiar named like the old Text classes and share some code but may work
> totally different.
>
> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used
> anywhere, it looks like RubTextEditor is just
> - a copy from TextEditor,
> - changed where it was needed
> - unchanged otherwise
>
> Rubric really adds some great new things and if you look at where it is used, it
> is really a great step forward, but the code is in a bad state.
> This needs to be cleaned up.
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Nicolai Hess


2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi,

the idea is to replace all old text classes usage, then remove them (and Rubric will became the unique text editor in Pharo)
so… I *think* (not sure about it), the duplication of classes is in this case on purpose, and a temporal thing.

But the duplication makes it *really* difficult to clean  up Rubric from the old TextEditor API.

 
Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

EstebanLM

On 31 Jul 2015, at 12:35, Nicolai Hess <[hidden email]> wrote:



2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi,

the idea is to replace all old text classes usage, then remove them (and Rubric will became the unique text editor in Pharo)
so… I *think* (not sure about it), the duplication of classes is in this case on purpose, and a temporal thing.

But the duplication makes it *really* difficult to clean  up Rubric from the old TextEditor API.

why? can’t you just ignore the old ones? I do not understand :(

Esteban


 

Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Marcus Denker-4
In reply to this post by Nicolai Hess

On 31 Jul 2015, at 12:35, Nicolai Hess <[hidden email]> wrote:



2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi,

the idea is to replace all old text classes usage, then remove them (and Rubric will became the unique text editor in Pharo)
so… I *think* (not sure about it), the duplication of classes is in this case on purpose, and a temporal thing.

But the duplication makes it *really* difficult to clean  up Rubric from the old TextEditor API.



Yes, we need to wait 

1) replace all users of the old 
2) remove old
3) clean up

The reason for the duplication is that after 1) you can just delete the old editor related code, as all needed parts
are in the new package already.

(At least this is how I understand it)

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Nicolai Hess
In reply to this post by EstebanLM


2015-07-31 12:55 GMT+02:00 Esteban Lorenzano <[hidden email]>:

On 31 Jul 2015, at 12:35, Nicolai Hess <[hidden email]> wrote:



2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <[hidden email]>:
Hi,

the idea is to replace all old text classes usage, then remove them (and Rubric will became the unique text editor in Pharo)
so… I *think* (not sure about it), the duplication of classes is in this case on purpose, and a temporal thing.

But the duplication makes it *really* difficult to clean  up Rubric from the old TextEditor API.

why? can’t you just ignore the old ones? I do not understand :(

For example, in the current effort to replace PluggableTextMorph with Rubric, how do you make sure
to use *only* rubrics API and methods and not the others copied from the old Text API?

*Every* change we make for, for example styling or keyboard handling, has to be done for *both*.
 

Esteban


 


Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

stepharo
In reply to this post by Nicolai Hess

> Maybe I am wrong, but it looks like there are many
> classes and code in rubric that are the same as in the old Text classes.

Yes never said that Rubric is the future. He just improved a bit

> Rub is used in GT and now in the Core image. Shouldn't we clean this up
> before it used everywhere?
>
> Some examples:
>
> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
>
> MorphAnnouncement subclass: #RubMorphAnnouncement
> RubMorphAnnouncment adds nothing
>
> FindReplaceService <-> RubFindReplaceService
> They look very similar, I don't understand why so much code is
> just the same in both, why not extract that into a base class?
> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
> and some many too)
>
> RubEditingState / EditingState.
>
> What this makes it even worse, Rubs class comment doesn't indicate how
> they differ from the old other one.
True.

> It is really difficult to understand,
> - which (Rub)classes were created just because the old TextApi has
> them, but aren't actually used in the current Rubric framework.
> - wich classes are used but could be replaced with the existing one
> (TextLink for example)
> - which classes had to be changed, and therefore only the Rub-classes
> can work with rubric.
> - which classes are similiar named like the old Text classes and share
> some code but may work
> totally different.
>
> (For example TextEditor vs. RubTextEditor there are some methods in
> both that aren't used
> anywhere, it looks like RubTextEditor is just
> - a copy from TextEditor,
> - changed where it was needed
> - unchanged otherwise
Yes. I think that alain did it like that. He just wanted to offer some
behavior for the Moosers.
> Rubric really adds some great new things and if you look at where it
> is used, it
> is really a great step forward, but the code is in a bad state.
> This needs to be cleaned up.
Definitively.
Nicolai
     do you have a list of actions?
     because I would like to do some of them.
We could remove the duplicate. This is what we started to do with
PluggableTextMorph.



Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

stepharo
Yes the situation with rubric is a real mess :(
Ideally I would like to throw away text and rub altogether.
Now I would like to understand what is a good path that minimise
duplication.

In addition I do not understand why certain class extensions are not the
same in both packages.
So I will try to get some time to read code and come with a list of
actions.
If you have some ideas I'm interested.

Stef

>> Maybe I am wrong, but it looks like there are many
>> classes and code in rubric that are the same as in the old Text classes.
>
> Yes never said that Rubric is the future. He just improved a bit
>
>> Rub is used in GT and now in the Core image. Shouldn't we clean this up
>> before it used everywhere?
>>
>> Some examples:
>>
>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
>>
>> MorphAnnouncement subclass: #RubMorphAnnouncement
>> RubMorphAnnouncment adds nothing
>>
>> FindReplaceService <-> RubFindReplaceService
>> They look very similar, I don't understand why so much code is
>> just the same in both, why not extract that into a base class?
>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
>> and some many too)
>>
>> RubEditingState / EditingState.
>>
>> What this makes it even worse, Rubs class comment doesn't indicate how
>> they differ from the old other one.
> True.
>> It is really difficult to understand,
>> - which (Rub)classes were created just because the old TextApi has
>> them, but aren't actually used in the current Rubric framework.
>> - wich classes are used but could be replaced with the existing one
>> (TextLink for example)
>> - which classes had to be changed, and therefore only the Rub-classes
>> can work with rubric.
>> - which classes are similiar named like the old Text classes and
>> share some code but may work
>> totally different.
>>
>> (For example TextEditor vs. RubTextEditor there are some methods in
>> both that aren't used
>> anywhere, it looks like RubTextEditor is just
>> - a copy from TextEditor,
>> - changed where it was needed
>> - unchanged otherwise
> Yes. I think that alain did it like that. He just wanted to offer some
> behavior for the Moosers.
>> Rubric really adds some great new things and if you look at where it
>> is used, it
>> is really a great step forward, but the code is in a bad state.
>> This needs to be cleaned up.
> Definitively.
> Nicolai
>     do you have a list of actions?
>     because I would like to do some of them.
> We could remove the duplicate. This is what we started to do with
> PluggableTextMorph.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Pharo Smalltalk Developers mailing list
Hello all,
Yes we have both PluggableTextMorph and Rubric so it is a mess.
Yes Rubric was a fork, so a lot of code is duplicated.
I would say just wait that all PluggableTextMorph uses are removed
then we will be able to clean-up things.
Now, remember that I was not so excited by Rubric  as the default editor.
Rubric is the past, It should be removed asap with all the crap that it duplicates.
I would not invest to much time in cleaning and commenting it.
Instead, clean, document and implement tests for TxText.

Cheers
Alain


> On 01 Aug 2015, at 11:22, stepharo <[hidden email]> wrote:
>
> Yes the situation with rubric is a real mess :(
> Ideally I would like to throw away text and rub altogether.
> Now I would like to understand what is a good path that minimise
> duplication.
>
> In addition I do not understand why certain class extensions are not the same in both packages.
> So I will try to get some time to read code and come with a list of actions.
> If you have some ideas I'm interested.
>
> Stef
>
>>> Maybe I am wrong, but it looks like there are many
>>> classes and code in rubric that are the same as in the old Text classes.
>>
>> Yes never said that Rubric is the future. He just improved a bit
>>
>>> Rub is used in GT and now in the Core image. Shouldn't we clean this up
>>> before it used everywhere?
>>>
>>> Some examples:
>>>
>>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
>>>
>>> MorphAnnouncement subclass: #RubMorphAnnouncement
>>> RubMorphAnnouncment adds nothing
>>>
>>> FindReplaceService <-> RubFindReplaceService
>>> They look very similar, I don't understand why so much code is
>>> just the same in both, why not extract that into a base class?
>>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
>>> and some many too)
>>>
>>> RubEditingState / EditingState.
>>>
>>> What this makes it even worse, Rubs class comment doesn't indicate how
>>> they differ from the old other one.
>> True.
>>> It is really difficult to understand,
>>> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework.
>>> - wich classes are used but could be replaced with the existing one (TextLink for example)
>>> - which classes had to be changed, and therefore only the Rub-classes can work with rubric.
>>> - which classes are similiar named like the old Text classes and share some code but may work
>>> totally different.
>>>
>>> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used
>>> anywhere, it looks like RubTextEditor is just
>>> - a copy from TextEditor,
>>> - changed where it was needed
>>> - unchanged otherwise
>> Yes. I think that alain did it like that. He just wanted to offer some behavior for the Moosers.
>>> Rubric really adds some great new things and if you look at where it is used, it
>>> is really a great step forward, but the code is in a bad state.
>>> This needs to be cleaned up.
>> Definitively.
>> Nicolai
>>    do you have a list of actions?
>>    because I would like to do some of them.
>> We could remove the duplicate. This is what we started to do with PluggableTextMorph.
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Nicolai Hess
In reply to this post by stepharo


Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <[hidden email]>:
>
> Hello all,
> Yes we have both PluggableTextMorph and Rubric so it is a mess.
> Yes Rubric was a fork, so a lot of code is duplicated.
> I would say just wait that all PluggableTextMorph uses are removed
> then we will be able to clean-up things.
> Now, remember that I was not so excited by Rubric  as the default editor.
> Rubric is the past, It should be removed asap with all the crap that it duplicates.
> I would not invest to much time in cleaning and commenting it.
> Instead, clean, document and implement tests for TxText.

Really? We move from pluggabletextmorph to rubric, just to move again to txtext?

>
> Cheers
> Alain
>
>
> > On 01 Aug 2015, at 11:22, stepharo <[hidden email]> wrote:
> >
> > Yes the situation with rubric is a real mess :(
> > Ideally I would like to throw away text and rub altogether.
> > Now I would like to understand what is a good path that minimise
> > duplication.
> >
> > In addition I do not understand why certain class extensions are not the same in both packages.
> > So I will try to get some time to read code and come with a list of actions.
> > If you have some ideas I'm interested.
> >
> > Stef
> >
> >>> Maybe I am wrong, but it looks like there are many
> >>> classes and code in rubric that are the same as in the old Text classes.
> >>
> >> Yes never said that Rubric is the future. He just improved a bit
> >>
> >>> Rub is used in GT and now in the Core image. Shouldn't we clean this up
> >>> before it used everywhere?
> >>>
> >>> Some examples:
> >>>
> >>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
> >>>
> >>> MorphAnnouncement subclass: #RubMorphAnnouncement
> >>> RubMorphAnnouncment adds nothing
> >>>
> >>> FindReplaceService <-> RubFindReplaceService
> >>> They look very similar, I don't understand why so much code is
> >>> just the same in both, why not extract that into a base class?
> >>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
> >>> and some many too)
> >>>
> >>> RubEditingState / EditingState.
> >>>
> >>> What this makes it even worse, Rubs class comment doesn't indicate how
> >>> they differ from the old other one.
> >> True.
> >>> It is really difficult to understand,
> >>> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework.
> >>> - wich classes are used but could be replaced with the existing one (TextLink for example)
> >>> - which classes had to be changed, and therefore only the Rub-classes can work with rubric.
> >>> - which classes are similiar named like the old Text classes and share some code but may work
> >>> totally different.
> >>>
> >>> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used
> >>> anywhere, it looks like RubTextEditor is just
> >>> - a copy from TextEditor,
> >>> - changed where it was needed
> >>> - unchanged otherwise
> >> Yes. I think that alain did it like that. He just wanted to offer some behavior for the Moosers.
> >>> Rubric really adds some great new things and if you look at where it is used, it
> >>> is really a great step forward, but the code is in a bad state.
> >>> This needs to be cleaned up.
> >> Definitively.
> >> Nicolai
> >>    do you have a list of actions?
> >>    because I would like to do some of them.
> >> We could remove the duplicate. This is what we started to do with PluggableTextMorph.
> >>
> >>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

EstebanLM

On 02 Aug 2015, at 10:24, Nicolai Hess <[hidden email]> wrote:


Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <[hidden email]>:
>
> Hello all,
> Yes we have both PluggableTextMorph and Rubric so it is a mess.
> Yes Rubric was a fork, so a lot of code is duplicated.
> I would say just wait that all PluggableTextMorph uses are removed
> then we will be able to clean-up things.
> Now, remember that I was not so excited by Rubric  as the default editor.
> Rubric is the past, It should be removed asap with all the crap that it duplicates.
> I would not invest to much time in cleaning and commenting it.
> Instead, clean, document and implement tests for TxText.

Really? We move from pluggabletextmorph to rubric, just to move again to txtext?

TxText should be the future because of many reasons… but is unfinished and far from it, so no idea when we will be actually ready. 
in the mean time Rubric is good and finished :) 

Esteban

>
> Cheers
> Alain
>
>
> > On 01 Aug 2015, at 11:22, stepharo <[hidden email]> wrote:
> >
> > Yes the situation with rubric is a real mess :(
> > Ideally I would like to throw away text and rub altogether.
> > Now I would like to understand what is a good path that minimise
> > duplication.
> >
> > In addition I do not understand why certain class extensions are not the same in both packages.
> > So I will try to get some time to read code and come with a list of actions.
> > If you have some ideas I'm interested.
> >
> > Stef
> >
> >>> Maybe I am wrong, but it looks like there are many
> >>> classes and code in rubric that are the same as in the old Text classes.
> >>
> >> Yes never said that Rubric is the future. He just improved a bit
> >>
> >>> Rub is used in GT and now in the Core image. Shouldn't we clean this up
> >>> before it used everywhere?
> >>>
> >>> Some examples:
> >>>
> >>> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink)
> >>>
> >>> MorphAnnouncement subclass: #RubMorphAnnouncement
> >>> RubMorphAnnouncment adds nothing
> >>>
> >>> FindReplaceService <-> RubFindReplaceService
> >>> They look very similar, I don't understand why so much code is
> >>> just the same in both, why not extract that into a base class?
> >>> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow
> >>> and some many too)
> >>>
> >>> RubEditingState / EditingState.
> >>>
> >>> What this makes it even worse, Rubs class comment doesn't indicate how
> >>> they differ from the old other one.
> >> True.
> >>> It is really difficult to understand,
> >>> - which (Rub)classes were created just because the old TextApi has them, but aren't actually used in the current Rubric framework.
> >>> - wich classes are used but could be replaced with the existing one (TextLink for example)
> >>> - which classes had to be changed, and therefore only the Rub-classes can work with rubric.
> >>> - which classes are similiar named like the old Text classes and share some code but may work
> >>> totally different.
> >>>
> >>> (For example TextEditor vs. RubTextEditor there are some methods in both that aren't used
> >>> anywhere, it looks like RubTextEditor is just
> >>> - a copy from TextEditor,
> >>> - changed where it was needed
> >>> - unchanged otherwise
> >> Yes. I think that alain did it like that. He just wanted to offer some behavior for the Moosers.
> >>> Rubric really adds some great new things and if you look at where it is used, it
> >>> is really a great step forward, but the code is in a bad state.
> >>> This needs to be cleaned up.
> >> Definitively.
> >> Nicolai
> >>    do you have a list of actions?
> >>    because I would like to do some of them.
> >> We could remove the duplicate. This is what we started to do with PluggableTextMorph.
> >>
> >>
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

stepharo
In reply to this post by Nicolai Hess

> >
> > Hello all,
> > Yes we have both PluggableTextMorph and Rubric so it is a mess.
> > Yes Rubric was a fork, so a lot of code is duplicated.
> > I would say just wait that all PluggableTextMorph uses are removed
> > then we will be able to clean-up things.
> > Now, remember that I was not so excited by Rubric  as the default
> editor.
> > Rubric is the past, It should be removed asap with all the crap that
> it duplicates.
> > I would not invest to much time in cleaning and commenting it.
> > Instead, clean, document and implement tests for TxText.
>
> Really? We move from pluggabletextmorph to rubric, just to move again
> to txtext?
>

Yes (it if is far from perfect but) now we decided to introduce rubric
because
     TxText is not ready
     people need to be able to have line number and other niceties that
Rubric has.
     Alain told me that it will be probably easier to move from Rub to
TxText than
     from pluggable to TxText.

And as one of the guy with franck doing most of the Pluggable -> Rubric
migration we would have preferred to avoid and jump to TxText directly.

Stef



Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Nicolai Hess


2015-08-04 21:29 GMT+02:00 stepharo <[hidden email]>:

>
> Hello all,
> Yes we have both PluggableTextMorph and Rubric so it is a mess.
> Yes Rubric was a fork, so a lot of code is duplicated.
> I would say just wait that all PluggableTextMorph uses are removed
> then we will be able to clean-up things.
> Now, remember that I was not so excited by Rubric  as the default editor.
> Rubric is the past, It should be removed asap with all the crap that it duplicates.
> I would not invest to much time in cleaning and commenting it.
> Instead, clean, document and implement tests for TxText.

Really? We move from pluggabletextmorph to rubric, just to move again to txtext?


Yes (it if is far from perfect but) now we decided to introduce rubric because
    TxText is not ready
    people need to be able to have line number and other niceties that Rubric has.
    Alain told me that it will be probably easier to move from Rub to TxText than
    from pluggable to TxText.

And as one of the guy with franck doing most of the Pluggable -> Rubric
migration we would have preferred to avoid and jump to TxText directly.


OK, so the plan is:
1. replace old with rubric
2. remove old
3. cleanup rubric (maybe)
4. move to txtext

is the 4th step only doable for bloc, or do we want to use txtext in morphic too?

nicolai



 

Stef



Reply | Threaded
Open this post in threaded view
|

Re: cleanup rubric

Tudor Girba-2
TxText should only be considered for Bloc. This is where the future is, and we should invest our effort to build that future.

Doru

On Wed, Aug 5, 2015 at 9:16 AM, Nicolai Hess <[hidden email]> wrote:


2015-08-04 21:29 GMT+02:00 stepharo <[hidden email]>:

>
> Hello all,
> Yes we have both PluggableTextMorph and Rubric so it is a mess.
> Yes Rubric was a fork, so a lot of code is duplicated.
> I would say just wait that all PluggableTextMorph uses are removed
> then we will be able to clean-up things.
> Now, remember that I was not so excited by Rubric  as the default editor.
> Rubric is the past, It should be removed asap with all the crap that it duplicates.
> I would not invest to much time in cleaning and commenting it.
> Instead, clean, document and implement tests for TxText.

Really? We move from pluggabletextmorph to rubric, just to move again to txtext?


Yes (it if is far from perfect but) now we decided to introduce rubric because
    TxText is not ready
    people need to be able to have line number and other niceties that Rubric has.
    Alain told me that it will be probably easier to move from Rub to TxText than
    from pluggable to TxText.

And as one of the guy with franck doing most of the Pluggable -> Rubric
migration we would have preferred to avoid and jump to TxText directly.


OK, so the plan is:
1. replace old with rubric
2. remove old
3. cleanup rubric (maybe)
4. move to txtext

is the 4th step only doable for bloc, or do we want to use txtext in morphic too?

nicolai



 

Stef






--

"Every thing has its own flow"