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.