On Jul 3, 2013 7:09 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
On Jul 3, 2013 1:38 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]> - (ATTN: Ivica) [hsl] seems to have the bounding box (?)
miscalculated
> > in l2ork so it doesn't GOP when it's less than 2-3px from the
border
> > of the parent canvas. Checked in Vanilla, it works as expected
([hsl]
> > can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that
iemguis used
to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks
compatibility
between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I
don't
see how this doesn't qualify for breaking compatibility.
Roman
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
I agree with Roman. Patch authors were being very reasonable when they created their GOPs that just so happened to be based on faulty logic under the hood. Those discrepancies were extremely small, small enough that most patch author's probably didn't even notice the bug until you pointed it out and fixed it.
For me having a new user face inconsistency with autopatching is a lot more critical than an existing user encounter an inconsistency due to the fact that an old bug has been fixed.
One could approach this problem by having a hack that adjusts the spacing during autopatching and that's exactly what I used to have. At some point I simply realized that I was adding more and more hacks to keep the hack propagating through the undo and other functions, and came to the conclusion it's time to start cleaning up hacks like these and make the code cleaner and easier to maintain.
Otherwise, by your suggested approach one could conclude that PD is perfect as-is and that no other development/changes are necessary. Case in point if a comment or labels for iemgui objects do in part fall out of GOP area, pd/extended still render them visible. Since this bug has been there for some time there are possibly patches out there that exploit this bug as a feature and by using your logic we should never change that either as doing so would break old patches. Again, if we take the suggested approach then there's nothing to change about pd. OTOH, one could ostensibly look into creating a simple shell script that when run could easily adapt all of the old patches to the new spacing. Perhaps someone else may want to contribute this?
In summary let us hope that other versions of the pd adopt the same/similar fixes and do so soon.
Best wishes,
Ico
So through no fault of their own, their patches are broken on the distribution of Pd that has a superior UX. That's a bad situation.
If you have a solution not too far off that will allow such GOP objects to be functional again, then the temporary breakage is probably ok. If not, then we need to keep the bug for all eternity and work around it.
To do otherwise is to scare off potential users who have no idea how many other changes will break their patches because of idiosyncracies that lurk deep in code that Pd was designed to abstract away from them.
-Jonathan
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.
Actually, one can decide to use or not to use new features. Obviously, added features do not work in flavors that do not implement that feature. From a user point of view, this can be dealt with in an clean way. If you want your patch to work on other flavors, don't use stuff like preset_node. I don't see a problem at all with that.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->