Proposal: Morphs in Text

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Morphs in Text

patrick.rein
Hi everyone,

please find attached a change set which includes:
1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
#textAnchorVerticalAlignment:
#textAnchorPadding:
#textAnchorConsumesHorizontalSpace:

You can see an example by executing the body of the test:
TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently

!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!

I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.

Thanks and best wishes,
Patrick


TextAnchor placement.2.cs (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Nicolas Cellier
Hi Patrick,

i did not have time to inquire about the .cs but I can partially answer

Le mar. 28 mai 2019 à 18:27, <[hidden email]> a écrit :
Hi everyone,

please find attached a change set which includes:
1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
#textAnchorVerticalAlignment:
#textAnchorPadding:
#textAnchorConsumesHorizontalSpace:

You can see an example by executing the body of the test:
TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently

!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!

I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)
If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
 
2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
unless you have thousands of Morphs, you won't be able to measure any difference

3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)

4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...


Thanks and best wishes,
Patrick


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

marcel.taeumel
Yes, I also think that textAnchorType refers to further interaction between morph and the surrounding text (layout or paragraph).


Best,
Marcel

Am 28.05.2019 18:40:24 schrieb Nicolas Cellier <[hidden email]>:

Hi Patrick,

i did not have time to inquire about the .cs but I can partially answer

Le mar. 28 mai 2019 à 18:27, <[hidden email]> a écrit :
Hi everyone,

please find attached a change set which includes:
1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
#textAnchorVerticalAlignment:
#textAnchorPadding:
#textAnchorConsumesHorizontalSpace:

You can see an example by executing the body of the test:
TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently

!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!

I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)
If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
 
2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
unless you have thousands of Morphs, you won't be able to measure any difference

3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)

4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...


Thanks and best wishes,
Patrick


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

K K Subbu
In reply to this post by patrick.rein
Thank you, Patrick, for your initiatives. TextMorph really needs some
attention.

On 28/05/19 9:48 PM, [hidden email] wrote:
> 1.) Should the alignment information be stored in the Morph or the
> TextAnchorAttribute? Currently the information is stored in the Morph
> which parallels LayoutProperties.

John Maloney's seminal paper on Morphic presented Morph as a graphical
unit for direct interaction (event handling) and liveness (stepping). It
was silent on modeling relations between morphs (with some exceptions).

Alignment and anchoring are properties of relationship between two
morphs rather than an intrinsic property of a Morph. I feel they should
be handled by subclasses (isA) or objects (hasA). Morph is already
pretty large for a basic unit.

> 4.) Does anyone remember / know what the textAnchorType was intended
> for? The previous implementation largely ignored it and this one does
> so too.
I think it was intended to stick a morph to a position within its
container (#document) or flow with other text morphs as paragraphs
(#paragraph) or character spans (#inline).

Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

timrowledge
In reply to this post by marcel.taeumel


> On 2019-05-28, at 11:51 PM, Marcel Taeumel <[hidden email]> wrote:
>
> Yes, I also think that textAnchorType refers to further interaction between morph and the surrounding text (layout or paragraph).

Generically thinking, for stuff like this it might be worth taking a look at the code for the Sophie project. We did a *lot* of text handling. I certainly won't claim we did it perfectly but it was quite good looking and reasonably fast - for example loading documents faster than Word.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
42.7 percent of all statistics are made up on the spot.



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
In reply to this post by Nicolas Cellier
Hi everyone,

thanks Nicolas and Subbu for the answers.

I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.

Given that we interpret the textAnchorType as the floating behavior, we would end up with:
#inline: Inline the text flow
#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow

If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.

Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.

Bests
Patrick

>Hi Patrick,
>
>i did not have time to inquire about the .cs but I can partially answer
>
>Le mar. 28 mai 2019 à 18:27, <[hidden email]> a écrit :
>
>Hi everyone,
>
>please find attached a change set which includes:
>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>#textAnchorVerticalAlignment:
>#textAnchorPadding:
>#textAnchorConsumesHorizontalSpace:
>
>You can see an example by executing the body of the test:
>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>
>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>
>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>
>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>
>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>
>unless you have thousands of Morphs, you won't be able to measure any difference
>
>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>
>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>
>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>
>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>
>
>Thanks and best wishes,
>Patrick
>
>--000000000000bedde40589f5512a--

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Chris Muller-3
In reply to this post by patrick.rein
Hi Patrick,

It breaks something with layout of non-ascii characters.   Try
selecting a binary file in the FileBrowser.  Warning:  save your image first.



 - Chris



On Tue, May 28, 2019 at 11:27 AM <[hidden email]> wrote:

>
> Hi everyone,
>
> please find attached a change set which includes:
> 1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
> 2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
> #textAnchorVerticalAlignment:
> #textAnchorPadding:
> #textAnchorConsumesHorizontalSpace:
>
> You can see an example by executing the body of the test:
> TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>
> !Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>
> I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
> 1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
> 2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
> 3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
> 4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>
> Thanks and best wishes,
> Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
In reply to this post by Nicolas Cellier
Hi everyone :)

please find attached a new version of the repaired/improved morph in text support :)

