Solitaire updated for 2203
Locked
123
123
 
|
I updated Solitaire to work with asynchronous animation. Solitaire used to use synchronous animation, which has been removed.
The main problem to be solved is how to interleave animation with control logic. For example, in auto-moving cards from columns to piles, one wishes to check each card column and if any card has been moved to a pile, check each column again. The style I used here, CPS (Continuation Passing Style), makes control flow explicit. Instead of returning, the last thing code does is invoke a closure passed in which does "the next thing". This lets an asynchronous animation, as its last step, "pick up where it left off", e.g. to continue looping through card columns, checking for legal moves. [Note CardTable Class>>cpsOverColl:do:next: and class side examples]. This is a style experiment. I am not totally happy with this style as it can be painful to debug. Perhaps we should re-introduce the Continuation Class to capture continuations directly. In any case, we have Solitaire working again with the current Cuis version. Enjoy! -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Solitaire updated for 2203
|
Very nice work Ken!
You managed to do the animation and game logic, interleaved with normal World cycling, and without any need to mess with "private" Morphic internals. Impressive. I'm not sure, but I have a feeling that making 'mainLoop' and 'pilesLoop' into separate methods might make debugging a bit easier. I also believe that once you leave the world of simple lineal sequencing of calls and returns, debugging will always get trickier, just as design and coding. At least, your code is entirely predictable and deterministic. I remember the non-deterministic signaling of events in Tweak, and how harder debugging was there, when you could not even repeat the UI steps, and expect code to run the same. The biggest value I see in this code of yours is that it well teach the rest of us how to do it, when we need to. Thanks, Juan Vuletich On 3/21/2015 1:40 PM, Ken.Dickey wrote: > I updated Solitaire to work with asynchronous animation. Solitaire used to use synchronous animation, which has been removed. > > The main problem to be solved is how to interleave animation with control logic. For example, in auto-moving cards from columns to piles, one wishes to check each card column and if any card has been moved to a pile, check each column again. > > The style I used here, CPS (Continuation Passing Style), makes control flow explicit. Instead of returning, the last thing code does is invoke a closure passed in which does "the next thing". This lets an asynchronous animation, as its last step, "pick up where it left off", e.g. to continue looping through card columns, checking for legal moves. [Note CardTable Class>>cpsOverColl:do:next: and class side examples]. > > This is a style experiment. I am not totally happy with this style as it can be painful to debug. Perhaps we should re-introduce the Continuation Class to capture continuations directly. > > In any case, we have Solitaire working again with the current Cuis version. > > Enjoy! > -KenD > > _______________________________________________ > 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 |
|
|
On Wed, 25 Mar 2015 09:12:54 -0300
Juan Vuletich <[hidden email]> wrote: .. > You managed to do the animation and game logic, interleaved with normal > World cycling, and without any need to mess with "private" Morphic > internals. Impressive. > > I'm not sure, but I have a feeling that making 'mainLoop' and > 'pilesLoop' into separate methods might make debugging a bit easier. Proof of concept code is not always elegant. First step. "If you can do it, it must be possible." > I also believe that once you leave the world of simple lineal sequencing > of calls and returns, debugging will always get trickier, just as design > and coding. At least, your code is entirely predictable and > deterministic. The CPS transform/style itself is entirely deterministic. Stepping adds some non-determinism but not much in this context. Disabeling the Undo button during undo helps. ;^) I need to look at the SeaSide code base to see what code/style they have developed to handle continuation based processing. They have been using continuations for some time to deal with web page processing. No time as yet. Cheers, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
Gentlemen,
I’ve been doing the following: Create a SystemWindow. Add a ScrollPane to the SystemWindow. Add a DragAndDropAreaMorph to the ScrollPane. with the intention that as I add morphs to the DragAndDropAreaMorph and space them appropriately the SystemWindow can be scrolled up and down to reveal the different parts on display. What I find is that if I enlarge the SystemWindow I can see the EllipseMorph but I’m not sure how to set it up so that the scrollbars appear to be able to scroll down to see the EllipseMorph. Any comments much appreciated! I’ve been looking up Squeak/Pharo/Cuis documentation on using layouts (which may be the issue) but have made little headway. Attached image illustrating the above. Best regards, Hari  _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Sat, 2015-03-28 at 13:50 -0400, Hari Balaraman wrote:
> Gentlemen, > > I’ve been doing the following: > > > Create a SystemWindow. > Add a ScrollPane to the SystemWindow. > Add a DragAndDropAreaMorph to the ScrollPane. > > > with the intention that as I add morphs to the DragAndDropAreaMorph > and space them appropriately the SystemWindow can be scrolled up and > down to reveal the different parts on display. > > > What I find is that if I enlarge the SystemWindow I can see the > EllipseMorph but I’m not sure how to set it up so that the scrollbars > appear to be able to scroll down to see the EllipseMorph. > > > Any comments much appreciated! > > > I’ve been looking up Squeak/Pharo/Cuis documentation on using layouts > (which may be the issue) but have made little headway. > > > Attached image illustrating the above. > > > Best regards, > I haven't played around with scrollbars in Squeak / Cuis yet, but in many (most?) GUIs its up to your code to maintain the illusion of position in the virtual space inside the scrolling area. (i.e. scrollbar position, size, and actually drawing the visible portion of the view is up to you to manage) > > Hari > > > > > > _______________________________________________ > 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 |
Re: Solitaire updated for 2203
|
|
In reply to this post by KenDickey
So did you do the continuation passing thing entirely with block closures? If so, I have to say I kind of like not having to add a class. But making the code easy to debug has some goodness to it as well.
Anyway, cool:) > On Mar 21, 2015, at 9:40 AM, "Ken.Dickey" <[hidden email]> wrote: > > I updated Solitaire to work with asynchronous animation. Solitaire used to use synchronous animation, which has been removed. > > The main problem to be solved is how to interleave animation with control logic. For example, in auto-moving cards from columns to piles, one wishes to check each card column and if any card has been moved to a pile, check each column again. > > The style I used here, CPS (Continuation Passing Style), makes control flow explicit. Instead of returning, the last thing code does is invoke a closure passed in which does "the next thing". This lets an asynchronous animation, as its last step, "pick up where it left off", e.g. to continue looping through card columns, checking for legal moves. [Note CardTable Class>>cpsOverColl:do:next: and class side examples]. > > This is a style experiment. I am not totally happy with this style as it can be painful to debug. Perhaps we should re-introduce the Continuation Class to capture continuations directly. > > In any case, we have Solitaire working again with the current Cuis version. > > Enjoy! > -KenD > > _______________________________________________ > 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 |
|
|
On Sat, 28 Mar 2015 18:14:07 -0700
Casey Ransberger <[hidden email]> wrote: > So did you do the continuation passing thing entirely with block closures? Guilty as charged. > If so, I have to say I kind of like not having to add a class. But making the code easy to debug has some goodness to it as well. I don't think callcc/currentDo: will be esier to debug. I'm just starting to play with the trivial port of Continuation from SeaSide. I suspect it will take me some time to find a style which helps. Elegance takes much time, not that I have much. > Anyway, cool:) Glad you think so. Great to have real closures in Squeak/Cuis/Pharo after many years of context blocks. Closures are so much more usable! Basically CPS was just the easiest way to get the control flow explicit so that it could be disentangled from the animation. I am still trying for "the simplest thing that will work". It sometimes takes an amazing amount of work to find the right simplicity. Cheers, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
In reply to this post by Phil B
On Sat, 28 Mar 2015 18:47:04 -0400
"Phil (list)" <[hidden email]> wrote: > > I’ve been looking up Squeak/Pharo/Cuis documentation on using layouts > > (which may be the issue) but have made little headway. Cuis layouts are different from Squeak or Pharo. Given the changes going on, many things require some code reading and playing around. To understand Layouts and LayoutSpecs, I did simple editors for them. They are located in the Morphic-Misc1 package at: https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1 From the readme: " After loading this package, one can select a morph, open its menu from the halo, and edit its LayoutSpec. If the morph is a LayoutMorph, one can also open an editor for the LayoutMorph from the halo menu. " Inspecting the window submorphs should help as well. Cheers, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
Hi Ken,
Thanks. I will look up your package. I just figured out how to get some of the behaviour I need in Squeak - by adding the morph in question to the TransformMorph within the ScrollPane rather than to the ScrollPane. More playing around required. Regards, Hari > On Mar 28, 2015, at 10:26 PM, Ken.Dickey <[hidden email]> wrote: > > On Sat, 28 Mar 2015 18:47:04 -0400 > "Phil (list)" <[hidden email]> wrote: > >>> I’ve been looking up Squeak/Pharo/Cuis documentation on using layouts >>> (which may be the issue) but have made little headway. > > Cuis layouts are different from Squeak or Pharo. Given the changes going on, many things require some code reading and playing around. > > To understand Layouts and LayoutSpecs, I did simple editors for them. They are located in the Morphic-Misc1 package at: > https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1 > > From the readme: > " > After loading this package, one can select a morph, open its menu from the halo, and edit its LayoutSpec. > If the morph is a LayoutMorph, one can also open an editor for the LayoutMorph from the halo menu. > " > > Inspecting the window submorphs should help as well. > > Cheers, > -KenD > > _______________________________________________ > 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 |
|
|
In reply to this post by KenDickey
On 3/29/15, Ken.Dickey <[hidden email]> wrote:
> On Sat, 28 Mar 2015 18:14:07 -0700 > Casey Ransberger <[hidden email]> wrote: > >> So did you do the continuation passing thing entirely with block closures? >> > > Guilty as charged. > >> If so, I have to say I kind of like not having to add a class. But making >> the code easy to debug has some goodness to it as well. > > I don't think callcc/currentDo: will be esier to debug. I'm just starting > to play with the trivial port of Continuation from SeaSide. > > I suspect it will take me some time to find a style which helps. Elegance > takes much time, not that I have much. > >> Anyway, cool:) > > Glad you think so. > > Great to have real closures in Squeak/Cuis/Pharo after many years of context > blocks. Closures are so much more usable! > > Basically CPS was just the easiest way to get the control flow explicit so > that it could be disentangled from the animation. > > I am still trying for "the simplest thing that will work". > > It sometimes takes an amazing amount of work to find the right simplicity. Exaclty! And it needs several attempts ..... > > Cheers, > -KenD > > _______________________________________________ > 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 |
|
|
In reply to this post by KenDickey
Hi Folks,
On 3/28/2015 11:26 PM, Ken.Dickey wrote: > On Sat, 28 Mar 2015 18:47:04 -0400 > "Phil (list)"<[hidden email]> wrote: > >>> I’ve been looking up Squeak/Pharo/Cuis documentation on using layouts >>> (which may be the issue) but have made little headway. > Cuis layouts are different from Squeak or Pharo. Given the changes going on, many things require some code reading and playing around. > > To understand Layouts and LayoutSpecs, I did simple editors for them. They are located in the Morphic-Misc1 package at: > https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1 > > From the readme: > " > After loading this package, one can select a morph, open its menu from the halo, and edit its LayoutSpec. > If the morph is a LayoutMorph, one can also open an editor for the LayoutMorph from the halo menu. > " > > Inspecting the window submorphs should help as well. > > Cheers, > -KenD Hari, you were really close. Unfortunately, a bug in Cuis made it harder than needed. Besides trying Ken suggestion, also do the following: 1) Change #addToScroller: to read addToScroller: aMorph scroller addMorph: aMorph position: 0@0; morphExtent: aMorph morphExtent (just found a bug. This fix will be on GitHub soon) 2) Take a look at #inATwoWayScrollPane. Try the comment: (EllipseMorph new morphExtent: 500@270) inATwoWayScrollPane openInHand 3) Change your code to read: mArea := ( DragAndDropAreaMorph new color: Color white) inspect openInWorld. scrollpane := (PluggableScrollPane new color: Color red) openInWorld . scrollpane inspect. gWindow := SystemWindow new. gWindow addMorph: scrollpane. mArea morphExtent: 800@800. scrollpane addToScroller: mArea. qEllipse := EllipseMorph new. mArea addMorph: qEllipse. qEllipse morphPosition: 200@500. gWindow openInWorld The change was to set the mArea extent prior to adding to the scroller.... Maybe we'd make InnerPluggableMorph>>#adjustExtent work! If you keep playing with this, and find out whow you think it should behave, please send us your code, for integration. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Solitaire updated for 2203
|
|
In reply to this post by KenDickey
On 3/28/2015 11:02 PM, Ken.Dickey wrote:
> On Sat, 28 Mar 2015 18:14:07 -0700 > Casey Ransberger<[hidden email]> wrote: > >> So did you do the continuation passing thing entirely with block closures? > Guilty as charged. > >> If so, I have to say I kind of like not having to add a class. But making the code easy to debug has some goodness to it as well. > I don't think callcc/currentDo: will be esier to debug. I'm just starting to play with the trivial port of Continuation from SeaSide. > > I suspect it will take me some time to find a style which helps. Elegance takes much time, not that I have much. > >> Anyway, cool:) > Glad you think so. > > Great to have real closures in Squeak/Cuis/Pharo after many years of context blocks. Closures are so much more usable! > > Basically CPS was just the easiest way to get the control flow explicit so that it could be disentangled from the animation. > > I am still trying for "the simplest thing that will work". > > It sometimes takes an amazing amount of work to find the right simplicity. Indeed. You must first understand all the superfluous stuff well enough to know what to remove and what to keep... Now that you have published Continuations for Cuis, I took a look at them... And found at http://www.jquigley.com/files/talks/continuations.pdf : "Even hard-core continuation fans don’t use them directly except as means to implement better-behaved abstractions." Besides, Continuations require reification of the execution context as a regular object (to be gc'ed later), instead of just a stack. I believe this means that using Continuations to implement control structures to be used for coding could have a significant performance penalty. I hope you'll eventually reach a style based on morphic stepping, that is simple enough to code and debug. Cheers, Juan Vuletich > Cheers, > -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Hi Juan,
Thanks very much for your comments. I will review your suggestions asap. As a temporary solution, I copied PluggableScrollPane, renamed it, and revised the initialize method (bypassing the instantiation of innerMorph) thus: initialize: aMorphClass "initialize the state of the receiver" | n | super initialize. hideScrollBars _ false. "initialize the receiver's scrollBars" scrollBar _ self scrollBarClass new model: self setValueSelector: #vScrollBarValue:. hScrollBar _ self scrollBarClass new model: self setValueSelector: #hScrollBarValue:. drawKeyboardFocusIndicator _ true. n:=SystemWindow new. n addMorph:self. "scroller _ self innerMorphClass new." scroller:=aMorphClass new. scroller morphExtent:8000@8000. self addMorph: scroller. self scrollerOffset: 0@ 0. self addMorph: scrollBar. self addMorph: hScrollBar. n openInWorld. and a) deleted initialize, and b)set up dummy adjustExtent messages within my embedded objects (and planned to tangle with adjustExtent later…). Some comments: 1.I’ve spent a some time reviewing the LayoutMorph class examples and have had a certain amount of difficulty in using them. I am using squeak documentation whenever I am stuck in my efforts, so if layouts are a marked departure from Squeak,I would like to request more documentation (in class comments, faq wherever) on when/how layouts are instantiated by objects and are used. 2. One of the things I like about Cuis is the relative positioning of morphs within containers. This has allowed me to build my (very simple) UI without considering layouts. 3. Not having an intermediary layout layer has allowed me to easily make calls to and from embedded objects within the containers in my system (I considered a decoupled model and spent some time on a version of the announcements framework which I imported from Squeak, but, scattered documentation and various versions later, I have abandoned that approach.) SystemWindow creates a LayoutMorph by default. Looking up the hierarchy, I haven’t as yet, located where the LayoutMorph instantiation behaviour occurs. I would dearly love to get around LayoutMorphs by toggling a switch or preference, and play puppeteer in a more direct fashion (I know, I know, you are shaking your head in despair.) Best regards, Hari On Mar 30, 2015, at 8:51 AM, Juan Vuletich <[hidden email]> wrote: _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Hari,
(inline) On 3/30/2015 11:22 AM, Hari Balaraman wrote: Hi Juan, Have you read the class comments at LayoutSpec and LayoutMorph? In addition, LayoutMorph has an 'examples' class category. Try each one. Resize the top morph, and see layouts in action. inspect / explore the morphs, etc. Try to figure out what's happening. WRT when they are instantiated, check references to these classes. They are all there. If something is not clear enough, please ask any questions. They will be useful to enhance this documentation.
Yep. That's the purpose of that. If you don't need automatic layout (maybe because your UI elements are all of fixed size), then just put them wherever you want them :)
Browse LayoutMorph. Right click on it. Select 'class refs (N)'. See that there are two references from LayoutMorph from SystemWindow. Check senders of those methods. Isn't everything obvious?
:) I welcome you and everybody else to play and experiment. That's the realization of the "Personal Mastery" principle from Dan Ingalls ("Design Principles behind Smalltalk"), and the whole purpose of Cuis. A Dynabook for me and for everybody. Cheers, Juan Vuletich
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
In reply to this post by hbalaraman
On 31 Mar 2015 at 10:30, Juan Vuletich wrote:
[snip] > Have you read the class comments at LayoutSpec and LayoutMorph? In > addition, LayoutMorph > has an 'examples' class category. Try each one. Resize the top > morph, and see layouts in action. > inspect / explore the morphs, etc. Try to figure out what's > happening... Having resized the top morph, what's the best way to determine which layout is which? _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On 4/1/2015 1:00 PM, Dan Norton wrote:
> On 31 Mar 2015 at 10:30, Juan Vuletich wrote: > > [snip] > >> Have you read the class comments at LayoutSpec and LayoutMorph? In >> addition, LayoutMorph >> has an 'examples' class category. Try each one. Resize the top >> morph, and see layouts in action. >> inspect / explore the morphs, etc. Try to figure out what's >> happening... > Having resized the top morph, what's the best way to determine which > layout is which? > Use middle click on the top morph to open a halo on it. From there, open an explorer. You can see the morph tree and play with it. BTW, be sure to try making it rather large, so you can see all the morphs inside. For example, #example11 has three rows, the first one with 5 boxes and 4 draggeable separators, etc. You can open a halo on each one to inspect it and so on... Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by hbalaraman
-----Original Message----- >From: Juan Vuletich <[hidden email]> >Sent: Apr 1, 2015 12:21 PM >To: Dan Norton <[hidden email]>, Discussion of Cuis Smalltalk <[hidden email]> >Subject: Re: [Cuis] Newbie question > >On 4/1/2015 1:00 PM, Dan Norton wrote: >> On 31 Mar 2015 at 10:30, Juan Vuletich wrote: >> >> [snip] >> >>> Have you read the class comments at LayoutSpec and LayoutMorph? In >>> addition, LayoutMorph >>> has an 'examples' class category. Try each one. Resize the top >>> morph, and see layouts in action. >>> inspect / explore the morphs, etc. Try to figure out what's >>> happening... >> Having resized the top morph, what's the best way to determine which >> layout is which? >> > >Use middle click on the top morph to open a halo on it. From there, open >an explorer. You can see the morph tree and play with it. > >BTW, be sure to try making it rather large, so you can see all the >morphs inside. For example, #example11 has three rows, the first one >with 5 boxes and 4 draggeable separators, etc. You can open a halo on >each one to inspect it and so on... > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Wed, 1 Apr 2015 16:40:45 -0400 (GMT-04:00)
Dan Norton <[hidden email]> wrote: > What's needed is a way to correlate the morphs on Display with the code in the examples. From a previous post: To understand Layouts and LayoutSpecs, I did simple editors for them. They are located in the Morphic-Misc1 package at: https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1 From the readme: " After loading this package, one can select a morph, open its menu from the halo, and edit its LayoutSpec. If the morph is a LayoutMorph, one can also open an editor for the LayoutMorph from the halo menu. " You option-click on a Morph to select it. Hold down your option key and "click" on a morph. The "control halo" appears and a label for the morph is at the bottom. Continuing to hold down the option key and clicking multiple times selects inner morphs. The small, round "control handles" of the halo have "hover help". Just hold the cursor over each small button to see what they do. One of these has title 'Menu'. If you click on that, you get a menu of options for the halo-ed morph. If you have cloned the Morphic-Misc1 package from GitHub (you can read about this in the World Menu's Help selections), you should be able from this menu to select edit Layout and edit LayoutSpec as appropriate. Between reading the code and playing with the layout options, you should be able to let us know how to better help you get oriented. -- -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Re: Layout/LayoutSpec Editors [WAS: Newbie question]
|
|
On 2 Apr 2015 at 6:03, Ken.Dickey wrote:
> On Wed, 1 Apr 2015 16:40:45 -0400 (GMT-04:00) > Dan Norton <[hidden email]> wrote: > > > What's needed is a way to correlate the morphs on Display with the > code in the examples. > > From a previous post: > > To understand Layouts and LayoutSpecs, I did simple editors for > them. They are located in the Morphic-Misc1 package at: > https://github.com/KenDickey/Cuis-Smalltalk-Morphic-Misc1 > > From the readme: > " > After loading this package, one can select a morph, open its menu > from the halo, and edit its LayoutSpec. > > If the morph is a LayoutMorph, one can also open an editor for the > LayoutMorph from the halo menu. > " > > You option-click on a Morph to select it. > > Hold down your option key and "click" on a morph. The "control > halo" appears and a label for the morph is at the bottom. > > Continuing to hold down the option key and clicking multiple times > selects inner morphs. > > The small, round "control handles" of the halo have "hover help". > Just hold the cursor over each small button to see what they do. > > One of these has title 'Menu'. If you click on that, you get a menu > of options for the halo-ed morph. > > If you have cloned the Morphic-Misc1 package from GitHub (you can > read about this in the World Menu's Help selections), you should be > able from this menu to select edit Layout and edit LayoutSpec as > appropriate. > > Between reading the code and playing with the layout options, you > should be able to let us know how to better help you get oriented. > This is interesting because it should allow experiments with instances of LayoutMorph and LayoutSpec. I tried installing on Cuis 4.2-2203 rather than 2198 per the ReadMe because that's what was handy. This is on a PC running 'Doze 7. Trying to use the ReadMe to install was not successful. However, from File List I did install the package. Not sure what you mean by option-click but button3 and cmd-button3 do the same thing: bring up the halos. The menu has your items at the end. Tried edit Layout on LayoutMorph example2. Changed from row to column, clicked update and the change took place but the editor quit. Could the way I installed cause this behavior? This has real potential and I'd like to see it working better. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by hbalaraman
>On 4/1/2015 1:00 PM, Dan Norton wrote:
>> On 31 Mar 2015 at 10:30, Juan Vuletich wrote: >> [snip] >> >>> Have you read the class comments at LayoutSpec and LayoutMorph? In >>> addition, LayoutMorph >>> has an 'examples' class category. Try each one. Resize the top >>> morph, and see layouts in action. >>> inspect / explore the morphs, etc. Try to figure out what's >>> happening... >> Having resized the top morph, what's the best way to determine which >> layout is which? >> > >Use middle click on the top morph to open a halo on it. From there, open >an explorer. You can see the morph tree and play with it. > >BTW, be sure to try making it rather large, so you can see all the >morphs inside. For example, #example11 has three rows, the first one >with 5 boxes and 4 draggeable separators, etc. You can open a halo on >each one to inspect it and so on... > LayoutMorph has examples. You bring up example2, middle click and use the resize halo to make it larger. (Suggestion: the example should make it large enough to distinguish the morphs.) You see in the browser that row has 3 submorphs which are BorderedRectMorphs. You middle click on one of the rectangular morphs on the screen to get the halos. At the bottom you see "a BorderedRectMorph(1639)" IMHO this is perfectly correct but utterly useless information because all the others will have similar info with different numbers, none of which tie back to what you see in the browser. Further these numbers will change upon the next instantiation. A simple solution is to have #name as an instance variable with 2 supporting methods: #name: and #printOn: . When #name: 'foo' is OPTIONALLY sent, the name will appear as "a BorderedRectMorph(1639)'foo'" when you middle click on the morph. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |