Smalltalk › Squeak › Squeak - Dev

morph selector x: x and y: y

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Nicolai Hess-3-2

morph selector x: x and y: y

Hi,

someone knows why Morphs selector x x: and y y: are
implemented differently?

Morph y and y: testing wether self world is nil

whereas x and x: doesn't.

Btw. what is the preferred way to position morphs relative

to the bounds of its owner. It seems morph positions are always

absolute coordinates.

regards

Nicolai

Casey Ransberger-2

Re: morph selector x: x and y: y

I don't have access to an image often enough. Sounds like you might have an interesting bug. Would you post the two implementations, if they aren't long?

On Mon, Mar 4, 2013 at 11:46 PM, Nicolai Hess <[hidden email]> wrote:

Hi,

someone knows why Morphs selector x x: and y y: are
implemented differently?

Morph y and y: testing wether self world is nil
whereas x and x: doesn't.

Btw. what is the preferred way to position morphs relative
to the bounds of its owner. It seems morph positions are always
absolute coordinates.

regards

Nicolai

--
Casey Ransberger

marcel.taeumel (old)

Re: morph selector x: x and y: y

In reply to this post by Nicolai Hess-3-2

Well, #x: and #y: actually is eToys stuff as the protocol "eToy" reveals. I think, one should use #top: and #left: instead.

Maybe we should (1) make the implementations consistent and (2) move them to the eToys extensions.

Best,
Marcel

Nicolai Hess-3-2

Re: morph selector x: x and y: y

In reply to this post by Casey Ransberger-2

2013/3/5 Casey Ransberger <[hidden email]>

I don't have access to an image often enough. Sounds like you might have an interesting bug. Would you post the two implementations, if they aren't long?

On Mon, Mar 4, 2013 at 11:46 PM, Nicolai Hess <[hidden email]> wrote:

Hi,

someone knows why Morphs selector x x: and y y: are
implemented differently?

Morph y and y: testing wether self world is nil
whereas x and x: doesn't.

Btw. what is the preferred way to position morphs relative
to the bounds of its owner. It seems morph positions are always
absolute coordinates.

regards

Nicolai

--
Casey Ransberger

x: aNumber
    "Set my horizontal position relative to the cartesian origin of the playfield or the world."

    | offset aPlayfield newX |
    aPlayfield := self referencePlayfield.
    offset := self left - self referencePosition x.
    newX := aPlayfield isNil
                ifTrue: [aNumber + offset]
                ifFalse: [aPlayfield cartesianOrigin x + aNumber + offset].
    self position: newX @ bounds top

y: aNumber
    "Set my vertical position relative to the cartesian origin of the playfield or the world. Note that larger y values are closer to the top of the screen."

    | w offset newY aPlayfield |
    w := self world.
    w ifNil: [^self position: bounds left @ aNumber].
    aPlayfield := self referencePlayfield.
    offset := self top - self referencePosition y.
    newY := aPlayfield isNil
                ifTrue: [w bottom - aNumber + offset]
                ifFalse: [aPlayfield cartesianOrigin y - aNumber + offset].
    self position: bounds left @ newY

Bert Freudenberg

Re: morph selector x: x and y: y

In reply to this post by Nicolai Hess-3-2

On 2013-03-05, at 08:46, Nicolai Hess <[hidden email]> wrote:

> Hi,
>
> someone knows why Morphs selector x x: and y y: are implemented differently?

Yes.

> Morph y and y: testing wether self world is nil whereas x and x: doesn't.

That's because the y coordinate does not need to be flipped.

As Marcel wrote, these should be moved to the Etoys package.

> Btw. what is the preferred way to position morphs relative
> to the bounds of its owner. It seems morph positions are always
> absolute coordinates.

The preferred way would be to use a layout.

A common way for absolute positioning is to add the children while the parent is still at 0@0.

Or, just embrace global coords:

child center: parent center.

(similar for other setters like #topLeft etc)

- Bert -

Nicolai Hess-3-2

Re: morph selector x: x and y: y

2013/3/5 Bert Freudenberg <[hidden email]>

On 2013-03-05, at 08:46, Nicolai Hess <[hidden email]> wrote:

> Hi,
>
> someone knows why Morphs selector x x: and y y: are implemented differently?

Yes.

> Morph y and y: testing wether self world is nil whereas x and x: doesn't.

That's because the y coordinate does not need to be flipped.

As Marcel wrote, these should be moved to the Etoys package.

> Btw. what is the preferred way to position morphs relative
> to the bounds of its owner. It seems morph positions are always
> absolute coordinates.

The preferred way would be to use a layout.

A common way for absolute positioning is to add the children while the parent is still at 0@0.

Or, just embrace global coords:

child center: parent center.

(similar for other setters like #topLeft etc)

- Bert -

Ah ok,

that means etoys uses x/y coordinates with origin at lower left screen corner
and morphs top/left are coordinates with origin at upper left screen corner.

Thank you.

Nicolai

Bert Freudenberg

Re: morph selector x: x and y: y

On 2013-03-06, at 09:00, Nicolai Hess <[hidden email]> wrote:

> 2013/3/5 Bert Freudenberg <[hidden email]>
>> On 2013-03-05, at 08:46, Nicolai Hess <[hidden email]> wrote:
>>
>> > Hi,
>> >
>> > someone knows why Morphs selector x x: and y y: are implemented differently?
>>
>> Yes.
>>
>> > Morph y and y: testing wether self world is nil whereas x and x: doesn't.
>>
>> That's because the y coordinate does not need to be flipped.
>>
>> As Marcel wrote, these should be moved to the Etoys package.
>>
>> > Btw. what is the preferred way to position morphs relative
>> > to the bounds of its owner. It seems morph positions are always
>> > absolute coordinates.
>>
>> The preferred way would be to use a layout.
>>
>> A common way for absolute positioning is to add the children while the parent is still at 0@0.
>>
>> Or, just embrace global coords:
>>
>> child center: parent center.
>>
>> (similar for other setters like #topLeft etc)
>>
>> - Bert -
>
> Ah ok,
> that means etoys uses x/y coordinates with origin at lower left screen corner
> and morphs top/left are coordinates with origin at upper left screen corner.
> Thank you.
>
> Nicolai

Yes, Etoys uses a cartesian coordinate system like kids learn it in school, with the origin in the lower left by default (but can be set to the center, too). Also, x and y refer to an object's center, by default. Who except programmers finds the upper-left corner of an object more natural than its center?

And I did mean to write "x does not need to be flipped" above of course. Reminds me of something I just saw on twitter:

"There are two hard problems in computer science: naming things, cache coherence, and off-by-one errors." -- anon

- Bert -