This changeset includes:
- less strict treatment of the start of header character so that binary files should display correctly again
- refactored the text anchor properties into a separate object which every morph can have as an extension
- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
- added basic support for vertical padding
- Examples! (Execute TextAnchor alignmentExamples)
- improved and added tests

Please try it out! :) Feedback is very welcome :)

Questions I still have are
- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
- Should we deprecate the old text anchor property methods on Morph or directly remove them?

The major missing aspect is some more documentation on TextAnchor.

Bests
Patrick

>Hi everyone,
>
>thanks Nicolas and Subbu for the answers.
>
>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>
>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>#inline: Inline the text flow
>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>
>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>
>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>
Best>s

>Patrick
>
>>Hi Patrick,
>>
>>i did not have time to inquire about the .cs but I can partially answer
>>
>>Le mar. 28 mai 2019 à 18:27, <[hidden email]> a écrit :
>>
>>Hi everyone,
>>
>>please find attached a change set which includes:
>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>#textAnchorVerticalAlignment:
>>#textAnchorPadding:
>>#textAnchorConsumesHorizontalSpace:
>>
>>You can see an example by executing the body of the test:
>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>
>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>
>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>
>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>
>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>
>>unless you have thousands of Morphs, you won't be able to measure any difference
>>
>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>
>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>
>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>
>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>
>>
>>Thanks and best wishes,
>>Patrick
>>
>>--000000000000bedde40589f5512a--
["ChangeSetRefactoring.cs"]


ChangeSetRefactoring.cs (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
In reply to this post by Nicolas Cellier
Please find the correct change set in this mail... :)

>Hi everyone :)
>
>please find attached a new version of the repaired/improved morph in text support :)
>
>This changeset includes:
>- less strict treatment of the start of header character so that binary files should display correctly again
>- refactored the text anchor properties into a separate object which every morph can have as an extension
>- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
>- added basic support for vertical padding
>- Examples! (Execute TextAnchor alignmentExamples)
>- improved and added tests
>
>Please try it out! :) Feedback is very welcome :)
>
>Questions I still have are
>- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>- Should we deprecate the old text anchor property methods on Morph or directly remove them?
>
>The major missing aspect is some more documentation on TextAnchor.
>
>Bests
>Patrick
>
>>Hi everyone,
>>
>>thanks Nicolas and Subbu for the answers.
>>
>>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>>
>>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>>#inline: Inline the text flow
>>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>>
>>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>>
>>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>>
>Best>s
>>Patrick
>>
>>>Hi Patrick,
>>>
>>>i did not have time to inquire about the .cs but I can partially answer
>>>
>>>Le mar. 28 mai 2019 ࠱8:27, <[hidden email]> a 飲it :
>>>
>>>Hi everyone,
>>>
>>>please find attached a change set which includes:
>>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>>#textAnchorVerticalAlignment:
>>>#textAnchorPadding:
>>>#textAnchorConsumesHorizontalSpace:
>>>
>>>You can see an example by executing the body of the test:
>>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>>
>>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>>
>>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>>
>>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>>
>>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>>
>>>unless you have thousands of Morphs, you won't be able to measure any difference
>>>
>>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>>
>>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>>
>>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>>
>>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>>
>>>
>>>Thanks and best wishes,
>>>Patrick
>>>
>>>--000000000000bedde40589f5512a--
>["ChangeSetRefactoring.cs"]
>
>
>[ChangeSetRefactoring.cs]
["TextAnchorPlacement.cs"]


TextAnchorPlacement.cs (95K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

marcel.taeumel
Hi Patrick.

> Should we deprecate the old text anchor property methods on Morph or directly remove them?

+1 for deprecation first, removal later.

> Do we want a more extensive text anchor menu?

Sure. :-)

Would it be fine to implement the menu creation logic on the TextAnchorProperties class?

I think, it would be okay. TextAnchor and TextAnchorProperties are additions from Morphic to the base system (i.e., Collections and Graphics). Yet, it could be kind of misleading for later to also add menu logic to other, non-morphic, text attributes. Hm...

