[Morphic] Some challenges for the morphic team

[stephane ducasse]

>> If you  improve something we will incorporate it.
>> I would love to help. Now my time is so short that I cannot even   
>> program.
>
> You have always been of great help to every squeaker. It is me who
> doesn't have enough time and energy for working more on Squeak.

but if you do not have that much time, why not contributing in small  
increment
base to 3.9 :)

>>> I also believe that we are having serious problems in setting the  
>>> direction for Squeak.
>>> Even though we all agree we want a small basic image with  
>>> optional  stuff in SqueakMap, every release gets bigger and bigger.
>>
>> But where are the cool shrinkers? Where is the code that I can   
>> unload. Did you have a look at the scriptloader?
>> There is a category of methods for checking which package can  
>> unload (just unload not even cleanly). So do you
>> think that if you provide some repakaging we will ignore it? No so  
>> what?
>
> The fact is that it is muuuuch easier to simply remove the stuff I  
> don't want
> from my image, than making it possible to unload (and reload)  
> packages.

:)

> It only makes sense to work on the latter if enough people really  
> uses it
> to justify the effort. I believe this is not the case. Besides, I  
> don't have the
> time and energy to finish the work I started in Morphic /  
> MorphicExtras /
> Etoys.

OK

> So, if that was the case (of course I don't think so), what we  
> would be
> lacking is a means to decide that something is not interesting  
> anymore, and
> remove it from the image.

???

> I didn't put it correctly. The main objective is not cleaning but
> redesigning. (please see at the end). The result should be a new
> Morphic package that could be loaded by those who don't care
> about compatibility with existing applications (Etoys, etc), but that
> most likely, the community would reject as an official replacement
> for not being back compatible.

OK

> Not at all. I would also miss some small fixes, but not the bigger
> improvements. It is a matter of personal interests and taste.
> At my job, I work in VisualSmalltalk. Compared to current Squeak, it
> is very small. The only thing I really miss there is Morphic and the
> Method Finder. I really believe in Dan's Personal Mastery principle.

Sure me too.
But cut from 3.9

>
> I understand and agree with you, except for the first phrase. Somebody
> working in his own image on the stuff he needs, is in no way "nothing
> happening". If his work can be used by others, much better. But if  
> not,
> it doesn't mean it was useless. For instance, remember PhotoSqueak.
> I wrote that stuff for a class lab project. I also published it in  
> the hope
> that somebody could use it. It was never considered for inclusion  
> in the
> image, but if anybody wants to do Image Processing in Squeak, he
> knows he can reuse my work. That's good enough for me.

Sure this is not want I meant.
But if you fix bugs in 3.7 because you will face it. Then may be we  
will not
be able to use them.
>

> Because I have a lot of work already done in my 3.7 image! You know
> how hard it is to move your stuff to each new Squeak version.
>
I know

> The difference with ToolPlus is that I'm not doing an improvement to
> Squeak. What I'm doing is not meant to be compatible with other
> packages in the image. I don't want to spend the little time I have on
> compatibility issues. I want to express my ideas in a design, to  
> test them.
> If they are good, they will be used by others.

Ok

> What follows are some ideas for a redesign of Morphic. Some of them  
> were suggested by John Maloney (the main implementor of Morphic).  
> Others are old ideas of mine. I did my first experiments on them in  
> C, way before knowing about Smalltalk.

:)

>
> - Every Morph defines a space and a coordinate system. His #drawOn:  
> method and the location of his submorphs are expressed in his own  
> coordinate system.
>
> - The coordinate systems are 2D but are not restricted to  
> Cartesian. Others are polar, logarithmic Cartesian, and hyperbolic  
> and map-like projections. The basic one is Cartesian with Float  
> coordinates.
>
> - There is no concept of pixel. Going from pixels to general  
> coordinate systems is like going from bits to objects. All the gui  
> is independent of pixel resolution. All the rendering is antialiased.
>
> - A coordinate system + its position in an owner + its extent in an  
> owner + its rotation angle in an owner together specify a  
> translation of coordinates to the owner's space and coordinate system.
>
> - The Morph hierarchy is NOT a shape hierarchy. Morphs don't have a  
> concept of a border or color. There is no general concept of  
> submorph aligning.
>
> - The existing Morph hierarchy is renamed as OldXxxx. Anyway, most  
> of them are deleted. Only kernel, a few basic, and the programming  
> tools remain.
>
> - Old Morphs and new Morphs can live together in a World.
>
> Any comment on all this is welcome.



Would be good :) but lot of work?
>
> Cheers,
> Juam
>