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 <estebanlm@gmail.com> wrote:

On 29 Jan 2014, at 15:50, phil@highoctane.be 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 <pavel.krivanek@gmail.com> 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