**

Could you update (or extend) the commentary for the following methods?

TextMorphForEditView >> #defaultTextModificationCharacterSet
TextAttribute >> #writeScanOn:

Thanks for working on this. All TextAnchorTest tests pass (or fail as expected ;P).

**

I noticed a little layout glitch in the TextAnchor alignmentExamples. You can see it if you do "demoMorph imageForm asMorph openInHand" instead of "openInWorld". Is this new?

Best,
Marcel

Am 11.06.2019 17:06:28 schrieb [hidden email] <[hidden email]>:

Please find the correct change set in this mail... :)

>Hi everyone :)
>
>please find attached a new version of the repaired/improved morph in text support :)
>
>This changeset includes:
>- less strict treatment of the start of header character so that binary files should display correctly again
>- refactored the text anchor properties into a separate object which every morph can have as an extension
>- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
>- added basic support for vertical padding
>- Examples! (Execute TextAnchor alignmentExamples)
>- improved and added tests
>
>Please try it out! :) Feedback is very welcome :)
>
>Questions I still have are
>- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>- Should we deprecate the old text anchor property methods on Morph or directly remove them?
>
>The major missing aspect is some more documentation on TextAnchor.
>
>Bests
>Patrick
>
>>Hi everyone,
>>
>>thanks Nicolas and Subbu for the answers.
>>
>>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>>
>>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>>#inline: Inline the text flow
>>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>>
>>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>>
>>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>>
>Best>s
>>Patrick
>>
>>>Hi Patrick,
>>>
>>>i did not have time to inquire about the .cs but I can partially answer
>>>
>>>Le mar. 28 mai 2019 ࠱8:27, a 飲it :
>>>
>>>Hi everyone,
>>>
>>>please find attached a change set which includes:
>>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>>#textAnchorVerticalAlignment:
>>>#textAnchorPadding:
>>>#textAnchorConsumesHorizontalSpace:
>>>
>>>You can see an example by executing the body of the test:
>>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>>
>>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>>
>>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>>
>>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>>
>>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>>
>>>unless you have thousands of Morphs, you won't be able to measure any difference
>>>
>>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>>
>>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>>
>>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>>
>>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>>
>>>
>>>Thanks and best wishes,
>>>Patrick
>>>
>>>--000000000000bedde40589f5512a--
>["ChangeSetRefactoring.cs"]
>
>
>[ChangeSetRefactoring.cs]
["TextAnchorPlacement.cs"]



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
Hi everyone,

please find attached an updated version of the Morphs in Text changeset. I consider this a final version, which I would like to merge into trunk.

In comparison to the previous changeset it now includes deprecated methods, an extended text anchor menu, and some more comments.

Regarding the layout glitch: it is not related to the changeset. It is related to Morph>>#imageForm using #fullBounds. We are using a layoutPolicy for the Morph in the example method and this seems to cause issues as the full sizes of the text morphs are not known yet. Consequently, full bounds is very large and thus the imageForm looks weird. For example, the issue does not occur when doing two imageForm calls after another.

Bests
Patrick

>Hi Patrick.
>> Should we deprecate the old text anchor property methods on Morph or directly remove them?
>+1 for deprecation first, removal later.
>> Do we want a more extensive text anchor menu?
>Sure. :-)
>> Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>I think, it would be okay. TextAnchor and TextAnchorProperties are additions from Morphic to the base system (i.e., Collections and Graphics). Yet, it could be kind of misleading for later to also add menu logic to other, non-morphic, text attributes. Hm...
>**
>Could you update (or extend) the commentary for the following methods?
>TextMorphForEditView >> #defaultTextModificationCharacterSetTextAttribute >> #writeScanOn:
>Thanks for working on this. All TextAnchorTest tests pass (or fail as expected ;P).
>**
>I noticed a little layout glitch in the TextAnchor alignmentExamples. You can see it if you do "demoMorph imageForm asMorph openInHand" instead of "openInWorld". Is this new?
>Best,Marcel
>
>Am 11.06.2019 17:06:28 schrieb [hidden email] <[hidden email]>:Please find the correct change set in this mail... :)
>
>>Hi everyone :)
>>
>>please find attached a new version of the repaired/improved morph in text support :)
>>
>>This changeset includes:
>>- less strict treatment of the start of header character so that binary files should display correctly again
>>- refactored the text anchor properties into a separate object which every morph can have as an extension
>>- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
>>- added basic support for vertical padding
>>- Examples! (Execute TextAnchor alignmentExamples)
>>- improved and added tests
>>
>>Please try it out! :) Feedback is very welcome :)
>>
>>Questions I still have are
>>- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>>- Should we deprecate the old text anchor property methods on Morph or directly remove them?
>>
>>The major missing aspect is some more documentation on TextAnchor.
>>
>>Bests
>>Patrick
>>
>>>Hi everyone,
>>>
>>>thanks Nicolas and Subbu for the answers.
>>>
>>>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>>>
>>>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>>>#inline: Inline the text flow
>>>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>>>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>>>
>>>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>>>
>>>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>>>
>>Best>s
>>>Patrick
>>>
>>>>Hi Patrick,
>>>>
>>>>i did not have time to inquire about the .cs but I can partially answer
>>>>
>>>>Le mar. 28 mai 2019 ࠱8:27, a 飲it :
>>>>
>>>>Hi everyone,
>>>>
>>>>please find attached a change set which includes:
>>>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>>>#textAnchorVerticalAlignment:
>>>>#textAnchorPadding:
>>>>#textAnchorConsumesHorizontalSpace:
>>>>
>>>>You can see an example by executing the body of the test:
>>>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>>>
>>>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>>>
>>>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>>>
>>>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>>>
>>>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>>>
>>>>unless you have thousands of Morphs, you won't be able to measure any difference
>>>>
>>>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>>>
>>>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>>>
>>>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>>>
>>>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>>>
>>>>
>>>>Thanks and best wishes,
>>>>Patrick
>>>>
>>>>--000000000000bedde40589f5512a--
>>["ChangeSetRefactoring.cs"]
>>
>>
>>[ChangeSetRefactoring.cs]
>["TextAnchorPlacement.cs"]
>
>------=_NextPart_52154164.987237250046--
["TextAnchorPlacement.cs"]


TextAnchorPlacement.cs (97K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

marcel.taeumel
Hi Patrick

> Regarding the layout glitch: it is not related to the changeset. It is related to Morph>>#imageForm using #fullBounds. We are using a layoutPolicy for the Morph in the example  method and this seems to cause issues as the full sizes of the text morphs are not known yet. Consequently, full bounds is very large and thus the imageForm looks weird. For  example, the issue does not occur when doing two imageForm calls after another.

That's correct. The interference between text layouting and morph layouting is not related to this change. That's an older bug in Morphic's general layouting mechanism, which does not care about morphs only having a height after getting a specific width. Or the other way round.

For clarification: I just used #imageForm to illustrate the bug. Noticable flickering occurs in your example without calling #imageForm because regular drawing uses #fullBounds, too.

Best,
Marcel

Am 24.06.2019 13:59:49 schrieb [hidden email] <[hidden email]>:

Hi everyone,

please find attached an updated version of the Morphs in Text changeset. I consider this a final version, which I would like to merge into trunk.

In comparison to the previous changeset it now includes deprecated methods, an extended text anchor menu, and some more comments.

Regarding the layout glitch: it is not related to the changeset. It is related to Morph>>#imageForm using #fullBounds. We are using a layoutPolicy for the Morph in the example method and this seems to cause issues as the full sizes of the text morphs are not known yet. Consequently, full bounds is very large and thus the imageForm looks weird. For example, the issue does not occur when doing two imageForm calls after another.

Bests
Patrick

>Hi Patrick.
>> Should we deprecate the old text anchor property methods on Morph or directly remove them?
>+1 for deprecation first, removal later.
>> Do we want a more extensive text anchor menu?
>Sure. :-)
>> Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>I think, it would be okay. TextAnchor and TextAnchorProperties are additions from Morphic to the base system (i.e., Collections and Graphics). Yet, it could be kind of misleading for later to also add menu logic to other, non-morphic, text attributes. Hm...
>**
>Could you update (or extend) the commentary for the following methods?
>TextMorphForEditView >> #defaultTextModificationCharacterSetTextAttribute >> #writeScanOn:
>Thanks for working on this. All TextAnchorTest tests pass (or fail as expected ;P).
>**
>I noticed a little layout glitch in the TextAnchor alignmentExamples. You can see it if you do "demoMorph imageForm asMorph openInHand" instead of "openInWorld". Is this new?
>Best,Marcel
>
>Am 11.06.2019 17:06:28 schrieb [hidden email] :Please find the correct change set in this mail... :)
>
>>Hi everyone :)
>>
>>please find attached a new version of the repaired/improved morph in text support :)
>>
>>This changeset includes:
>>- less strict treatment of the start of header character so that binary files should display correctly again
>>- refactored the text anchor properties into a separate object which every morph can have as an extension
>>- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
>>- added basic support for vertical padding
>>- Examples! (Execute TextAnchor alignmentExamples)
>>- improved and added tests
>>
>>Please try it out! :) Feedback is very welcome :)
>>
>>Questions I still have are
>>- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>>- Should we deprecate the old text anchor property methods on Morph or directly remove them?
>>
>>The major missing aspect is some more documentation on TextAnchor.
>>
>>Bests
>>Patrick
>>
>>>Hi everyone,
>>>
>>>thanks Nicolas and Subbu for the answers.
>>>
>>>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>>>
>>>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>>>#inline: Inline the text flow
>>>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>>>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>>>
>>>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>>>
>>>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>>>
>>Best>s
>>>Patrick
>>>
>>>>Hi Patrick,
>>>>
>>>>i did not have time to inquire about the .cs but I can partially answer
>>>>
>>>>Le mar. 28 mai 2019 ࠱8:27, a 飲it :
>>>>
>>>>Hi everyone,
>>>>
>>>>please find attached a change set which includes:
>>>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>>>#textAnchorVerticalAlignment:
>>>>#textAnchorPadding:
>>>>#textAnchorConsumesHorizontalSpace:
>>>>
>>>>You can see an example by executing the body of the test:
>>>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>>>
>>>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>>>
>>>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>>>
>>>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>>>
>>>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>>>
>>>>unless you have thousands of Morphs, you won't be able to measure any difference
>>>>
>>>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>>>
>>>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>>>
>>>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>>>
>>>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>>>
>>>>
>>>>Thanks and best wishes,
>>>>Patrick
>>>>
>>>>--000000000000bedde40589f5512a--
>>["ChangeSetRefactoring.cs"]
>>
>>
>>[ChangeSetRefactoring.cs]
>["TextAnchorPlacement.cs"]
>
>------=_NextPart_52154164.987237250046--
["TextAnchorPlacement.cs"]



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Chris Muller-3
In reply to this post by marcel.taeumel
Hi Patrick,

