[Cuis] Newbie question

H. Hirzel hannes.hirzel at gmail.com
Wed May 13 15:32:44 CDT 2015 

P.S. I hope that Cuis has not changed to much that you run into
compatibility issues. As I wrote I did not do a retest of it in the
last 12 months.

On 5/13/15, 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
>>
>

More information about the Cuis mailing list