Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <[email protected]>: > > 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 <[email protected]> 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. > >> > >> > > > > >
