You've done a lot of good work in pd-l2ork, but you also broke binary compatibility of libraries for no good reason. You could have implemented that feature in a way that preserved binary compatibility of libraries. You still can, and you should.
.hc Ivica Bukvic wrote: > Well, I guess you can call me a "developer," whatever that means--I don't > care that much about titles. Yet, I would argue that as far as low level > stuff is concerned in recent years pd-l2ork has certainly pushed the > envelope in terms of core development. Even the feature that has earned me > the title in quotations delves so deep into the core that currently it > cannot be implemented in either vanilla or extended without significant > changes even though it retains full backwards compatibility. I would also > argue it is essential and offers a slew of features that are unavailable in > any other implementation of presets. > > Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially > a conscious decision to allow for faster development while addressing the > lack of manpower. But that is about to change once we complete port to Qt > library. We already transitioned to Tkpath quite a while ago which allowed > us to use a full SVG-based canvas, so I have no doubt we will be able to do > this again. Once this is done, we won't have to circumnavigate exceptions > Tk library requires in order to be compliant with different platforms and I > would argue in turn that will result in faster development. So, if you are > really interested in pushing the development of non-vanilla pd I think you > should heed some of Jonathan's advice and look for ways how community can > work together in combining the "best of" and engaging developers and > "developers" alike who have shown dedication to the cause. But before that > can be accomplished, the community should consider agreeing on design > choices. For instance, pd-l2ork came into existence because it focuses on > more nimble development at the expense of potential loss of backwards > compatibility (even though after 4 years of development the only > incompatibility we infatuated is correcting buggy positioning of iemgui > objects, which is cosmetic in nature) because a good chunk of that > compatibility stems from buggy implementations that stuck around long > enough that they became a part of the standard (e.g. iemgui's buggy > positioning of objects that are arbitrarily offset from their x and y > positions, as reported by the pd script), which is unfortunate. > > Best, > > Ico > On Sep 23, 2014 9:21 AM, "Dan Wilcox" <[email protected]> wrote: > >> I disagree. Your example lists what? 2 more developers? I'm talking about >> "developers" as in people working the C code, build scripts, tcl/tk etc aka >> people who could, theoretically, help push out a new Pd-extended release. >> True, we have plenty of people working on externals, but this is a problem >> for someone who can go deeper. >> >> I still maintain that the number of low level developers to overall users >> (non-developers) is relatively low. >> >> On Sep 23, 2014, at 6:00 AM, [email protected] wrote: >> >> However, your description of the user/developer ratio doesn't ring true to >> me. There's actually a surplus of developers and development energy-- I >> count two implementations of presets in the last year or two (in Pd-l2ork >> and the Chocolate et Coffee lib) which are in addition to however many >> already exist on svn and the Pd forum. >> >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> N�n�r����)em�h�yhiם�w^�� _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
