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>:
>
> 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.
> >>
> >>
> >
> >
>