Thanks for doing this.  Maui makes heavy use of domain objects embedded as characters in free-form text fields, but they currently look like this:

old-anchor-alignment.png 

but with your change set, I can finally have the #bottom alignment I've been wanting.

new-anchor-alignment.png

Great!

The only thing that gave me pause was that API for #verticalAlignment:.  Initially, I just saw the selector and thought about it the same as the API for regular horizontal text alignment (e.g., #left, #center, #right, justified), and so tried:

    self verticalAlignment: #bottom

but this informed me that this single-argument selector is actually looking for two arguments.  That's some great flexibility that I didn't even consider, but I wonder whether this detracts from the usability of the common cases:

   #bottom, expected to do what #(#bottom #bottom) does,
   #center, to do what, uh, #(#middle #middle) does, and
   #top, would do what, #top #top does.

#verticalAlignment: handle the above, while #verticalAlignmentMorph: and #verticalAlignmentLine: could be used for advanced customizations.  Even once I figured out it wanted a two-element Array for input, I had to go back look at the method to remind myself which is first and which is second.  Separate attributes would be more readable.

Lastly, #middle vs. #center.  #center is what we have _everywhere_ to refer to geometric centers, all over the image, including even for horizontal text-alignment.  The only #middle in the whole image relates to a Collection element access.  Could we use #center?

Regards,
  Chris


On Mon, Jun 24, 2019 at 6:59 AM <[hidden email]> wrote:
Hi everyone,

please find attached an updated version of the Morphs in Text changeset. I consider this a final version, which I would like to merge into trunk.

In comparison to the previous changeset it now includes deprecated methods, an extended text anchor menu, and some more comments.

Regarding the layout glitch: it is not related to the changeset. It is related to Morph>>#imageForm using #fullBounds. We are using a layoutPolicy for the Morph in the example method and this seems to cause issues as the full sizes of the text morphs are not known yet. Consequently, full bounds is very large and thus the imageForm looks weird. For example, the issue does not occur when doing two imageForm calls after another.

Bests
Patrick

