[Cuis] Newbie question

[H. Hirzel]

Hari,

A suggestion:

Maybe you can write some learner's notes written from your perspective
(questions and answers) we may add then to as a file to

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/tree/master/Documentation

Tentative title

Some suggestions for Cuis Morphic experiments for learners.

BTW here a have a series of Layout experiments which were fine one year ago

https://github.com/hhzl/Cuis-Add-Ons/blob/master/Add-Ons-LayoutDemo.pck.st

I have not checked if they are still fine with the current Cuis. The
layout experiments start very simple and one builds on the other.

--Hannes



On 5/13/15, Hari Balaraman <hbalaraman at gmail.com> wrote:
> Hi Juan,
> Thank you for your reply.
> My replies to specific points are inline.
>
>> On May 13, 2015, at 9:53 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>>
>> Hi Hari,
>>
>> I think it is great that you experiment. For sure you'll learn and have
>> fun. And maybe you can contribute useful code.
>
> Hopefully soon! At this point, the only benefit to you is seeing how a
> newbie tackles the system.
>
>>> On 5/12/2015 7:19 PM, Hari Balaraman wrote:
>>> Hi Ken,
>>>
>>> Thanks for your reply. It came in just as I finished a slightly improved
>>> version of the code I presented earlier. This code moves the embedded
>>> morph in relation to the enclosing morph (by moving the centre of the
>>> embedded morph in proportion to the centre of the container morph.) I
>>> moved the variables and methods I used in the attached test class
>>> (including the stepAt method) upstream to RectangleLikeMorph to test and
>>> attach some screenshots (of that testing) when I embed an EllipseMorph
>>> into a BorderedRectMorph and switch ‘proportionalresize' off and on
>>> within the embedded morph while resizing the container morph. Thus, I
>>> maintain control over layout on a per embedded morph basis.
>>> ...
>>> I don’t yet have a sense of what load the additional variables and
>>> methods put on the system when added at the top of the hierarchy (other
>>> than my laptop fan not going insane), but since the tax is on the
>>> individual embedded morph for maintaining layout, I hope it is small.
>>>
>>> Best regards,
>>>
>>> Hari
>>>
>>
>> Well, the cost is not so much loading the system, but the extra stuff that
>> everybody needs to keep in our heads.
>>
>> Besides, there are yet more possibilities, besides Layouts in Ken's
>> example. For instance, in a workspace evaluate:
>>
>>     g _ RectangleLikeMorph new openInWorld.
>>     f _ EllipseMorph new.
>>     g morphExtent: 400 at 400; color: Color orange.
>>     g addMorph: f.
>>      f morphPosition: 50 at 50; color: Color blue.
>>     g morphPosition:70 at 70.
>>
>> Then, in the same workspace, try:
>>     g rotation: 0.0 scale: 0.5.
>>
>> or:
>>     g rotation: 0.0 scale: 2.
>>
>> When Morphic3 is ready, this will also work:
>>     g rotation: 1.0 scale: 1.0.
>> The idea is that each morph can define its own coordinate system.
>
> That does sound interesting.
> I'd like to explore how morphs can be aware of and organise themselves
> around other morphs as peers (either when told about them or not.) As
> organic an approach as possible.
>
>> Cheers,
>> Juan Vuletich
>>
>>
>>>>> On May 12, 2015, at 5:52 PM, Ken.Dickey <Ken.Dickey at whidbey.com>
>>>>> wrote:
>>>>>
>>>>> On Tue, 12 May 2015 00:24:06 -0400
>>>>> Hari Balaraman <hbalaraman at gmail.com> wrote:
>>>>>
>>>>> Hi Juan et al,
>>>>>
>>>>> I’ve been pondering on how to position and size morphs (based on Juan's
>>>>> comment below about automatic layout in an earlier exchange) without
>>>>> having an intermediate layer of layoutMorphs.
>>>>>
>>>>> Attached is a fileout of a test class with a class method “example 1”
>>>>> showing a rectangle that varies its size based on its owner (I’m also
>>>>> writing the method to reset the location of a morph if it wishes to be
>>>>> remain in the same location relative to the midpoints of two sides of
>>>>> the enclosing morph.)
>>>>>
>>>>> This way a morph can be positioned and at any time sent a message to
>>>>> relocate or resize itself based on its then owner. That way there are
>>>>> only two actors, the morph and its owner, and a morph knows (based on
>>>>> two messages, whether it should maintain its relative place and size
>>>>> within its owner. Although I have got a bit of the hang of
>>>>> layoutMorphs, I’m exploring whether positioning and repositioning a lot
>>>>> of elements in my UI may be easier with this approach.
>>>>>
>>>>> I was wondering what you think of this approach.
>>>> Hari,
>>>>
>>>> I think we all need to get more experience building things to see what
>>>> works and is as simple as we can make it.
>>>>
>>>> Please continue to build things and share them!
>>>>
>>>> Here is the example using aLayoutMorpk and a LayoutSpec.
>>>>
>>>> example2
>>>> "
>>>>    self example2.
>>>> "	| f g |
>>>> 	g := LayoutMorph initializedInstance openInWorld.
>>>> 	g padding: 0.5. "center"
>>>> 	f := RectangleLikeMorph new.
>>>> 	g morphExtent:400 at 400; color: Color orange.
>>>> 	g addMorph: f layoutSpec: (LayoutSpec proportionalWidth: 0.25
>>>> proportionalHeight: 0.25).
>>>> 	f morphPosition:150 at 150; color: Color blue.
>>>> 	g morphPosition:70 at 70.
>>>>
>>>>
>>>> Cheers,
>>>> -KenD
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>