> > That's independently of the GAL, I think some/most of this stuff would > be useful even for 'stock' kicad,
Lorenzo, I think it is positive for the project that you and I agree with Tom on this design concept. We are approaching a unified vision for the project moving forward. This architecture also allows folks to contribute new tools and do so in a less disruptive and modular fashion. So if tools are the destination of code, then what are the sources of code for those destination buckets? Basically: old code and new code. You like it so much that you want to move old code into tools for 'stock" KiCad. That is a solid endorsement of the idea. But I think Tom sees it as an opportunity to transport code into the new architecture. The act of transporting code is a healthy endeavour because it lets you scrutinize and revitalize and quality enhance. It is like pouring a dirty liquid through a filter into a new container. So I hear Tom saying that the new containers could define the new GAL pcbnew. One has to ask then: "if the the GAL display code is working well enough, why don't we merge it in and start writing tools?" Clearly the P&S router is not the only thing that needs to be done. With a #ifdef we can keep the new code out of the stock build binaries for awhile. Co-mingling the source is possible, some minor drawbacks no doubt, but how bad are they? Dick > however the GAL *requires* them... too > bad you can't have the xor blend in opengl:((( I really prefer the xor > contrast compared to Porter/Duff composition (maybe there is some shader > trick but good luck having it work fast on the Intel GPUs...). Well, > there *was* but it was deprecated together with color index mode and > other 'non-photorealistic' stuff. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