>Hi Patrick.
>> Should we deprecate the old text anchor property methods on Morph or directly remove them?
>+1 for deprecation first, removal later.
>> Do we want a more extensive text anchor menu?
>Sure. :-)
>> Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>I think, it would be okay. TextAnchor and TextAnchorProperties are additions from Morphic to the base system (i.e., Collections and Graphics). Yet, it could be kind of misleading for later to also add menu logic to other, non-morphic, text attributes. Hm...
>**
>Could you update (or extend) the commentary for the following methods?
>TextMorphForEditView >> #defaultTextModificationCharacterSetTextAttribute >> #writeScanOn:
>Thanks for working on this. All TextAnchorTest tests pass (or fail as expected ;P).
>**
>I noticed a little layout glitch in the TextAnchor alignmentExamples. You can see it if you do "demoMorph imageForm asMorph openInHand" instead of "openInWorld". Is this new?
>Best,Marcel
>
>Am 11.06.2019 17:06:28 schrieb [hidden email] <[hidden email]>:Please find the correct change set in this mail... :)
>
>>Hi everyone :)
>>
>>please find attached a new version of the repaired/improved morph in text support :)
>>
>>This changeset includes:
>>- less strict treatment of the start of header character so that binary files should display correctly again
>>- refactored the text anchor properties into a separate object which every morph can have as an extension
>>- removed the partially implemented #paragraph layouting style and finished the #inline and #document layouting styles
>>- added basic support for vertical padding
>>- Examples! (Execute TextAnchor alignmentExamples)
>>- improved and added tests
>>
>>Please try it out! :) Feedback is very welcome :)
>>
>>Questions I still have are
>>- Do we want a more extensive text anchor menu? Currently, only the layout style is accessible through the menu. Would it be fine to implement the menu creation logic on the TextAnchorProperties class?
>>- Should we deprecate the old text anchor property methods on Morph or directly remove them?
>>
>>The major missing aspect is some more documentation on TextAnchor.
>>
>>Bests
>>Patrick
>>
>>>Hi everyone,
>>>
>>>thanks Nicolas and Subbu for the answers.
>>>
>>>I did not think about the concept of a morph having a baseline too but it sounds like a good idea. I'll try to accomodate it in the new alignment logic.
>>>
>>>Given that we interpret the textAnchorType as the floating behavior, we would end up with:
>>>#inline: Inline the text flow
>>>#paragraph: The morph is displayed on its own line (_Not_ the semantic of having a morph within a chain of TextMorphs)
>>>#document: The morph can be placed freely within the document and is neither influenenced by the text flow, nor does it influence the text flow
>>>
>>>If that sounds about right I would go on to implement the behavior like that, as it currently does not really work like that. In the course of that it might make sense to rename textAnchorType so something else.
>>>
>>>Based on Subbus comment I will also move the new properties and methods on morphs into a class TextAnchorProperties which will then be referenced by a morph. This should actually make the morph interface smaller than it is right now.
>>>
>>Best>s
>>>Patrick
>>>
>>>>Hi Patrick,
>>>>
>>>>i did not have time to inquire about the .cs but I can partially answer
>>>>
>>>>Le mar. 28 mai 2019 ࠱8:27, a 飲it :
>>>>
>>>>Hi everyone,
>>>>
>>>>please find attached a change set which includes:
>>>>1.) Some fixes to the Scanner infrastructure to support Morphs in Text better
>>>>2.) Improvements to describe how a Morph should be aligned with regard to the text. Relevant methods on Morph are:
>>>>#textAnchorVerticalAlignment:
>>>>#textAnchorPadding:
>>>>#textAnchorConsumesHorizontalSpace:
>>>>
>>>>You can see an example by executing the body of the test:
>>>>TextAnchorTest>>#testHavingAnAnchorCanBeAlignedDifferently
>>>>
>>>>!Warning: As this touches Scanner code a lot, loading this change set might make your image unresponsive!
>>>>
>>>>I would like to point out that the test cases are preliminary and a few of the methods still require polishing. Nevertheless, I would like to ask for comments on the change set, in particular regarding:
>>>>1.) Should the alignment information be stored in the Morph or the TextAnchorAttribute? Currently the information is stored in the Morph which parallels LayoutProperties.
>>>>
>>>>I think it should be in Morph, because Morph can have its own notion of baseline etc... (imagine for example that I want to render a FractionMathMorph 1/(1/x+1), then I want the main (upper) fraction bar to be somehow aligned with the text baseline)If Morph does not carry such information, then we can wrap in another Morph that does (but I'm not sure that's how Morph works currently...)
>>>>
>>>>2.) Is using caseOf: in Scanner code fine? I suspect it to be quite expensive which is probably not a good thing in Scanners?
>>>>
>>>>unless you have thousands of Morphs, you won't be able to measure any difference
>>>>
>>>>3.) Should the cursor allow users to navigate (or select?) the "start of header" character that is used to denote the text anchor placement?
>>>>
>>>>If Morph is aligned with text (renderd as if a single character), then i would expect so (so as to be able to copy/paste for example)
>>>>
>>>>4.) Does anyone remember / know what the textAnchorType was intended for? The previous implementation largely ignored it and this one does so too.
>>>>
>>>>I guess it could be like classical editors: Morph aligned with text (as a single character) or super-imposed over text, or text wraps around the morph, or ...
>>>>
>>>>
>>>>Thanks and best wishes,
>>>>Patrick
>>>>
>>>>--000000000000bedde40589f5512a--
>>["ChangeSetRefactoring.cs"]
>>
>>
>>[ChangeSetRefactoring.cs]
>["TextAnchorPlacement.cs"]
>
>------=_NextPart_52154164.987237250046--
["TextAnchorPlacement.cs"]


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
Hi Chris,

