[Ann] Cuis 4.1 is released

> Hi Folks,
>
> Cuis 4.1 is available at http://www.jvuletich.org/Cuis/Index.html . Biggest news is in the Morph hierarchy. Ivars 'bounds' and 'fullBounds' are gone! All coordinates are now Float and relative to the owner morph. This is part of the transition to Morphic 3. The drawing engine is still BitBlt and the UI is not scalable yet, but Morphic 3 is now much closer.
>
> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

>> The idea is that location (position, angle, scale, and/or whatever
>> specification of how a Morph is placed in its owner) should be completely
>> separated from attributes such as extent. Any morph needs a location. But
>> not all morphs need an extent. For example, a polyline, or Bezier path would
>> be specified by corners or control points. Not by extent. In addition, the
>
> That makes sense.  But isn't a rectangular extent still useful for
> quick identification of damaged areas, e.g., to support efficient
> redraw?
>

> Quoting Chris Muller <[hidden email]>:
>
>>> The idea is that location (position, angle, scale, and/or whatever
>>> specification of how a Morph is placed in its owner) should be completely
>>> separated from attributes such as extent. Any morph needs a location. But
>>> not all morphs need an extent. For example, a polyline, or Bezier path
>>> would
>>> be specified by corners or control points. Not by extent. In addition,
>>> the
>>
>>
>> That makes sense.  But isn't a rectangular extent still useful for
>> quick identification of damaged areas, e.g., to support efficient
>> redraw?
>>
>
> That´s a problem for the Morphic machinery, not a problem for Morphs and
> their programmers. Somebody coding her morphs only needs to care about
> appareance and behavior. Not about low level problems such as damaged areas.
>
> The underlying machinery (World, Canvases, Hand, etc) need to know about
> damaged areas and such. These are usually in Display coordinates, not in
> Morph coordinates. (Remember that the objective is to build a ZUI). Even
> there, a rectangle (aligned with Display or surface edges) is not the only
> alternative... Apple´s QuickDraw used regions for this in 1982!
>
> Squeak´s Morphic merges all this at a single level. The initial design is
> simpler, but to support rotation and scaling (via TransformMorphs and
> WarpBlt), one consequence is terrible visual quality, because drawing is
> done in fake coordinates, and it´s bitmaps that are scaled, not drawing
> operations. In addition, these fake coordinates don´t really make much
> sense, and the resulting object mashups are very hard to inspect and debug.
>
> Fixing this mess is one of the central objectives of Cuis and Morphic 3.
>
>
> Cheers,
> Juan Vuletich
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

> On Mon, Dec 17, 2012 at 12:36 PM,  <[hidden email]> wrote:
>> Quoting Chris Muller <[hidden email]>:
>>
>>>> The idea is that location (position, angle, scale, and/or whatever
>>>> specification of how a Morph is placed in its owner) should be
>>>> completely
>>>> separated from attributes such as extent. Any morph needs a location.
>>>> But
>>>> not all morphs need an extent. For example, a polyline, or Bezier path
>>>> would
>>>> be specified by corners or control points. Not by extent. In addition,
>>>> the
>>>
>>>
>>> That makes sense.  But isn't a rectangular extent still useful for
>>> quick identification of damaged areas, e.g., to support efficient
>>> redraw?
>>>
>>
>> That´s a problem for the Morphic machinery, not a problem for Morphs
>> and
>> their programmers. Somebody coding her morphs only needs to care about
>> appareance and behavior. Not about low level problems such as damaged
>> areas.
>>
>> The underlying machinery (World, Canvases, Hand, etc) need to know about
>> damaged areas and such. These are usually in Display coordinates, not in
>> Morph coordinates. (Remember that the objective is to build a ZUI). Even
>> there, a rectangle (aligned with Display or surface edges) is not the
>> only
>> alternative... Apple´s QuickDraw used regions for this in 1982!
>>
>> Squeak´s Morphic merges all this at a single level. The initial design
>> is
>> simpler, but to support rotation and scaling (via TransformMorphs and
>> WarpBlt), one consequence is terrible visual quality, because drawing is
>> done in fake coordinates, and it´s bitmaps that are scaled, not drawing
>> operations. In addition, these fake coordinates don´t really make much
>> sense, and the resulting object mashups are very hard to inspect and
>> debug.
>>
>> Fixing this mess is one of the central objectives of Cuis and Morphic 3.
>>
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

>
> I don't have any answers. But I'm willing to think and discuss, to find
> the best way, for people to have freedom to pick their own balance between
> between compatibility, features,
> evolutivity, etc. All this, enabling reuse and reducing duplication of
> efforts...
>
> Cheers,
> Juan Vuletich
>

> On Mon, Dec 17, 2012 at 04:19:54PM -0300, [hidden email] wrote:
>  
>>> Extremely impressive Juan.  Congratulations.  Morphic3 is something
>>> that sounds worth breaking backward-compatibility in Squeak if it
>>> would ever possible to run there.
>>>      
>> Thanks Chris. I still need to work on M3 for several months before it is
>> usable. I hope to be able to release some alpha code sooner. In any case,
>> what you say opens many interesting questions. Cuis was forked just for
>> technical reasons (not social or personal), and I think it still is a
>> 'Squeak distribution'.
>>    
>
> To me, Cuis represents the best of Squeak: Elegant simplicity, high quality,
> and a sense of vision. While I personally spend most of my time with Squeak
> trunk, I really do appreciate Cuis.
>  

>> If there is enough interest in the Squeak community, the bigger issue is
>> how to deal with multiple distributions. Does Squeak need to support just
>> one distribution? Can it handle several? Or maybe there should not be an
>> 'official squeak', but a set of pieces from where anybody could build her
>> own, personalized Squeak?
>>    
>
> Good questions. And if we can do these things, we should also be able
> to do a better job of supporting and enabling Etoys, Scratch, and other
> 'distributions'. Ultimately perhaps Cuis may provide a better way of doing
> these things, as it seems to be inherently simpler and smaller than the
> 'official Squeak' itself.
>
> Dave
>  

>> I don't have any answers. But I'm willing to think and discuss, to find
>> the best way, for people to have freedom to pick their own balance between
>> between compatibility, features,
>> evolutivity, etc. All this, enabling reuse and reducing duplication of
>> efforts...
>>
>> Cheers,
>> Juan Vuletich
>>
>>