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(a)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(a)hpi.uni-potsdam.de <
> patrick.rein(a)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"]
>