thanks for the recommendations!

>The only thing that gave me pause was that API for #verticalAlignment:.  Initially, I just saw the selector and thought about it the same as the API for regular horizontal text alignment (e.g., #left, #center, #right, justified), and so tried:
>    self verticalAlignment: #bottom
>but this informed me that this single-argument selector is actually looking for two arguments.  That's some great flexibility that I didn't even consider, but I wonder whether this detracts from the usability of the common cases:
>   #bottom, expected to do what #(#bottom #bottom) does,   #center, to do what, uh, #(#middle #middle) does, and   #top, would do what, #top #top does.
>#verticalAlignment: handle the above, while #verticalAlignmentMorph: and #verticalAlignmentLine: could be used for advanced customizations.  Even once I figured out it wanted a two-element Array for input, I had to go back look at the method to remind myself which is first and which is second.  Separate attributes would be more readable.

That is a good point. I myself had some difficulties remembering which way they have to go... I have added a convenience case which now allows for just sending a symbol and the method takes care of converting it to the array internally (so #top results in #(top top)).

>Lastly, #middle vs. #center.  #center is what we have _everywhere_ to refer to geometric centers, all over the image, including even for horizontal text-alignment.  The only #middle in the whole image relates to a Collection element access.  Could we use #center?

Yes, that makes sense :) I renamed #middle to #center.

The new changeset includes these changes.

Bests
Patrick


["TextAnchorPlacement.cs"]


TextAnchorPlacement.cs (99K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

patrick.rein
In reply to this post by Chris Muller-3
Hi everyone,

please find attached a new version of the change including an improved protocol for setting the alignment added by Chris (basically as discussed below). :)

Bests
Patrick

>Hi Chris,
>
>thanks for the recommendations!
>
>>The only thing that gave me pause was that API for #verticalAlignment:.  Initially, I just saw the selector and thought about it the same as the API for regular horizontal text alignment (e.g., #left, #center, #right, justified), and so tried:
>>    self verticalAlignment: #bottom
>>but this informed me that this single-argument selector is actually looking for two arguments.  That's some great flexibility that I didn't even consider, but I wonder whether this detracts from the usability of the common cases:
>>   #bottom, expected to do what #(#bottom #bottom) does,   #center, to do what, uh, #(#middle #middle) does, and   #top, would do what, #top #top does.
>>#verticalAlignment: handle the above, while #verticalAlignmentMorph: and #verticalAlignmentLine: could be used for advanced customizations.  Even once I figured out it wanted a two-element Array for input, I had to go back look at the method to remind myself which is first and which is second.  Separate attributes would be more readable.
>
>That is a good point. I myself had some difficulties remembering which way they have to go... I have added a convenience case which now allows for just sending a symbol and the method takes care of converting it to the array internally (so #top results in #(top top)).
>
>>Lastly, #middle vs. #center.  #center is what we have _everywhere_ to refer to geometric centers, all over the image, including even for horizontal text-alignment.  The only #middle in the whole image relates to a Collection element access.  Could we use #center?
>
>Yes, that makes sense :) I renamed #middle to #center.
>
>The new changeset includes these changes.
>
>Bests
>Patrick
>
>
>["TextAnchorPlacement.cs"]
>
>
>[TextAnchorPlacement.cs]
["TextAnchorPlacement.cs"]


TextAnchorPlacement.cs (101K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Karl Ramberg
In reply to this post by Chris Muller-3
I'm a little late here.
TextMorph does not really need TextAnchor I think.
You can just drop morphs on the text and select avoid occlusions in the menu.
What are the use of text anchors instead just dropped in morphs ?
I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.

Best,
Karl






On Fri, Jun 28, 2019 at 4:42 PM <[hidden email]> wrote:
Hi everyone,

please find attached a new version of the change including an improved protocol for setting the alignment added by Chris (basically as discussed below). :)

Bests
Patrick

