[squeakland] Found Bug But Not Sure How to Proceed To Fix
Jeremy Landry
hakyoku at gmail.com
Sat Mar 3 22:52:37 UTC 2018
I had thought about doing this as a hack to leave the rest of the system
alone, as well. I'm still trying to find why playfield cursors are
boogered up as much as they are. It's *really* bad...my personal 'hack' is
just to make a new default playfield as an etoys button as a 'new project
template' that replaces the cursor with a another etoys rectangle that can
be toggled, but hack up on hack upon hack isn't really...well, it's
certainly not ideal. I am also looking at cuis smalltalk a little to find
out if there's anything in there that was fixed that might be portable back
into etoys to fix this. It still 'feels' like these little anomolies have
a common origin. From what I understand, Cuis deleted a lot of things and
then re-inserted them one by one from the lowest level first and went from
there. Someone on that project might have found a fix that would work here
too...
On Sat, Mar 3, 2018 at 1:28 PM, Bob Arning <arning315 at comcast.net> wrote:
> Attached is a hack to keep rotated rectangles (well, most anything
> rotated, but rectangles are were it really shows) all aligning as one might
> expect them. It basically assumes that the bounds have been expanded by 1
> and scoots the drawing back to the top left when rotated by 90, 18 or 270.
> See if you like it.
>
> On 3/2/18 8:59 PM, Jeremy Landry wrote:
>
> So far, with a little testing, everything lines up much better with .1
> instead of removing it. removing that offset still sees to make it offset,
> but .1 lines everything up visually more...still not perfect, but much less
> flagrant. It still has a clipping glitch (you can see it with a rectangle
> when rotating: the border gets clipped off) but it does visually appear
> more 'solid' and expected when aligning rectangular shapes together.
>
> I'm going to keep experimenting to find something that keeps the rotated
> bitmap in tact while still aligning properly. I feel like I probably
> glanced at a method that needs an edit over and over but haven't realized
> which one it is yet. I still need to look into the cursor not being
> properly redrawn as well. I might be stretching or trying to make a
> connection that isn't there, but something 'feels' related to this and the
> cursor, like some common reference point is being shifted so that the
> cursor's area for drawing doesn't reach the left and bottom edges just like
> the origin doesn't reach the left and bottom edges correctly for the this
> rotation issue.
>
>
>
>
>
> On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>
>> Does anything bad happen if the "expandBy: 1" is removed? I tried
>> removing it
>> in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which
>> is one
>> user of TransformationMorph) seems to work nicely.
>>
>> And if the "expandBy: 1" is removed in an Etoys image, does anything bad
>> happen?
>> Does it fix the issue that Jeremy is seeing?
>>
>> This would be an easy thing to fix in Squeak trunk, which hopefully will
>> become
>> part of future Etoys releases, knock wood.
>>
>> Dave
>>
>>
>> On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
>> > TransformationMorph>>computeBounds
>> > ?????? self hasSubmorphs ifTrue:
>> > ?????? ?????? [bounds _ (transform localBoundsToGlobal:
>> > ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
>> > ?????? ?????? ?????? ?????? ?????? ?????? (self submorphs collect: [:m
>> | m
>> > fullBounds]))) truncated
>> > ?????? ?????? ?????? ?????? expandBy: 1].
>> > ?????? fullBounds _ bounds.
>> >
>> > Note the expandBy: 1
>> >
>> >
>> > On 3/2/18 1:59 PM, Jeremy Landry wrote:
>> > >Actually to add a little more insight if possible, you can create bug
>> > >with the following actions:
>> > >
>> > >make a new playfield
>> > >make 2 new rectangles and place them into the playfield.
>> > >Rotate one of them 90 degrees.
>> > >Turn gridding on in the playfield.
>> > >
>> > >The rotated and unscaled rectangle will not align with the non-rotated
>> > >one with gridding.?? Something about making a bitmap copy is offsetting
>> > >the values, my guess is there's a rounding problem that is popping up
>> > >on these objects, thus scale and rotation get offset for some reason,
>> > >and specifically changes the origin by 1 at -1 somewhere...it causes
>> > >graphical glitches leaving 'garbage' with playfield indicators when
>> > >the object that has the indicator is moved and also shows up with
>> > >rotated ellipses.?? What is the common thread through them all??? What
>> > >method are they all accessing?
>> > >
>> > >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry <hakyoku at gmail.com
>> > ><mailto:hakyoku at gmail.com>> wrote:
>> > >
>> > > You will also notice if you rotate any shape, it becomes a bit
>> > > map.?? Scale it and you will see that problem re-occur even with
>> > > built-in objects.?? Could it be the masking offset, too??? that
>> > > causes this??? I'm still investigating, but I'm not sure how to
>> > > step through 'already working' things specifically related to what
>> > > I'm trying to look at.
>> > >
>> > > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy Landry <hakyoku at gmail.com
>> > > <mailto:hakyoku at gmail.com>> wrote:
>> > >
>> > > Hi, it only appears when scaling a morph.?? Here is
>> > > example...it is my belief (how does one step through code with
>> > > debugger if there's no bug happening?);
>> > >
>> > > Whatever code is common that scales morphs is being offset
>> > > incorrectly. The first image shows the 'garbage' left behind
>> > > by playfield indicator if that option is set.?? It seems it was
>> > > only tested in 'holders' and thus likely not picked up during
>> > > 'intended' use.
>> > >
>> > > Next, two pictures show scaling as where the misalignment
>> > > starts.?? This might be why you could not recreate bug;
>> > > resizing rectangle changes rectangle morph extent, whereas
>> > > scaling is a differnet piece of code and therefore different
>> > > outcome.
>> > >
>> > > Image included.?? This works with *anything* scaled.
>> > > https://imgur.com/a/6zEWq
>> > >
>> > > On Fri, Mar 2, 2018 at 10:20 AM, Bob Arning
>> > > <arning315 at comcast.net <mailto:arning315 at comcast.net>> wrote:
>> > >
>> > > I tried to recreate your example and could not. How did
>> > > you create the two morphs in your example? Are you certain
>> > > the read/gray morph does not have some transparent pixels
>> > > along the top and left?
>> > >
>> > >
>> > > On 3/2/18 12:50 PM, Jeremy Landry wrote:
>> > >> I did a little more digging, just for the record...and it
>> > >> turns out it's scaling error.?? No matter what, scaling
>> > >> offsets morphs by 1 at -1.?? I'm still looking for where
>> this
>> > >> occurs and why.?? So far, injecting intentionally bad
>> > >> values into bordered morph and sketch classes hasn't
>> > >> produced any change.?? It 'feels' like most of that code
>> > >> isn't even used, but then again, I might not have
>> > >> genuinely created a new object with that code and system
>> > >> might have been giving me what was already in system...
>> > >>
>> > >>
>> > >> On Fri, Mar 2, 2018 at 7:15 AM, Bert Freudenberg
>> > >> <bert at freudenbergs.de <mailto:bert at freudenbergs.de>>
>> wrote:
>> > >>
>> > >> That bug tracker is pretty much dead, since all
>> > >> ongoing development moved to squeak.org
>> > >> <http://squeak.org>.
>> > >>
>> > >> The plan was to make a new Etoys release based on the
>> > >> latest Squeak source base, but we have not have
>> > >> enough developer time to make that actually happen.
>> > >>
>> > >> - Bert -
>> > >>
>> > >> On 1 March 2018 at 06:03, Nicco Kunzmann (rambler)
>> > >> <niccokunzmann at rambler.ru
>> > >> <mailto:niccokunzmann at rambler.ru>> wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> I found a bug tracker on the squeakland site:
>> > >> http://tracker.squeakland.org/
>> secure/Dashboard.jspa
>> > >> <http://tracker.squeakland.org
>> /secure/Dashboard.jspa>
>> > >>
>> > >> I think, you can describe the problem there as an
>> > >> issue and hand in the fix.
>> > >> They may also know how to guide you further if
>> > >> the code base is somewhere else.
>> > >> If you have problems there (login, no response),
>> > >> I guess, this mailing list is one place to ask
>> > >> for help.
>> > >>
>> > >> Best,
>> > >> Nicco
>> > >>
>> > >>
>> > >> On 03/01/2018 03:34 AM, Jeremy Landry wrote:
>> > >>> Hi, while working on a project needing precise
>> > >>> alignment of sketches/bitmaps and rectangles
>> > >>> using playfield 'use gridding', it seems that
>> > >>> there's a difference of detected origin.
>> > >>>
>> > >>> Here's a screenshot with magnifier showing the
>> > >>> discrepency.
>> > >>> https://imgur.com/a/tcaRu
>> > >>>
>> > >>> I'm quite certain this bug is the one that
>> > >>> causes bad redrawing, especially when showing a
>> > >>> cursor move when 'indicate cursor' is activated
>> > >>> in a playfield.
>> > >>>
>> > >>> If I correct this bug inside of a project, will
>> > >>> it load into an image where it has not been
>> > >>> fixed and be fixed?
>> > >>>
>> > >>> I haven't actually fixed the bug yet, but didn't
>> > >>> want to waste time on it if the fix will not
>> > >>> travel with the project.
>> > >>>
>> > >>> Thanks in advance for any input.
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> squeakland mailing list
>> > >>> squeakland at lists.squeakland.org
>> > >>> <mailto:squeakland at lists.squeakland.org>
>> > >>> http://lists.squeakland.org/ma
>> ilman/listinfo/squeakland
>> > >>> <http://lists.squeakland.org/m
>> ailman/listinfo/squeakland>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> squeakland mailing list
>> > >> squeakland at lists.squeakland.org
>> > >> <mailto:squeakland at lists.squeakland.org>
>> > >> http://lists.squeakland.org/ma
>> ilman/listinfo/squeakland
>> > >> <http://lists.squeakland.org/m
>> ailman/listinfo/squeakland>
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> squeakland mailing list
>> > >> squeakland at lists.squeakland.org
>> > >> <mailto:squeakland at lists.squeakland.org>
>> > >> http://lists.squeakland.org/ma
>> ilman/listinfo/squeakland
>> > >> <http://lists.squeakland.org/m
>> ailman/listinfo/squeakland>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> squeakland mailing list
>> > >> squeakland at lists.squeakland.org
>> > >> <mailto:squeakland at lists.squeakland.org>
>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland
>> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland>
>> > >
>> > >
>> > > _______________________________________________
>> > > squeakland mailing list
>> > > squeakland at lists.squeakland.org
>> > > <mailto:squeakland at lists.squeakland.org>
>> > > http://lists.squeakland.org/mailman/listinfo/squeakland
>> > > <http://lists.squeakland.org/mailman/listinfo/squeakland>
>> > >
>> > >
>> > >
>> > >
>> >
>>
>> > _______________________________________________
>> > squeakland mailing list
>> > squeakland at lists.squeakland.org
>> > http://lists.squeakland.org/mailman/listinfo/squeakland
>>
>> _______________________________________________
>> squeakland mailing list
>> squeakland at lists.squeakland.org
>> http://lists.squeakland.org/mailman/listinfo/squeakland
>>
>
>
>
> _______________________________________________
> squeakland mailing listsqueakland at lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
>
>
>
> _______________________________________________
> squeakland mailing list
> squeakland at lists.squeakland.org
> http://lists.squeakland.org/mailman/listinfo/squeakland
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/squeakland/attachments/20180303/f39922ab/attachment-0001.html>
More information about the squeakland
mailing list