[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?
Ill 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 Guis 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 dont 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.
Ill 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 Garys nearly published work, the UI builder that got into 3.9, Nouris gui builder and the potential of lambda message sends which are all important to squeak and morphics 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 Juans 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 havent 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/
Jerome, thank you for good overview. My personal interest, as you may know, is the graphics part of morphic. I'm developer of GLMorphic project, which draws all morphs using openGL.
There are some things which i wish to be cleaned up / rethought. First is the hard-wiring with Forms and blitting: i don't like, that many morphs relying on fact, that display surface represented by rectangular area of pixels (Forms), and can be manipulated directly with blitting operations. This is what i want to be avoided at all, and to draw all morphs using calls to canvas only.
Second is font rendering and paragraphs rendering. Most of morphs use paragraphs to hold text, and paragraphs using special class like CanvasCharacterScanner which containing very complex and ugly (IMHO) code to render text. I don't know why simple text rendering became so complex in respect to rendering paragraphs. And i wish this to be simplified someday. Personally i don't think that message #paragraph:bounds:color: need to be included in Canvas protocol, since its too complex to pass in single command and always splitting to more basic commands like draw string.
-
Igor Stasenko -
Jerome Peace