> On 02 Aug 2015, at 10:24, Nicolai Hess <[email protected]> wrote: > > > Am 02.08.2015 10:09 vorm. schrieb "Alain Plantec" <[email protected] > <mailto:[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? > 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 <[email protected] > > > <mailto:[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. > > >> > > >> > > > > > > > >
