On 3 January 2014 12:38, J.F. Rick <[email protected]> wrote:
> OK. Here's some code to demonstrate the bug:
>
> wrap := AthensWrapMorph new
> extent: 100 @ 100;
> yourself.
> black := Morph new
> extent: 100 @ 100;
> color: Color black;
> yourself.
> red := Morph new
> extent: 100 @ 50;
> color: Color red;
> yourself.
> transparent := Morph new
> extent: 50 @ 50;
> position: 25 @ -25;
> color: Color transparent;
> yourself.
> wrap
> addMorph: black;
> addMorph: red;
> addMorph: transparent;
> openInWorld
>
> Please note that for this to work, you have to remove the "initialize"
> method in AthensWrapMorph that makes it use a TableLayout, which is a silly
> choice. Though adding transparent should not make a difference in the
> rendering, it does.
>
> Ah, ok, that's the whole reason why :)
Because i AthensWrapMorph mainly , as you said very silly and works for
simplest layouts
for example:
wrap := AthensWrapMorph new
extent: 100 @ 100;
yourself.
black := Morph new
extent: 100 @ 100;
color: Color black;
yourself.
red := Morph new
extent: 100 @ 50;
color: Color red;
yourself.
transparent := Morph new
extent: 50 @ 50;
position: 25 @ -25;
color: Color transparent;
yourself.
wrap
addMorph: black;
addMorph: red;
addMorph: transparent;
fullBounds
(0@ -25) corner: (100@100)
it is obvious, that it has to clip submorphs, and
fullBounds should be
(0@ 0) corner: (100@100)
but not
(0@ -25) corner: (100@100)
because then it is causing 'clipping' because surface's 0@0 corresponds to
fullbounds zero , which is 0@-25
and if you draw it this way, then of course the bottom 25 pixels will be
clipped.
But it really depends on usage.. because in fact maybe it should not clip.
(ehh.. morphic has too many features to support them properly :)
(btw, i think i found why there's extra 1 pixel , because in #initialize
there is:
layoutInset: 0@1;
:)
don't ask me how it appeared there.. i don't remember.
The logic should be rewritten in a way that:
- the surface extent should be same as wrap morph's fullBounds, not bounds
then it won't clip the morphs which outside..
and also it should take into account the negative offset (either x or y)
when copying output from athens surface to morphic.
i added the issue..
Please feel free to provide a better "fixed" version of wrapper, which is
less intrusive than existing one (if i won't do it before)
https://pharo.fogbugz.com/f/cases/12555/Improve-AthensWrapMorph
Cheers,
>
> Jeff
>
>
> On Thu, Jan 2, 2014 at 5:29 PM, J.F. Rick <[email protected]> wrote:
>
>> I'm aware of the default Morphic behavior. I've hacked it so that a
>> transparent 1x1 pixel bit is in the hand and its movement causes the brown
>> morph to move and remain a submorph of the AthensWrapMorph application.
>>
>> Yes, this is some kind of weird clipping thing. Specifically, it looks
>> like clipping is not happening. The brown morph (and the area behind it)
>> renders correctly but it is not rendered at the correct location. Instead,
>> the starting location of the rendering seems to be forced into the bounds
>> of the surface. That's why it looks like the background things have shifted
>> downwards.
>>
>> Cheers,
>>
>> Jeff
>>
>>
>> On Thu, Jan 2, 2014 at 5:10 PM, Igor Stasenko <[email protected]> wrote:
>>
>>>
>>>
>>>
>>> On 2 January 2014 16:54, J.F. Rick <[email protected]> wrote:
>>>
>>>> I've been converting DigiTile over to Athens with general success but I
>>>> have found an odd rendering bug. In this scenario, I am moving the brown
>>>> square around with a hand. As I am using AthensWrapMorph, I have made it so
>>>> that the brown square is a submorph of the application (an AthensWrapMorph)
>>>> and not in the hand. The brown square is actually twice the extent that it
>>>> appears (i.e., it has a 50 pixel transparent border). This has to be done
>>>> to allow rotation handles to be added. Anyway, when it moves so that its
>>>> top would go beyond the top of the application, some crazy rendering effect
>>>> happens, as illustrated in the included screenshots. This same behavior
>>>> happens when moving the square to the left side of the screen. It does not
>>>> happen on either the right or the bottom of the screen. It seems like
>>>> Athens does not like for submorphs of AthensWrapMorph to extend to the left
>>>> or above their parent. This seems like a problem and something that can
>>>> easily happen as somebody moves some morph to be partially offscreen.
>>>>
>>>>
>>> Sounds like clipping issue. But it is hard to tell anything by looking
>>> at screenshots..
>>> Usually all things outside of visible area should be clipped.
>>> Also, note that dragging, like it is done in Morphic, the dragged morph
>>> changes its owner to hand (handmorph)..
>>> and since it is only within AthensWrapMorph it is where it uses
>>> rendering by Athens, it could be simply the case that it don't renders at
>>> all (or just uses morhic rendering while held by hand).
>>>
>>>
>>>> Cheers,
>>>>
>>>> Jeff
>>>>
>>>> --
>>>> Jochen "Jeff" Rick, Ph.D.
>>>> http://www.je77.com/
>>>> Skype ID: jochenrick
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>>
>> --
>> Jochen "Jeff" Rick, Ph.D.
>> http://www.je77.com/
>> Skype ID: jochenrick
>>
>
>
>
> --
> Jochen "Jeff" Rick, Ph.D.
> http://www.je77.com/
> Skype ID: jochenrick
>
--
Best regards,
Igor Stasenko.
