Hi, there.

Styling in HelpTopic is "under construction" because of how tool builder works. There is usually a lot of "initialization code" which is challenging to toggle at a tool's run-time:

- styling on/off - fixed (monospaced) font? - horizontal scrolling on/off (or text wrapping on/off)

Consequently, things that seem to be "under construction" in Squeak's Help Browser might actually be "under construction" in the tool builder (and all it's specs and relationships to pluggable morphs [Morphic] or pluggable views [ST80/MVC]):

- A new event for changed/update would make sense? - What are the default values of properties if no further values are specified? - Is a default value coded in a widgets #initialize or in a tool's (or model's) #buildWith: or in the spec's #ifNil: or in the (tool) builder's #buildPluggable*:? Or at all places together? What are the override priorities then?

Further code readings:

HelpBrowser >> #buildWith: HelpBrowser >> #buildCodeContentsWith: HelpBrowser >> #aboutToStyle: (senders of) #usesCodeStyling (implementors of) #usesCodeStyling

Best, Marcel Am 10.11.2019 20:50:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Yeah, I already saw styling in the help topics is a bit under construction, I will be happy to work at this after this change set will have been approved :-)

Best, Christoph

On Sun, Nov 10, 2019 at 8:27 PM +0100, "tim Rowledge" <tim@rowledge.org [mailto:tim@rowledge.org]> wrote:

On 2019-11-10, at 10:28 AM, Christoph Thiede wrote: > > ShoutAttribute.cs That looks pretty damn good. This could help a great deal in making Help stuff clearer, so thank you! tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

I even read Java and C with proportional fonts these days. And hope that people don't format their comments or declarations in tables too often...

So I would not be a fan of monospacing code in the help topics either.

Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de schrieb am Mo., 11. Nov. 2019, 12:20:

Hi Marcel,

Thanks for the overview.

However, I'd be curious why and when we should ever want font to be monospaced or text wrapping to be disabled for text or Smalltalk code? From my point of view, monospacing is a relic of programming languages that provide bad readability due to a complicated or counter-intuitive syntax, and horizontal scroll bars are inconvenient at all, as exceedingly few mouses support 2D scrolling (I don't even know whether Squeak supports them :D) and you cannot read the whole line at once. Just my two cents :-)

Styling, on the other hand, should be dynamic if we simply always use a PluggableCodePaneSpec?

Best,

Christoph

*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Montag, 11. November 2019 11:07:00 *An:* John Pfersich via Squeak-dev *Betreff:* Re: [squeak-dev] Changeset: ShoutAttribute & semi-styling

Hi, there.

Styling in HelpTopic is "under construction" because of how tool builder works. There is usually a lot of "initialization code" which is challenging to toggle at a tool's run-time:

• styling on/off
• fixed (monospaced) font?
• horizontal scrolling on/off (or text wrapping on/off)

Consequently, things that seem to be "under construction" in Squeak's Help Browser might actually be "under construction" in the tool builder (and all it's specs and relationships to pluggable morphs [Morphic] or pluggable views [ST80/MVC]):

• A new event for changed/update would make sense?
• What are the default values of properties if no further values are

specified?

• Is a default value coded in a widgets #initialize or in a tool's (or

model's) #buildWith: or in the spec's #ifNil: or in the (tool) builder's #buildPluggable*:? Or at all places together? What are the override priorities then?

Further code readings:

HelpBrowser >> #buildWith: HelpBrowser >> #buildCodeContentsWith: HelpBrowser >> #aboutToStyle: (senders of) #usesCodeStyling (implementors of) #usesCodeStyling

Best, Marcel

Am 10.11.2019 20:50:13 schrieb Thiede, Christoph < christoph.thiede@student.hpi.uni-potsdam.de>: Yeah, I already saw styling in the help topics is a bit under construction, I will be happy to work at this after this change set will have been approved :-)

Best, Christoph

On Sun, Nov 10, 2019 at 8:27 PM +0100, "tim Rowledge" tim@rowledge.org wrote:

...

...

On 2019-11-10, at 10:28 AM, Christoph Thiede wrote:

ShoutAttribute.cs

That looks pretty damn good. This could help a great deal in making Help stuff clearer, so thank you!

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

However, I'd be curious why and when we should ever want font to be monospaced...

Haha, sorry for the confusion. That list was just from the top of my hat. The actual code font is a preference: Preferences standardCodeFont

... or text wrapping to be disabled ...

For a better overview in the Terse Guide but just because how the current guide is written:

Best, Marcel

Am 11.11.2019 12:39:19 schrieb Tobias Pape das.linux@gmx.de:

On 11.11.2019, at 12:35, Jakob Reschke wrote:

I even read Java and C with proportional fonts these days. And hope that people don't format their comments or declarations in tables too often...

So I would not be a fan of monospacing code in the help topics either.

same here. -t

