[L2Ork-dev] pd_compatibility breakage from Vanilla
ico at vt.edu
Sun Jul 5 16:40:39 EDT 2020
I favor your way of thinking on this one. Namely, implicitly backwards
compatible while offering a superior interface.
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
ico at vt.edu
On Sun, Jul 5, 2020, 16:08 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> Hi all,
> Looking at porting the symbolic hex color values for iemguis. But this
> pd_compatibility business doesn't make sense to me.
> if (ac >= 1)
> iemgui->x_bcol = iemgui_compatible_colorarg(0, ac, av);
> if (ac == 2 && pd_compatibilitylevel < 47)
> /* old versions of Pd updated foreground and label color
> if only two args; now we do it more coherently. */
> iemgui->x_lcol = iemgui_compatible_colorarg(1, ac, av);
> else if (ac >= 2)
> iemgui->x_fcol = iemgui_compatible_colorarg(1, ac, av);
> This means any mortal user who happens to open a pre 0.47 patch that
> uses this interface will see breakage. And the pd_compatibility
> interface essentially tells them, "Here, *you* fix this by playing a
> version number guessing game and crossing your fingers that no other
> bits flip that you care about..."
> But can't we fix this automatically? E.g., if the user is sending the
> "color" message with args from the old, lossy human unreadable
> integers then parse them according to the old way. If they are the hex
> syntax from the bleeding edge of 1995, then use the new branch.
> Or am I missing something here?
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the L2Ork-dev