New subject: Proposal: Morphs in Text

24 Jun 2019

      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:
[image: old-anchor-alignment.png]
but with your change set, I can finally have the #bottom alignment I've
been wanting.
[image: 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 patrick.rein@hpi.uni-potsdam.de 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 patrick.rein@hpi.uni-potsdam.de <
patrick.rein@hpi.uni-potsdam.de>: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"]

Re: [squeak-dev] Proposal: Morphs in Text