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.
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