Yeah, time. Not enough not enough not enough. Who is going to be at #FOSDEM on Saturday?
Phil On Wed, Jan 29, 2014 at 3:58 PM, Esteban Lorenzano <[email protected]>wrote: > > On 29 Jan 2014, at 15:50, [email protected] wrote: > > Know what would be making it really useful? > > A nice dark theming feature. > > Yeah, that's not Morphic-Core, but currently, this aspect makes the whole > thing feel stuck in the 90's. > > Esteban, did you had any luck with that? > > > not yet :( > time time time time :(( > > Doru was going to help on that too... but I think he is the same situation > as me. > > Esteban > > > Phil > > > On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek > <[email protected]>wrote: > >> >> >> >> 2014-01-29 Hilaire Fernandes <[email protected]> >> >>> 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 >>> >>> >>> >> > >
