[PD] [SOLVED!] GOP auto-moving issue with Pd Vanilla 0.53.1 under GNU/Linux and Windows

[Linux ROUEN Normandie]

I'm neither a Pure Data specialist nor a developer.
The best I can do, as a user, is to try thinking cleverly.

If I delete the 1st line on three from my reorganized Restore/Coords 
list, the result is still a good behavior of my GOP / patch.
So it seems this Coords was also referring to this canvas.
Why it was added if it's unnecessary ?

Best,
= = = = = = = = = =

Le 26/02/2023 à 16:20, João Pais a écrit :
>
> without going to see the meaning of all coords parameters or how it's 
> applied in the file: if both coords statements refer to the same 
> canvas, wouldn't it be better to delete the first one?
>
> = = = = = = = = = =
>> Hello João,
>>
>> Thanks for your suggestions.
>> The first ones were not working, always the same jumping GOP issue.
>>
>> So I spent some more time on analyzing the 1845 lines of my patch.pd 
>> file helped by this unofficial PdFileFormat article 
>> <https://puredata.info/docs/developer/PdFileFormat>.
>> After a lot of testing I found the culprit, it is #X restore... and 
>> any associated #X coords... lines.
>>
>> In my case I was able to fix my issue by modifying the order of 3 lines.
>>
>> * Original Pd patch file for Restore & Coords: BAD behavior
>> /#X coords 0 -1 1 1 853 280 1 995 265;//
>> //#X restore 10 7 pd smpsk;//
>> //#X coords 0 293.5 1 292.5 850 280 0;//
>> ////
>> / * Modified Pd patch file for RESTORE & COORDS: Now GOOD behavior
>> /#X coords 0 293.5 1 292.5 850 280 0;//
>> //#X coords 0 -1 1 1 853 280 1 995 265;//
>> //#X restore 10 7 pd smpsk;/
>>
>> It seems to be a question of properly sorting this 3 lines, here 
>> manually.
>> But it should be the automatic task of the Pd engine to do it, isn't it!
>>
>> I will open an Issue on Miller Puckette Git site.
>>
>> Best, Joe
>> = = = = = = = = = =
>>
>> Le 25/02/2023 à 18:41, João Pais a écrit :
>>> it could be that your object isn't in the position it looks like, 
>>> but it's outside (above or below) the canvas, and it's only noticed 
>>> when you click in it - although it should show slider panes in the 
>>> window. You can try to move it downwards or upwards or check the 
>>> patche's text file to see where exactly in the canvas it is.
>>>
>>> or maybe not.
>>>
>>> = = = = = = = = = =
>>>> Hello List,
>>>>
>>>> In one of my project I have the same weird issue under both 
>>>> GNU/Linux (Linux Mint, Ubuntu Studio, Manjaro Linux, Raspberry Pi 
>>>> OS) and Windows with the use of Pd Vanilla GOP.
>>>> It's moving/jumping down/up (y axis only) when 
>>>> maximizing/minimizing its windows or changing its y size with the 
>>>> mouse.
>>>> See here attached animated GIF file (zoom-out) realized with a RPi 
>>>> 400.
>>>>
>>>> This is true for both zoom-out / zoom-in level.
>>>> But its parent patch doesn't have this weird behavior. The x,y 
>>>> position of the GOP is not impacted at all.
>>>>
>>>> Removing from its parent patch all the objects, inside + outside 
>>>> the GOP, doesn't change this weird behavior.
>>>> Note that trying to reproduce this problem from scratch with very 
>>>> simple patches+GOP is not always giving the same result. Sometimes 
>>>> it's okay but sometimes not. Random behavior seems to be around.
>>>>
>>>> Is there a known bug in Pd Vanilla or something wrong in the design 
>>>> of my patch regarding GOP?
>>>>
>>>> Thank you. Best,
>>>> Joe-Rouen
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230226/553d0167/attachment.htm>