Smalltalk › Squeak › Squeak - Dev

Changeset: ShoutAttribute & semi-styling

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Christoph Thiede

Changeset: ShoutAttribute & semi-styling

ShoutAttribute.cs

Hi all,

I did not forget this thread here, and now I would like to finally present a changeset for an implementation of the ShoutAttribute.

I'm still not sure whether this is the right name and we should put this indeed into Shout-Core, so as always I'm open for your ideas. (OT: Should we maybe introduce a general "Styler" class outside of Shout providing the abstract protocol? Other classes such as a MarkdownStyler (do we already have one?) could then derive from it. In particular, this could be also useful for GraalSqueak ...)

However, try out the changeset or watch it in action:

Best,
Christoph

Sent from the Squeak - Dev mailing list archive at Nabble.com.

Carpe Squeak!

fniephaus

Re: Changeset: ShoutAttribute & semi-styling

Hi Christoph,

On Sun, Nov 10, 2019 at 7:26 PM Christoph Thiede <[hidden email]> wrote:

ShoutAttribute.cs
Hi all,

I did not forget this thread here, and now I would like to finally present a changeset for an implementation of the ShoutAttribute.

I'm still not sure whether this is the right name and we should put this indeed into Shout-Core, so as always I'm open for your ideas. (OT: Should we maybe introduce a general "Styler" class outside of Shout providing the abstract protocol? Other classes such as a MarkdownStyler (do we already have one?) could then derive from it. In particular, this could be also useful for GraalSqueak ...)

I'm guessing you're mentioning GraalSqueak here because of the Ruby styler that I've talked about at the Squeak e.V. meeting. At the moment, our styler inherits from Object. But I'd agree that a more generic and cleaned up styler interface would be nice.

Fabio

However, try out the changeset or watch it in action:

Best,
Christoph
Sent from the Squeak - Dev mailing list archive at Nabble.com.

timrowledge

Re: Changeset: ShoutAttribute & semi-styling

In reply to this post by Christoph Thiede

> On 2019-11-10, at 10:28 AM, Christoph Thiede <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Christoph Thiede

Re: Changeset: ShoutAttribute & semi-styling

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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Carpe Squeak!

marcel.taeumel

Re: 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 <[hidden email]>:
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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Christoph Thiede

Re: Changeset: ShoutAttribute & semi-styling

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 <[hidden email]> 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)

- A new event for changed/update would make sense?

- What are the default values of properties if no further values are specified?

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 <[hidden email]>:
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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Carpe Squeak!

Jakob Reschke

Re: Changeset: ShoutAttribute & semi-styling

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Tobias Pape

Re: Changeset: ShoutAttribute & semi-styling

> On 11.11.2019, at 12:35, Jakob Reschke <[hidden email]> 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

marcel.taeumel

Re: Changeset: ShoutAttribute & semi-styling

> 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 <[hidden email]>:

> 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

marcel.taeumel

Re: Changeset: ShoutAttribute & semi-styling

In reply to this post by Christoph Thiede

> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Christoph Thiede

Re: Changeset: ShoutAttribute & semi-styling

> ... Terse Guide ...

I would still propose to reformat it about this way:

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 <[hidden email]> 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?

Best,

Marcel

Am 11.11.2019 12:20:10 schrieb Thiede, Christoph <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.

Carpe Squeak!