Hi, Luis! > On 10/20/2014 02:19 PM, Andrew Deryabin wrote: > > Hi Andrew, > > Thanks for the informative response! I forgot to tell you I know > reasonably well LV2's architecture and specs, so you don't need to go > into too much detail for my sake. Ok! I hope that I didn't make any mistake explaining things. Now I'll be more specific :).
>> 3. Any patch, that will be submitted to David will see the world only in >> future versions of suil library. In ubuntu/kubuntu this can be as long >> as half a year of waiting for those changes. And then, it's not 100% >> guarantee, that there will be no plugins, incompatible with suil till >> the distro update is out. >> > OK, that is indeed a reasonable concern. > > However, for the sake of effort consolidation, I'd like to offer a > suggestion for discussion, if you will allow me. > > Since all LV2 libraries are by design modular and lightweight so they > can be used in embedded hardware, a middle ground could be adding a > customized suil source tree to MusE's. > > This way you could patch up MusE's copy of suil and have MusE statically > linked to this latest and greatest version. Additionally you could send > your patches to Dave, so they can benefit any other software using > future suil releases (and MusE can benefit from Dave's work too). In the > long term, once your fixes are merged upstream and are widely > distributed, MusE's customized suil could be dropped in favor of the > standard version. That's was the initial plan :). But... The first thing is that suil is aimed to be a general-purpose gui wrapper library, so it includes support for gtk2 hosts too (x11 in gtk2 and qt4 in gtk2 for now), that is unneeded for MusE. Of course I can exclude them from compilation but I have to keep them in source tree in order to be in sync with Dave's development. The second thing is that suil supports embedding by means of ''SUIL_MODULE_DIR" env var, where it searches for modules. So, I can compile only needed patched modules and use system suil library. But If distro lacks libgtk2-dev code, gtk2_in_qt4.so module will not be compiled, and existing suil library will not find it, because there is no fallback code to use system modules dir. That can be patched too, but gui wrapper code is not so hard to implement (comparable to lilv lv2 library). May be it sounds selfish, but I want to keep all that code as simple as possible to further improving and maintaining. So... I choose a 'rewrite from scratch' method there. Regards, Andrew > Nevertheless, I understand there are other advantages in maintaining > your own code (tighter integration with MusE's codebase, no need to > coordinate with other developers, etc.) > > Thanks again for your efforts. Cheers! > > Luis > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
