Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk:
http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.235.mcz ==================== Summary ==================== Name: ToolBuilder-Morphic-mt.235 Author: mt Time: 6 August 2019, 8:50:12.289656 am UUID: 8fb2449e-5234-44cb-bba5-f7bcf80b3cef Ancestors: ToolBuilder-Morphic-ct.234 Adds some comments. =============== Diff against ToolBuilder-Morphic-ct.234 =============== Item was changed: ----- Method: PluggableTextMorphPlus>>updateStyle (in category 'styling') ----- updateStyle + "Be sure to reset the style if it is not #okToStyle. Models might just send 'self changed: #style' without resetting the contents. See #update:." + - self okToStyle ifTrue: [styler styleInBackgroundProcess: textMorph contents] ifFalse: [textMorph contents: textMorph contents asString].! Item was changed: ----- Method: PluggableTextMorphPlus>>updateStyleNow (in category 'styling') ----- updateStyleNow + "Be sure to reset the style if it is not #okToStyle. Models might just send 'self changed: #style' without resetting the contents. See #update:." + - self okToStyle ifTrue: [styler style: textMorph contents] ifFalse: [textMorph contents: textMorph contents asString].! |
Wouldn't it be better if there were only a single method:
updateStyle: inTheBackground ... instead of duplicating the logic? Levente On Tue, 6 Aug 2019, [hidden email] wrote: > Marcel Taeumel uploaded a new version of ToolBuilder-Morphic to project The Trunk: > http://source.squeak.org/trunk/ToolBuilder-Morphic-mt.235.mcz > > ==================== Summary ==================== > > Name: ToolBuilder-Morphic-mt.235 > Author: mt > Time: 6 August 2019, 8:50:12.289656 am > UUID: 8fb2449e-5234-44cb-bba5-f7bcf80b3cef > Ancestors: ToolBuilder-Morphic-ct.234 > > Adds some comments. > > =============== Diff against ToolBuilder-Morphic-ct.234 =============== > > Item was changed: > ----- Method: PluggableTextMorphPlus>>updateStyle (in category 'styling') ----- > updateStyle > + "Be sure to reset the style if it is not #okToStyle. Models might just send 'self changed: #style' without resetting the contents. See #update:." > + > - > self okToStyle > ifTrue: [styler styleInBackgroundProcess: textMorph contents] > ifFalse: [textMorph contents: textMorph contents asString].! > > Item was changed: > ----- Method: PluggableTextMorphPlus>>updateStyleNow (in category 'styling') ----- > updateStyleNow > + "Be sure to reset the style if it is not #okToStyle. Models might just send 'self changed: #style' without resetting the contents. See #update:." > + > - > self okToStyle > ifTrue: [styler style: textMorph contents] > ifFalse: [textMorph contents: textMorph contents asString].! |
Assuming we're still talking about styling in the Workspaces, I'd like to suggest investigating having a Shout style that you can apply to any text within a workspace; then plain old notes can be left alone, code can be selected and marked as 'shoutable'. If that can be done, then one might imagine that style simply being the default style in code related text views.
> On 2019-08-06, at 11:39 AM, Levente Uzonyi <[hidden email]> wrote: > > Wouldn't it be better if there were only a single method: > > updateStyle: inTheBackground > > ... > > instead of duplicating the logic? > > > Levente tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Not much to show for four billion years of evolution. |
Hi Tim, that's a good idea. Yet, such a mechanism would be decoupled from the automatic styling pluggable text morphs can provide. Best, Marcel
|
> On 2019-08-06, at 11:57 PM, Marcel Taeumel <[hidden email]> wrote: > > Hi Tim, > > that's a good idea. Yet, such a mechanism would be decoupled from the automatic styling pluggable text morphs can provide. Well, nothing need stop styling being the default for certain varieties of text morph; it wouldn't have to be available only through a text style. But then again, consider this aspect - if the styling were done via a text style and that style were the default for code related textmorphs, then turning off styling would be merely a matter of changing the choice of default style. I'm not going to claim to have a precise plan how one might do shout styling via a textstyle but since the basics are pretty much 'take this string and render it via a process of applying font & colour attributes derived from the list in the style' why couldn't it work to insert 'according to the parser rules' at the end. I mean, add a few more tweaks and we could have some interesting formatting markers in the source. Sort of ST markdown. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Every bug you find is the last one. |
Hi Tim,
do you really mean a TextStyle from Graphics, or rather a TextAttribute from Collections-Text, such as TextEmphasis? We probably should merge this conversation with http://forum.world.st/The-Inbox-ToolBuilder-Morphic-ct-234-mcz-tp5101951p5102068.html.
(The light blue is the argument color in my personal UI theme, which come from a Context instance provided to the
styler.)
Just an application case where this could be really useful :)
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von tim Rowledge <[hidden email]>
Gesendet: Mittwoch, 7. August 2019 18:29:34 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Trunk: ToolBuilder-Morphic-mt.235.mcz > On 2019-08-06, at 11:57 PM, Marcel Taeumel <[hidden email]> wrote: > > Hi Tim, > > that's a good idea. Yet, such a mechanism would be decoupled from the automatic styling pluggable text morphs can provide. Well, nothing need stop styling being the default for certain varieties of text morph; it wouldn't have to be available only through a text style. But then again, consider this aspect - if the styling were done via a text style and that style were the default for code related textmorphs, then turning off styling would be merely a matter of changing the choice of default style. I'm not going to claim to have a precise plan how one might do shout styling via a textstyle but since the basics are pretty much 'take this string and render it via a process of applying font & colour attributes derived from the list in the style' why couldn't it work to insert 'according to the parser rules' at the end. I mean, add a few more tweaks and we could have some interesting formatting markers in the source. Sort of ST markdown. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Every bug you find is the last one.
Carpe Squeak!
|
> On 2019-08-07, at 9:45 AM, Thiede, Christoph <[hidden email]> wrote: > > Hi Tim, > > do you really mean a TextStyle from Graphics, or rather a TextAttribute from Collections-Text, such as TextEmphasis? Probably TextAttribute since they can be added to partial texts whereas styles pretty much have to be applied to an entire view's text ( at least, in the current rather tacky implementation). Or maybe a new thing that does a similar job but can also process the selected text. We have attributes for 'this is a doit', 'this is a link to a browsable item' and so on, so perhaps another one for 'this should be run through a processor' could work. There is of course a potential issue with clashing attributes; imagine some text that has been partly underlined and then some of it is selected for Shout-styling. We do already have some handling for this with the TextAttribute>>#dominates: methods, perhaps it sufficient as-is? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Never trust a computer you can't lift. |
Free forum by Nabble | Edit this page |