[squeak-dev] Proposal: Morphs in Text

karl ramberg karlramberg at gmail.com
Thu Jul 4 13:46:48 UTC 2019


I tested drag and drop of morphs into a "bare" TextMorph and that works
quite nice.
But trying to drop stuff into the text in a Workspace and or a
ScrollingText is not easy to enable.
I'm sure it is possible to set up, but had no luck with it.

Best,
Karl



On Wed, Jul 3, 2019 at 10:58 PM Chris Muller <ma.chris.m at gmail.com> wrote:

> Hi Karl, I'm not sure what or how you tested, but "drag and drop of
> morph on text in windows" works fine when the appropriate handlers are
> set up (#mouseEnter:, etc.).
>
> You can see it in action if you're willing to load Maui into a trunk
> image (from SqueakMap).  It has a class MauiTextEditor, which is just
> a subclass of PluggableTextMorph with the handlers.
>
>     MauiTextEditor new openInWorld
>
> type some text,
> grab any Morph and, while holding Shift,
> drag it into the text window.
>
> An outline of the proposed position is shown, when you let go, the
> morph is dropped and embedded as a character.  Works with clipboard, etc.
>
>  - Chris
>
>
>  - Chris
>
> On Wed, Jul 3, 2019 at 3:36 PM karl ramberg <karlramberg at gmail.com> wrote:
> >
> > I did some more testing and found the drag and drop of morph on text in
> windows practically non functional.
> > So I don't think you could break anything :-)
> >
> > Best,
> > Karl
> >
> >
> > On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick <Patrick.Rein at hpi.de>
> wrote:
> >>
> >> Hi Karl,
> >>
> >> I agree that the drag and drop handling of TextMorphs is somewhat
> complex by now.  While looking into the issue I found two kinds of issues:
> some more general ones and one related to layouting.
> >>
> >> ## General Occlusion Bug
> >>
> >> I have to admit that I was not aware of the avoid occlusions feature. I
> dug into it a little and
> >> found TextContainer and the class comment which explains the feature.
> Then I constructed
> >> the following example:
> >>
> >> o := Morph new.
> >> tm := TextMorph new
> >>         contents: 'This is a very long text with a lot of characters
> >> spanning multiple lines overall and throughout the
> >> place in order to trigger the occlusion thing';
> >>         yourself.
> >> m := RectangleMorph new.
> >> m position: tm topLeft + (10 at 10).
> >> tm occlusionsOnOff.
> >> o addMorph: tm.
> >> o addMorph: m.
> >> o openInWorld.
> >>
> >> I tried it in trunk and Squeak 3.8 and in both it results in errors in
> NewParagraph>>#adjustRightX as
> >> it expects container to behave like a rectangle.
> >>
> >> However, the root cause seems to be that #adjustRightX does not make
> sense when having a fixed
> >> TextContainer as it describes the individual rectangles in which the
> text can be set. One solution is
> >> to set `tm wrapFlag: true` before turning avoidOcclusions on (otherwise
> #wrapFlag triggers a relayout
> >> without tm having an owner which does not work...).
> >>
> >> To make this more robust I would propose:
> >> 1.) When activating occlusion we also set the wrapFlag
> >> 2.) We do not try to avoid occlusions as long as the morph does not
> have an owner yet.
> >>
> >> ## Text Anchor Related
> >>
> >> Maybe this is more what you were thinking about Karl: I found that when
> having the above example
> >> plus an anchored morph which is layouted inline most things work fine.
> Except for the layout issue
> >> you can see in the attachment (the first morph in the third line is the
> anchored morph, the second one
> >> is the m from the example above). The second part of the third line
> does not adhere to the offset of the
> >> first part of the line. @Karl: Did you refer to that? (Not sure how to
> fix this yet...)
> >>
> >> Bests
> >> Patrick
> >> ________________________________________
> >> From: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> on
> behalf of karl ramberg <karlramberg at gmail.com>
> >> Sent: Monday, July 1, 2019 11:44:34 AM
> >> To: Chris Muller
> >> Cc: The general-purpose Squeak developers list
> >> Subject: Re: [squeak-dev] Proposal: Morphs in Text
> >>
> >> 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 <ma.chris.m at gmail.com
> <mailto:ma.chris.m at gmail.com>> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190704/e405d065/attachment.html>


More information about the Squeak-dev mailing list