>Hi Chris,
>
>thanks for the recommendations!
>
>>The only thing that gave me pause was that API for #verticalAlignment:.  Initially, I just saw the selector and thought about it the same as the API for regular horizontal text alignment (e.g., #left, #center, #right, justified), and so tried:
>>    self verticalAlignment: #bottom
>>but this informed me that this single-argument selector is actually looking for two arguments.  That's some great flexibility that I didn't even consider, but I wonder whether this detracts from the usability of the common cases:
>>   #bottom, expected to do what #(#bottom #bottom) does,   #center, to do what, uh, #(#middle #middle) does, and   #top, would do what, #top #top does.
>>#verticalAlignment: handle the above, while #verticalAlignmentMorph: and #verticalAlignmentLine: could be used for advanced customizations.  Even once I figured out it wanted a two-element Array for input, I had to go back look at the method to remind myself which is first and which is second.  Separate attributes would be more readable.
>
>That is a good point. I myself had some difficulties remembering which way they have to go... I have added a convenience case which now allows for just sending a symbol and the method takes care of converting it to the array internally (so #top results in #(top top)).
>
>>Lastly, #middle vs. #center.  #center is what we have _everywhere_ to refer to geometric centers, all over the image, including even for horizontal text-alignment.  The only #middle in the whole image relates to a Collection element access.  Could we use #center?
>
>Yes, that makes sense :) I renamed #middle to #center.
>
>The new changeset includes these changes.
>
>Bests
>Patrick
>
>
>["TextAnchorPlacement.cs"]
>
>
>[TextAnchorPlacement.cs]
["TextAnchorPlacement.cs"]


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Chris Muller-4
> I'm a little late here.
> TextMorph does not really need TextAnchor I think.
> You can just drop morphs on the text and select avoid occlusions in the menu.
> What are the use of text anchors instead just dropped in morphs ?
> I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.

I was wondering about the 'avoid occlusions' but spent all my focus on
the alignment testing, thanks for testing that too!

We should not break that.  I like this new alignment capability, but
classic DTP text-handling is one of Squeak's most impressive
capabilities.  Hopefully an easy fix..?


 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

marcel.taeumel
Hi Chris,

what does "DTP" stand for? 

Best,
Marcel

Am 01.07.2019 02:19:19 schrieb Chris Muller <[hidden email]>:

> I'm a little late here.
> TextMorph does not really need TextAnchor I think.
> You can just drop morphs on the text and select avoid occlusions in the menu.
> What are the use of text anchors instead just dropped in morphs ?
> I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.

I was wondering about the 'avoid occlusions' but spent all my focus on
the alignment testing, thanks for testing that too!

We should not break that. I like this new alignment capability, but
classic DTP text-handling is one of Squeak's most impressive
capabilities. Hopefully an easy fix..?


- Chris



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Karl Ramberg
Desk Top Publishing ?

Best,
Karl

On Mon, Jul 1, 2019 at 9:02 AM Marcel Taeumel <[hidden email]> wrote:
Hi Chris,

what does "DTP" stand for? 

Best,
Marcel

Am 01.07.2019 02:19:19 schrieb Chris Muller <[hidden email]>:

> I'm a little late here.
> TextMorph does not really need TextAnchor I think.
> You can just drop morphs on the text and select avoid occlusions in the menu.
> What are the use of text anchors instead just dropped in morphs ?
> I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.

I was wondering about the 'avoid occlusions' but spent all my focus on
the alignment testing, thanks for testing that too!

We should not break that. I like this new alignment capability, but
classic DTP text-handling is one of Squeak's most impressive
capabilities. Hopefully an easy fix..?


- Chris



Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Morphs in Text

Karl Ramberg
In reply to this post by Chris Muller-4
One big issue with the drag and drop is that it is often not clear which morph one drop into.
There are so many layers of morphs in a text window so it gets confusing to know which morph to actually
enable to accepting the drop.

But drag and drop are probably a separate issue from text anchors constructed from 
code. Just don't break it to badly  :-)


Best,
Karl



Best.
Karl



On Mon, Jul 1, 2019 at 2:19 AM Chris Muller <[hidden email]> wrote:
> I'm a little late here.
> TextMorph does not really need TextAnchor I think.
> You can just drop morphs on the text and select avoid occlusions in the menu.
> What are the use of text anchors instead just dropped in morphs ?
> I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.

I was wondering about the 'avoid occlusions' but spent all my focus on
the alignment testing, thanks for testing that too!

We should not break that.  I like this new alignment capability, but
classic DTP text-handling is one of Squeak's most impressive
capabilities.  Hopefully an easy fix..?


 - Chris


12