cleanup rubric
Locked
 
|
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.MorphAnnouncement subclass: #RubMorphAnnouncement FindReplaceService <-> RubFindReplaceService and some many too) 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 <[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. > > > > > > |
|
|
2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <[hidden email]>: Hi, 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 |
|
|
In reply to this post by Nicolai Hess
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
|
|
|
In reply to this post by EstebanLM
2015-07-31 12:55 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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*.
|
|
|
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. > 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 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. > > |
Re: cleanup rubric
|
|
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. >> >> > > |
|
|
In reply to this post by stepharo
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
|
|
|
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 |
|
|
2015-08-04 21:29 GMT+02:00 stepharo <[hidden email]>:
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
|
|
|
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:
|
| Free forum by Nabble | Edit this page |