Default Morph position something other than 0 @ 0?

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial position
> annoying and in some cases nearly non-functional since the Morph doesn't
> have room for its halo icons.  Just wondering if this bothers anyone
> else and if maybe insetting new morphs top left by default to something
> like 50 @ 50 (something out of the way, but giving it a bit of margin
> from the edge of the screen) might be better?
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> This is a minor nit but when I'm developing Morphs I often need to
> instantiate them manually via something like 'MorphName new
> openInWorld.'  When I do that, I almost always find its initial
> position
> annoying and in some cases nearly non-functional since the Morph
> doesn't
> have room for its halo icons.  Just wondering if this bothers
> anyone
> else and if maybe insetting new morphs top left by default to
> something
> like 50 @ 50 (something out of the way, but giving it a bit of
> margin
> from the edge of the screen) might be better?
>

>
>
> On 7/9/15, 6:15 AM, "Phil (list)" <[hidden email]> wrote:
>
> > This is a minor nit but when I'm developing Morphs I often need to
> > instantiate them manually via something like 'MorphName new
> > openInWorld.'  When I do that, I almost always find its initial position
> > annoying and in some cases nearly non-functional since the Morph doesn't
> > have room for its halo icons.  Just wondering if this bothers anyone
> > else and if maybe insetting new morphs top left by default to something
> > like 50 @ 50 (something out of the way, but giving it a bit of margin
> > from the edge of the screen) might be better?
>
>
> Morph new openInHand could be better?
>

>
>
> On 7/12/15, 2:16 PM, "Phil (list)" <[hidden email]> wrote:
>
> > I find that's not always an option in the early stages of working on a
> > Morph as there are often initialization dependencies that I haven't
> > worked out at that stage causing openInHand not to work.  Once I have
> > everything working, then I go back and figure out what needs to happen
> > to get it running with openInHand...
>
> Ok.
> Could share yours code not working with openInHand ?
>

> I think a recent example was the Dan's BouncingAtomsMorph which could
> not be invoked from the New Morph... menu until I submitted a fix.  It
> was an easy fix and I run into this problem quite often in the early
> stages of Morph development.  openInHand calls doOneCycleNow (or maybe
> it's doOneCycle... I forget which) which results in the Morph needing to
> draw earlier than with openInWorld.  This is a problem if the Morph
> isn't fully initialized and ready to be drawn yet.  It's not a big deal,
> just part of how I develop Morphs and why I use openInWorld until I get
> things sorted out.  Also, when I'm developing a Morph I'm usually
> invoking it from a workspace or code browser and don't want to be
> dealing with it interactively yet since it usually isn't fully
> functional anyway.

>
>
>
> On 7/12/15, 5:23 PM, "Phil (list)" <[hidden email]> wrote:
>
> > I think a recent example was the Dan's BouncingAtomsMorph which
> could
> > not be invoked from the New Morph... menu until I submitted a fix.
> It
> > was an easy fix and I run into this problem quite often in the
> early
> > stages of Morph development.  openInHand calls doOneCycleNow (or
> maybe
> > it's doOneCycle... I forget which) which results in the Morph
> needing to
> > draw earlier than with openInWorld.  This is a problem if the
> Morph
> > isn't fully initialized and ready to be drawn yet.  It's not a big
> deal,
> > just part of how I develop Morphs and why I use openInWorld until
> I get
> > things sorted out.  Also, when I'm developing a Morph I'm
> usually
> > invoking it from a workspace or code browser and don't want to
> be
> > dealing with it interactively yet since it usually isn't fully
> > functional anyway.
>
> Very instructive.
> Thanks a lot.
>
> Edgar
>

> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
>
> >
> >
> >
> > On 7/12/15, 5:23 PM, "Phil (list)" <[hidden email]> wrote:
> >
> > > I think a recent example was the Dan's BouncingAtomsMorph which
> > could
> > > not be invoked from the New Morph... menu until I submitted a fix.
> > It
> > > was an easy fix and I run into this problem quite often in the
> > early
> > > stages of Morph development.  openInHand calls doOneCycleNow (or
> > maybe
> > > it's doOneCycle... I forget which) which results in the Morph
> > needing to
> > > draw earlier than with openInWorld.  This is a problem if the
> > Morph
> > > isn't fully initialized and ready to be drawn yet.  It's not a big
> > deal,
> > > just part of how I develop Morphs and why I use openInWorld until
> > I get
> > > things sorted out.  Also, when I'm developing a Morph I'm
> > usually
> > > invoking it from a workspace or code browser and don't want to
> > be
> > > dealing with it interactively yet since it usually isn't fully
> > > functional anyway.
> >
> > Very instructive.
> > Thanks a lot.
> >
> > Edgar
> >
>
> Yes, thank you Phil for the fix. I needed to learn that. I put the history of the change on:
>

> On Sun, 2015-07-12 at 22:20 -0400, Dan Norton wrote:
>> On 12 Jul 2015 at 18:02, Edgar J. De Cleene wrote:
>>
>> >
>> >
>> >
>> > On 7/12/15, 5:23 PM, "Phil (list)" <[hidden email]> wrote:
>> >
>> > > I think a recent example was the Dan's BouncingAtomsMorph which
>> > could
>> > > not be invoked from the New Morph... menu until I submitted a fix.
>> > It
>> > > was an easy fix and I run into this problem quite often in the
>> > early
>> > > stages of Morph development.  openInHand calls doOneCycleNow (or
>> > maybe
>> > > it's doOneCycle... I forget which) which results in the Morph
>> > needing to
>> > > draw earlier than with openInWorld.  This is a problem if the
>> > Morph
>> > > isn't fully initialized and ready to be drawn yet.  It's not a big
>> > deal,
>> > > just part of how I develop Morphs and why I use openInWorld until
>> > I get
>> > > things sorted out.  Also, when I'm developing a Morph I'm
>> > usually
>> > > invoking it from a workspace or code browser and don't want to
>> > be
>> > > dealing with it interactively yet since it usually isn't fully
>> > > functional anyway.
>> >
>> > Very instructive.
>> > Thanks a lot.
>> >
>> > Edgar
>> >
>>
>> Yes, thank you Phil for the fix. I needed to learn that. I put the history
>> of the change on:
>>
>
> Glad to chip in... thank you for giving us a nice Morphic demo!
>
>> https://github.com/dhnorton/Cuis-Smalltalk-atoms
>>
>> The commit is "343a986"  "starts from new morph menu"
>>
>
> There it is  (I was too tired/lazy to dig up the commit reference :-)
>
>>  - Dan
>>
>>
>> _______________________________________________
>> 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
>