LayoutFrame>>#printOn:

Hi all,

is anyone attached to the current LayoutFrame>>#printOn: design?

The current one fails if some instvars are nil. This is the case for SystemWindowButtons.

Furthermore, I never liked the current string representation, it has a quite cryptic look and does not match the common way you create a LayoutFrame using #fractions:/#offsets:.

Would anyone mind me to rewrite #printOn: in order to return a re-evaluatable string? Are there any dependencies?

Best,

Christoph

Am 18.09.2019 13:50:09 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

is anyone attached to the current LayoutFrame>>#printOn: design?

The current one fails if some instvars are nil. This is the case for SystemWindowButtons.

Furthermore, I never liked the current string representation, it has a quite cryptic look and does not match the common way you create a LayoutFrame using #fractions:/#offsets:.

Would anyone mind me to rewrite #printOn: in order to return a re-evaluatable string? Are there any dependencies?

Best,

Christoph

Hi Marcel,

actually I find re-evaluability quite often useful - for example, when I would like to take the LayoutFrame and set it to another Morph. At the moment you need to totally deconstruct + rewrite the expression to reuse it, while on the other hand you can directly print-and-eval points and rectangles. For beginners, it also helps to understand how the Objects are created.

Is

LayoutFrame fractions: (0.25@0 corner: 0.5@0.42) offsets: (4@0 corner: 0@ -20)

actually harder to read than

a LayoutFrame( l 0.25+4 t 0+0 r 0.5+0 b 0.42-20 )

?

(Imho, the latter with the unfamiliar non-Smalltalk syntax looks much more confusing to me. :) )

Best,

Christoph

> Is LayoutFrame fractions: (0.25@0 corner: [hidden email]) offsets: (4@0 corner: 0@ -20) actually harder to read than a LayoutFrame( l 0.25+4 t 0+0 r 0.5+0 b 0.42-20 ) ?

Yes, because it separates left fraction + left offset (etc.) visually. Again, the current printOn: reflects my personal debugging needs. :-) No, #printOn: does not have to be evaluable. We use #storeOn: for that. Until recently, #printOn: wasn't even implemented in LayoutFrame. Feel free to improve it for reasons other than evaluability. ;-)

Do you want to have a "print it" shortcut for #storeString? Like "store it"? Like CMD+SHIFT+P instead of CMD+P? That might be a nice productivity tool...

Best,

Marcel

Am 18.09.2019 16:15:19 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

actually I find re-evaluability quite often useful - for example, when I would like to take the LayoutFrame and set it to another Morph. At the moment you need to totally deconstruct + rewrite the expression to reuse it, while on the other hand you can directly print-and-eval points and rectangles. For beginners, it also helps to understand how the Objects are created.

Is

LayoutFrame fractions: (0.25@0 corner: 0.5@0.42) offsets: (4@0 corner: 0@ -20)

actually harder to read than

a LayoutFrame( l 0.25+4 t 0+0 r 0.5+0 b 0.42-20 )

?

(Imho, the latter with the unfamiliar non-Smalltalk syntax looks much more confusing to me. :) )

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 18. September 2019 13:54:55
An: Alan Grimes via Squeak-dev
Betreff: Re: [squeak-dev] LayoutFrame>>#printOn:

 

Hi Christoph,

I recently changed that to be more valuable for me when debugging layout issues. Feel free to add more "ifNil" checks if needed - there are already some.

However, there is no need to make that string re-evaluable. It's designed to fit the human eye. At least mine. :-)

Best,

Marcel

Am 18.09.2019 13:50:09 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

is anyone attached to the current LayoutFrame>>#printOn: design?

The current one fails if some instvars are nil. This is the case for SystemWindowButtons.

Furthermore, I never liked the current string representation, it has a quite cryptic look and does not match the common way you create a LayoutFrame using #fractions:/#offsets:.

Would anyone mind me to rewrite #printOn: in order to return a re-evaluatable string? Are there any dependencies?

Best,

Christoph

Am 18.09.2019 20:33:35 schrieb tim Rowledge <[hidden email]>:

Perhaps I missed it in the huge raft of emails I got this morning, but I'd urge people to remember the history of #printOn: & #storeOn: and related methods.
#printOn: is expected to result in a displayable String that offers a description of the receiver that can be helpful in debugging or other simple 'remind what this is' scenarios.
#storeOn: is/was an early attempt at providing a String that could be selected and evaluated to recreate an identical object. It had and has massive problems with anything actually complex - cycles, large size, whatever. That's why serializers came to be.

My advice would be to not to try to push either too far. It will only cause pain...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
We can rescue a hostage or bankrupt a system. Now, what would you like us to do?

> Compromise: can we introduce additional factory methods to make the LayoutFrame string both easy to grasp and evaluable? So it would satisfy both Marcel and Christoph?

> I am fine with somebody changing the implementation to make the string readable in a different way. Making it evaluable would be an objective measure for such readability.

Well, as a LayoutFrame consists of 8 values, I'm afraid such a constructor would not provide a good readability in any way unless the arguments are grouped into rectangles, would it?

Regarding storing:

I just discovered #storeString - personally, I am satisfied with typing " storeString" and the <cmd>p at the moment ...

Best,

Christoph