July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] cleanup rubric

by Nicolai Hess

2015-07-31 12:55 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> 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. >> > > 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 :( > 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*. > > Esteban > > > > > >

July 31, 2015

Re: [Pharo-dev] cleanup rubric

by Marcus Denker

> On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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. > > But the duplication makes it *really* difficult to clean up Rubric from the old TextEditor API. > > 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

July 31, 2015

Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

by Marcus Denker

> On 15 Jul 2015, at 10:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > the slides for my ESUG talk are online: > > http://www.slideshare.net/MarcusDenker/reflection-in-pharo5 <http://www.slideshare.net/MarcusDenker/reflection-in-pharo5> > > Video is online, too: https://www.youtube.com/watch?v=Ik539CtjtTI <https://www.youtube.com/watch?v=Ik539CtjtTI> Marcus

July 31, 2015

Re: [Pharo-dev] why I can't minimise gtinspector?

by Andrei Chis

I still have them in my image. Can you send a screenshot? Cheers, Andrei On Fri, Jul 31, 2015 at 12:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > thatâ¦ I realised minimise/maximise options are gone from gtinspector > windowâ¦ is there a reason? > > Esteban >

July 31, 2015

why I can't minimise gtinspector?

by Esteban Lorenzano

thatâ¦ I realised minimise/maximise options are gone from gtinspector windowâ¦ is there a reason? Esteban

July 31, 2015

Re: [Pharo-dev] cleanup rubric

by Esteban Lorenzano

> On 31 Jul 2015, at 12:35, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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. > > 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 > >

July 31, 2015

Re: [Pharo-dev] cleanup rubric

by Nicolai Hess

2015-07-31 12:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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. > But the duplication makes it *really* difficult to clean up Rubric from the old TextEditor API.

July 31, 2015

Re: [Pharo-dev] cleanup rubric

by Esteban Lorenzano

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 <nicolaihess(a)web.de> 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. > > > > > >

July 31, 2015

cleanup rubric

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

July 31, 2015

Re: [Pharo-dev] rubric and text styler

by Nicolai Hess

2015-07-31 10:02 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > it is a subclass to change one methodâ¦ we should make it (as a first hack) > a subclass > of the RB based SHRBTextStyler. Maybe this just works? I will try. > > Going already now for RB I think is good as the Styler for TxText is based > on RB, too. > (it is a bit different but if we get SHRBTextStyler to work, we will have > the knowledge > to make the TxText one working, too) > OK, that sounds like a good plan. nicolai > > > On 31 Jul 2015, at 09:59, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > What is the plan for Rubric and its text styler? > > > > There was some work to enhance and use RB-based styler (SHRBTextStyler). > > This seems useless because more and more textcomponents are replaced > > with rubrics, and rubric uses its own styler. > > > > do we stay with rubrics styler ? > > > >

July 31, 2015