... Terse Guide ...

I would still propose to reformat it about this way:

[cid:28d0935b-bb15-4e11-ae66-7d6476e04fea]

And also in your second screenshot, I think text wrapping would improve the readability. :)

...

Styling, on the other hand, should be dynamic if we simply always use a PluggableCodePaneSpec?

Hmm... I wouldn't do that in the help browser by default. Those little "wiki-like" pages in the help browser are text documents that can contain code -- not the other way round. You can always style a piece of text with [cmd]+[6] then "style it". ;-) Then save it.

What is the difference between a pluggable code pane that is not "okToStyle", and a pluggable text spec? As far as I see, at least the Morphic implementation does not make any difference here ... Moreover, "style it" is exactly where my changeset comes :-) Referring to the current Trunk implementation, I do not think we should store the hard-coded result of a #styleIt operation at any place. Please note that at the moment, the ShoutAttribute only works for PluggableTextMorphPlus and enforces styling even if it is not "okToStyle".

Well, actual mark-down with dynamic styling of selected text portions would also be nice. Yet, then we would need an extra "edit mode" for those pages in the help browser to "see" the mark down, which we do not need at the moment. And that's a good thing. It feels more direct. ;-) Not sure how long we can keep it that way...

The old question about WYSIWYG vs WYSIWYM :-) Well, inspecting or manipulating a TextAction after creation is not very easy for now (okay, I don't know all details about TextAction>>analyze). We could need a hotkey for something like "change attribute" here, maybe. But if we could develop a *simple* WYSWIWYM language, I think a switch in the PluggableTextMorph (yellow-button or halo) menu could be a compromise; and it would be also a nice way to store the text, as Text>>readStream is quite cryptical. However, pure Markdown does neither support colors nor links, while on the other hand, HTML is not the simplest language to read, in my humble opinion. GitHub-flavored Markdown? BBCode? ;-)

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 11. November 2019 13:53:03 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] Changeset: ShoutAttribute & semi-styling

Styling, on the other hand, should be dynamic if we simply always use a PluggableCodePaneSpec?

Hmm... I wouldn't do that in the help browser by default. Those little "wiki-like" pages in the help browser are text documents that can contain code -- not the other way round. You can always style a piece of text with [cmd]+[6] then "style it". ;-) Then save it.

Well, actual mark-down with dynamic styling of selected text portions would also be nice. Yet, then we would need an extra "edit mode" for those pages in the help browser to "see" the mark down, which we do not need at the moment. And that's a good thing. It feels more direct. ;-) Not sure how long we can keep it that way...

Best, Marcel

Am 11.11.2019 12:20:10 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:

Hi Marcel,

Thanks for the overview.

However, I'd be curious why and when we should ever want font to be monospaced or text wrapping to be disabled for text or Smalltalk code? From my point of view, monospacing is a relic of programming languages that provide bad readability due to a complicated or counter-intuitive syntax, and horizontal scroll bars are inconvenient at all, as exceedingly few mouses support 2D scrolling (I don't even know whether Squeak supports them :D) and you cannot read the whole line at once. Just my two cents :-)

Styling, on the other hand, should be dynamic if we simply always use a PluggableCodePaneSpec?

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 11. November 2019 11:07:00 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] Changeset: ShoutAttribute & semi-styling

Hi, there.

Styling in HelpTopic is "under construction" because of how tool builder works. There is usually a lot of "initialization code" which is challenging to toggle at a tool's run-time:

- styling on/off - fixed (monospaced) font? - horizontal scrolling on/off (or text wrapping on/off)

Consequently, things that seem to be "under construction" in Squeak's Help Browser might actually be "under construction" in the tool builder (and all it's specs and relationships to pluggable morphs [Morphic] or pluggable views [ST80/MVC]):

- A new event for changed/update would make sense? - What are the default values of properties if no further values are specified? - Is a default value coded in a widgets #initialize or in a tool's (or model's) #buildWith: or in the spec's #ifNil: or in the (tool) builder's #buildPluggable*:? Or at all places together? What are the override priorities then?

Further code readings:

HelpBrowser >> #buildWith: HelpBrowser >> #buildCodeContentsWith: HelpBrowser >> #aboutToStyle: (senders of) #usesCodeStyling (implementors of) #usesCodeStyling

Best, Marcel

Am 10.11.2019 20:50:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:

Yeah, I already saw styling in the help topics is a bit under construction, I will be happy to work at this after this change set will have been approved :-)

Best, Christoph

On Sun, Nov 10, 2019 at 8:27 PM +0100, "tim Rowledge" <tim@rowledge.orgmailto:tim@rowledge.org> wrote:

On 2019-11-10, at 10:28 AM, Christoph Thiede wrote:

ShoutAttribute.cs

That looks pretty damn good. This could help a great deal in making Help stuff clearer, so thank you!

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.