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.
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 <nicolaihess@web.de> 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.
2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
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.
On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess@web.de> wrote:
2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: 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
2015-07-31 12:55 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess@web.de> wrote:
2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
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
On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess@web.de> wrote:
2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: 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
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.
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.
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 <stepharo@free.fr> 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.
Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <alain.plantec@yahoo.com>:
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 <stepharo@free.fr> 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.
On 02 Aug 2015, at 10:24, Nicolai Hess <nicolaihess@web.de> wrote:
Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <alain.plantec@yahoo.com <mailto:alain.plantec@yahoo.com>>:
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 <stepharo@free.fr <mailto:stepharo@free.fr>> 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.
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
2015-08-04 21:29 GMT+02:00 stepharo <stepharo@free.fr>:
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
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 <nicolaihess@web.de> wrote:
2015-08-04 21:29 GMT+02:00 stepharo <stepharo@free.fr>:
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
-- www.tudorgirba.com "Every thing has its own flow"
participants (6)
-
Alain Plantec -
Esteban Lorenzano -
Marcus Denker -
Nicolai Hess -
stepharo -
Tudor Girba