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 patrick.rein@hpi.uni-potsdam.de 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"]
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
Hi Chris,
what does "DTP" stand for?
Best, Marcel Am 01.07.2019 02:19:19 schrieb Chris Muller ma.chris.m@gmail.com:
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
Desk Top Publishing ?
Best, Karl
On Mon, Jul 1, 2019 at 9:02 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Chris,
what does "DTP" stand for?
Best, Marcel
Am 01.07.2019 02:19:19 schrieb Chris Muller ma.chris.m@gmail.com:
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
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@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
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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto:ma.chris.m@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
Hi Patrick,
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@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.
Squeak *3.7* was the last release we included "The Worlds of Squeak" demo project that showed off its capabilities, including its powerful text-handling. One of my favorite demos to show people was typing into that upper-left bubble (under "Squeak Rulez") and watch:
- text being inserted flowing into the next morphs! - even along that spline! - and into that lower box with an embedded Morph that demonstrating occlusion avoidance!
[image: dtp-level-text-handling.png]
Selecting that yellow ellipse in the lower-right box and dragging it around forces the text to reformat around the shape of the ellipse (e.g., not even just a simple rectangle!).
Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least *could* be done in 5.3 if we wanted.
Best, Chris
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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto: ma.chris.m@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
Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least could be done in 5.3 if we wanted.
We should write more tests. :-) Such examples are nice to learn from. Yet, they cannot replace automated testing. There have been several bugs in the recent past despite objects (or games or apps) being in the release image to reveal them.
Best, Marcel Am 03.07.2019 21:32:15 schrieb Chris Muller asqueaker@gmail.com: Hi Patrick,
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@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.
Squeak 3.7 was the last release we included "The Worlds of Squeak" demo project that showed off its capabilities, including its powerful text-handling. One of my favorite demos to show people was typing into that upper-left bubble (under "Squeak Rulez") and watch:
- text being inserted flowing into the next morphs! - even along that spline! - and into that lower box with an embedded Morph that demonstrating occlusion avoidance!
[dtp-level-text-handling.png]
Selecting that yellow ellipse in the lower-right box and dragging it around forces the text to reformat around the shape of the ellipse (e.g., not even just a simple rectangle!).
Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least could be done in 5.3 if we wanted.
Best, Chris
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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]> on behalf of karl ramberg <karlramberg@gmail.com [mailto:karlramberg@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@gmail.com [mailto:ma.chris.m@gmail.com]<mailto:ma.chris.m@gmail.com [mailto:ma.chris.m@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
The bug can also be triggered in 3.7... The main problem is that there is no logic to ensure that the wrapFlag is set when avoid occlusion is on.
I'll see to a proposed fix in the next days.
Bests Patrick ________________________________________ From: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of Taeumel, Marcel Sent: Thursday, July 4, 2019 8:23:55 AM To: Chris Muller; Robert via Squeak-dev Subject: Re: [squeak-dev] Proposal: Morphs in Text
Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least could be done in 5.3 if we wanted.
We should write more tests. :-) Such examples are nice to learn from. Yet, they cannot replace automated testing. There have been several bugs in the recent past despite objects (or games or apps) being in the release image to reveal them.
Best, Marcel
Am 03.07.2019 21:32:15 schrieb Chris Muller asqueaker@gmail.com:
Hi Patrick,
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@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.
Squeak 3.7 was the last release we included "The Worlds of Squeak" demo project that showed off its capabilities, including its powerful text-handling. One of my favorite demos to show people was typing into that upper-left bubble (under "Squeak Rulez") and watch:
- text being inserted flowing into the next morphs! - even along that spline! - and into that lower box with an embedded Morph that demonstrating occlusion avoidance!
[dtp-level-text-handling.png]
Selecting that yellow ellipse in the lower-right box and dragging it around forces the text to reformat around the shape of the ellipse (e.g., not even just a simple rectangle!).
Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least could be done in 5.3 if we wanted.
Best, Chris
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@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> on behalf of karl ramberg <karlramberg@gmail.commailto:karlramberg@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@gmail.commailto:ma.chris.m@gmail.com<mailto:ma.chris.m@gmail.commailto:ma.chris.m@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
On 04/07/19 12:28 PM, Rein, Patrick wrote:
The bug can also be triggered in 3.7... The main problem is that there is no logic to ensure that the wrapFlag is set when avoid occlusion is on.
I'll see to a proposed fix in the next days.
Patrick,
Isn't this too strong a condition? Will pre-formatted text like code or poems not be eligible for occlusion?
Regards .. Subbu
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@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto: ma.chris.m@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
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@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@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto:ma.chris.m@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
Maybe Karl refers to the default behavior of TextMorph or PluggableTextMorph?
If you subclass PluggableTextMorph, TextMorph, TextEditor etc. you can add any additional stuff such as through Morphic's generic event handling.
Best, Marcel Am 03.07.2019 22:58:21 schrieb Chris Muller ma.chris.m@gmail.com: 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 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 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@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 on behalf of karl ramberg 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 > 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
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@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 openInWorldtype 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@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@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@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@lists.squeakfoundation.org on
behalf of karl ramberg karlramberg@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@gmail.com
mailto:ma.chris.m@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
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a TextContainer. This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto: ma.chris.m@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
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg karlramberg@gmail.com wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a TextContainer. This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
NewParagraph seems to sometimes have Rectangle as container and sometimes a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.commailto: ma.chris.m@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
I think it's not really broken - adjustRightX is only used when wrapFlag is false, which is probably not the originally intended use for TextContainers. You could add a method or two to TextContainer to see if it would work when not wrappping.
On 7/4/19 4:00 PM, karl ramberg wrote:
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg <karlramberg@gmail.com mailto:karlramberg@gmail.com> wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a TextContainer. This method must be made to work with TextContainer. NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth. Best, KarlNewParagraph seems to sometimes have Rectangle as container and sometimes a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick <Patrick.Rein@hpi.de <mailto:Patrick.Rein@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@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@lists.squeakfoundation.org <mailto:squeak-dev-bounces@lists.squeakfoundation.org>> on behalf of karl ramberg <karlramberg@gmail.com <mailto:karlramberg@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@gmail.com <mailto:ma.chris.m@gmail.com><mailto:ma.chris.m@gmail.com <mailto:ma.chris.m@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
I looked at the code and I'm really not sure what to do. I don't think understand what is going on in the code, and what is supposed to go on.
Best, Karl
On Thu, Jul 4, 2019 at 10:33 PM Bob Arning arning315@comcast.net wrote:
I think it's not really broken - adjustRightX is only used when wrapFlag is false, which is probably not the originally intended use for TextContainers. You could add a method or two to TextContainer to see if it would work when not wrappping.
On 7/4/19 4:00 PM, karl ramberg wrote:
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg karlramberg@gmail.com wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a TextContainer. This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
NewParagraph seems to sometimes have Rectangle as container and sometimes a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.com mailto:ma.chris.m@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
To quote my earlier proposal:
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.
adjustX adjusts the Paragraph bounds to the rightmost character. This does not make sense for TextContainers as they dictate the rightmost point for layouting. (Even if you make that work, there are other such constraints (I tried it :))). Thus when having a TextContainer the wrapFlag should always be set to true.
At the same time it is right that pre-formatted text should also work with occlusion ideally. but this goes beyond the initial bug we are trying to fix here (at least that was my impression).
Bests Patrick
BlueMail for Android herunterladen
Am 6. Juli 2019, 19:55, um 19:55, karl ramberg karlramberg@gmail.com schrieb:
I looked at the code and I'm really not sure what to do. I don't think understand what is going on in the code, and what is supposed to go on.
Best, Karl
On Thu, Jul 4, 2019 at 10:33 PM Bob Arning arning315@comcast.net wrote:
I think it's not really broken - adjustRightX is only used when
wrapFlag
is false, which is probably not the originally intended use for TextContainers. You could add a method or two to TextContainer to see
if it
would work when not wrappping.
On 7/4/19 4:00 PM, karl ramberg wrote:
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg karlramberg@gmail.com
wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a
TextContainer.
This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
NewParagraph seems to sometimes have Rectangle as container and
sometimes
a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.com mailto:ma.chris.m@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
Hello
what happened to Patrick's proposals?
" 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. "
Kind regards Hannes
On 7/7/19, Patrick Rein patrick.rein@hpi.uni-potsdam.de wrote:
To quote my earlier proposal:
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.
adjustX adjusts the Paragraph bounds to the rightmost character. This does not make sense for TextContainers as they dictate the rightmost point for layouting. (Even if you make that work, there are other such constraints (I tried it :))). Thus when having a TextContainer the wrapFlag should always be set to true.
At the same time it is right that pre-formatted text should also work with occlusion ideally. but this goes beyond the initial bug we are trying to fix here (at least that was my impression).
Bests Patrick
BlueMail for Android herunterladen
Am 6. Juli 2019, 19:55, um 19:55, karl ramberg karlramberg@gmail.com schrieb:
I looked at the code and I'm really not sure what to do. I don't think understand what is going on in the code, and what is supposed to go on.
Best, Karl
On Thu, Jul 4, 2019 at 10:33 PM Bob Arning arning315@comcast.net wrote:
I think it's not really broken - adjustRightX is only used when
wrapFlag
is false, which is probably not the originally intended use for TextContainers. You could add a method or two to TextContainer to see
if it
would work when not wrappping.
On 7/4/19 4:00 PM, karl ramberg wrote:
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg karlramberg@gmail.com
wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a
TextContainer.
This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
NewParagraph seems to sometimes have Rectangle as container and
sometimes
a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.com mailto:ma.chris.m@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
P.S. Is the change set I need to file in still the one from the mail of Patrick Rein, Jun 28, 2019 at 2:40 PM?
On 8/22/19, H. Hirzel hannes.hirzel@gmail.com wrote:
Hello
what happened to Patrick's proposals?
" 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. "
Kind regards Hannes
On 7/7/19, Patrick Rein patrick.rein@hpi.uni-potsdam.de wrote:
To quote my earlier proposal:
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.
adjustX adjusts the Paragraph bounds to the rightmost character. This does not make sense for TextContainers as they dictate the rightmost point for layouting. (Even if you make that work, there are other such constraints (I tried it :))). Thus when having a TextContainer the wrapFlag should always be set to true.
At the same time it is right that pre-formatted text should also work with occlusion ideally. but this goes beyond the initial bug we are trying to fix here (at least that was my impression).
Bests Patrick
BlueMail for Android herunterladen
Am 6. Juli 2019, 19:55, um 19:55, karl ramberg karlramberg@gmail.com schrieb:
I looked at the code and I'm really not sure what to do. I don't think understand what is going on in the code, and what is supposed to go on.
Best, Karl
On Thu, Jul 4, 2019 at 10:33 PM Bob Arning arning315@comcast.net wrote:
I think it's not really broken - adjustRightX is only used when
wrapFlag
is false, which is probably not the originally intended use for TextContainers. You could add a method or two to TextContainer to see
if it
would work when not wrappping.
On 7/4/19 4:00 PM, karl ramberg wrote:
On Thu, Jul 4, 2019 at 8:50 PM karl ramberg karlramberg@gmail.com
wrote:
The code in NewParagraph>>adjustRightX is broken. It seem to expect a container that is a Rectangle and not a
TextContainer.
This method must be made to work with TextContainer.
NewParagraph>>adjustRightX | shrink | shrink := container right - maxRightX. lines do: [:line | line paddingWidth: (line paddingWidth - shrink)]. container := container withRight: maxRightX + self caretWidth.
Best, Karl
NewParagraph seems to sometimes have Rectangle as container and
sometimes
a TextContainer. I'm not sure what to do about that...
Best, Karl
On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick Patrick.Rein@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@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@lists.squeakfoundation.org on behalf of karl ramberg karlramberg@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@gmail.com mailto:ma.chris.m@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
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Chris Muller -
Chris Muller -
H. Hirzel -
K K Subbu -
karl ramberg -
Marcel Taeumel -
Patrick Rein -
Rein, Patrick