State of morphic ( long reply to Sig from [UI] Re: UI plan, my thoughts thread)

[UI] Re: UI plan, my thoughts

Hi Sig,

Thanks for your interest and thanks for your
questions:

>What was fruits which came from morphic team before
you stopped developing?

I’ll let Juan answer this too.
 
The work I did which got into 3.9 was
On polygons to smooth out smooth curves and then add
optional corners to mixed morphs.
 
On buttons and sliders to fix the targeting
mechanisms. This is a key reason why Nouri can do his
Easy Morphic Gui’s now but not before.

There is now a way to take a snapshot of any morph and
get a thumbnail image that can be resized and which
will provide on demand a popup image of the original.

There are fixes to internal logic for selecting list
items. And double clicking a selected item in an
inspector now works as it should.

Dans old double click demonstrater has been replaced
with an updated version.

A major cause of off by one errors and rounding and
truncation errors have been identified and language
has been introduced to prepare for fixing them.

Lots of little fixes.


>And what is the current state of morphic package.

There are two possible questions here.

1) What is the state of morphic as a whole once it is
loaded and in the image?

2) The other is what is the state of the morphic
packaging as mcz pieces in the repositories? They need
separate answers.

Morphic is there and it works in its essential.

There are bugs and clutter and annoyances. They don’t
interfere with most uses.
Morphic code could benifit from some code review and
refactoring. For large values of some. :-)

>Does it have any maintainers?

Yes it does. At least one capable one in me. There are
others who are adding good things to it. And there of
course are the scratch and olpc projects which will be
sources of debugged code for future enhancements and
widgets.

I’ll cover future directions in another report.

>I have to admit that morphic in its current state
requires a clean up.

Yes. It requires a review and clean up. It does not
require everything to be cleaned up all at once. Slow,
steady, progress counts in the long run. And will
often produce better results than massivly disruptive
efforts.
 
>Maybe starting from a scratch is a good decision.


No. Starting from scratch is a terrible decision.

Especially when you consider what you are proposing is
that someone who is not intimately familiar with
morphic start from scratch and build something that is
as complex and good as morphic is today. Without the
experience to avoid the mistakes that morphic has
encountered.

Tweak is what you come out with when the most
experienced squeak programmer rewrites the interface.
With support and with a patron to pay salaries and
bills.

Juans Morphic 3.0 is an experienced squeak programmers
efforts in creating something good based on past
experiences.  As a Hobby with only self funded
resources.  With out compatibility with current tools
or the ability to use what is as scafolding, it may or
may not make it off the ground.  It is not something
one can hold ones breath for.  It can not be ready
anytime soon and it will not be easy to integrate when
it does come out.

Better to start from the annoyances that morphic
provices and repair those; keeping the remaining
framework in place; and using the exquisite tools that
squeak provides to make rapid progress, more and
better mistakes and more and better learning
experiences.

I am leaving out Gary’s nearly published work, the UI
builder that got into 3.9, Nouri’s gui builder and the
potential of lambda message sends which are all
important to squeak and morphic’s future.
 

>Lately in squeak-dev there was note of someone who
doing clean-up ,
>called minimal morphic. He's task was to remove
dependencies from
>Etoys in basic Morphs package code.

This sounds like Juan’s efforts.  The goal while
laudable is in practice somewhat unsellable.  What
benifit is gotten by having less ability in squeak or
morphic? And no matter how careful one is in
minimizing morphic there will be things that you want
that inevitalbly will get broken in an lagre
minimization effort. Then you will find your
self-funded resources being spent to recreate the
stuff you already had.

Unless there is a real necessity massive minimization
is not something others will wish to adopt.

Which covers the state of morphic.
Now the other piece the state of morphic MC packages.

The current morphic--.mcz package is in size over a
megabyte.
This is for just the morphic mcz package. Morphic
extras and Etoys are separate packages ( I haven’t
looked into their size yet). The size is significant.
MC maintainence suffers non-linearly with size. So
maintaining Morphic in MC is not on for those with
limited resources.  (of time and patience).  I do my
fixes with changesets and goodie fileouts.  And relie
on more resourced help (Edgar is a brick) to get these
into the packages.

The packages also need rethinking and reforming.
Currently simple fixes are likely to touch several
packages at once. The first attempts at packages may
not have found the right decouplings between packages.
 Also how to you repackage glue once its been
deployed?

I read a lot of Christopher Alexander these days.  In
the context of image maintence I find the packaging of
fixes to be an out of sequence step. I also find that
the mcz tool lacks sensativity to levels of scale.
That is the very first requirement of a good
transformation process.

I mention this here because this one change of tool
has made morphic maintence a much more difficult task
to find resources for. (Though I must admit I have
found ways of maintaining morphic that avoids my
involvement with the tool.)

So part of morphics state is waiting for the tools to
become more rational and better suited for squeak and
the tasks of squeak development.

And another part is trying to get the morphic package
better set to be maintained by the current tools.

I believe that small whitling steps. Removing leaf
classes after understanding their presence is the only
way forward that insures morphic continues to work as
we make is smaller.

Then with a better familiarity the natural
decompostion and decouplings can be found.

Repair, when done right is implosive, you are left
with fewer pieces that work better together and do
more that the old buggy stuff. And that direction has
the full support of my curiosity.

Hth

Yours in curiosity and service, --Jerome Peace

***
>Igor Stasenko siguctua at gmail.com
>Sun Aug 26 13:56:40 UTC 2007
>
>
>On 26/08/07, Juan Vuletich <juan at jvuletich.org>
wrote:
>> Hi Bert,
>>
>> Bert Freudenberg wrote:
>> > On Aug 25, 2007, at 19:27 , Juan Vuletich wrote:
>> >
>> >>  I found little support for that from the Board
>> >
>> > You make that sound like the Board opposed any of
this. This is not
>> > the case, the Board so far has stayed out of
*any* technical advise,
>> > it is leaving these to the teams.
>> That's true.
>> > If anything, there was (unfortunately) little
support from the Morphic
>> > Team.
>> That's not so true. I was the team leader, so
support from the Morphic
>> Team basically meant support for myself. But what I
wanted to do would
>> have broken badly back compatibility, and would
have caused serious
>> trouble to Etoys users. It was a risky decision,
with good and bad
>> consequences for many people. Too much for the
Morphic Team (i.e. for
>> myself) to make. That's why I asked the community
and the Board for
>> support. Basically, the Board didn't take a
position, and the community
>> (almost all who said something) were against it.
>>
>
>What was fruits which came from morphic team before
you stopped developing?
>And what is the current state of morphic package,
does it have any
>maintainers?
>I have to admit that morphic in its current state
requires a clean up.
>Maybe starting from a scratch is a good decision.
>Lately in squeak-dev there was note of someone who
doing clean-up ,
>called minimal morphic. He's task was to remove
dependencies from
>Etoys in basic Morphs package code.
>
>Maybe first, before new team can start doing
something new, its better
>to make an overview to think about what is done, what
is started but
>not finished and what is need to be done?
>
>> I understand this, and it's ok. It is just that
after that, I started
>> doing all this in my own fork, the Morphic 3.0
image.
>>
>
***



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/ 
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic