[Cuis] Newbie question

Hari Balaraman hbalaraman at gmail.com
Wed May 13 15:45:08 CDT 2015 

No plague! Hari, put down those antibiotics....
Seriously, thanks much for the suggestions. 
H



> On May 13, 2015, at 4:31 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> 
> I suggest that you really have a look at
> 
> https://github.com/hhzl/Cuis-Add-Ons/blob/master/Add-Ons-LayoutDemo.pck.st
> 
> They are _really_ basic. No plague....
> 
> At least you learn for example how to put a SystemWindow around your
> morphs and have a tool bar. Which is a good thing to know.
> 
> HH
> 
>> On 5/13/15, Hari Balaraman <hbalaraman at gmail.com> wrote:
>> Hi Hannes,
>> Thank you for your reply. My responses are inline.
>> Best regards,
>> Hari
>> 
>>> On May 13, 2015, at 4:01 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>> 
>>> 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
>> 
>> I really like that idea. I was thinking the same thing this afternoon. They
>> will also serve to remind me of the things I (assume) I am learning. Will
>> get back to you on that.
>> 
>>> 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.
>> 
>> Thanks! I will check them out. Right now I am trying to avoiding layouts
>> (and innerpluggablemorphs etc.) like the plague :) and rebuilding my UI with
>> the most basic pieces and looking to switch behaviour on and off as
>> required.  I like direct access when it comes to morphs and submorphs (and a
>> sort of WYSIWIG in the ownership chain) and am still very suspicious of the
>> value of having multiple levels of morphs contained in each 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
>>> 
>>> _______________________________________________
>>> Cuis mailing list
>>> Cuis at jvuletich.org
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>> 
>> 
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

More information about the Cuis mailing list