Re: [Pharo-dev] process to collaborate on cleaning morphic

[btc]

I was going to say... As an alternative to nibbling at the edges of Morphic, now that we have PharoKernel3.0-FromTopShrink, which presumably unloads Morphic, I wonder what is involved in loading Juan's SimpleMorphic [1] & [2] ...but actually it looks like SimpleMorphic was already integrated in 2010 [3]. (I'd be curious if someone could provide a summary of that.)   However perhaps the idea still applies since 2010 Juan seems to have improved Morphic further [4]. btw - it looks like it has a dark theme like some people have been asking for [5] [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-November/035248.html [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-November/035247.html [3] https://code.google.com/p/pharo/issues/detail?id=3210 [4] http://www.jvuletich.org/Cuis/CuisReleaseNotes.html [5] http://news.squeak.org/2011/01/15/cuis-3-0-released/ cheers -ben Pavel Krivanek wrote: 2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com> Le 28/01/2014 18:41, Pharo4Stef a écrit : > this is years since I clean Morphic (may be I’m that good at it) but this is important to > go step by step. So I would really like to get a list of simple actions. > Do you have an idea? What about a brutal scheme, independent of all code quality considerations: - dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do:         i. unmark it as deprecated         ii. move it in external package         iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy. I guess Steph already did some of this in the past. The idea is you don't want to refactor unused code, right? I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph.  We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor.  It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal. Cheers, -- Pavel   -- Dr. Geo http://drgeo.eu