kicad-developers team mailing list archive
Mailing list archive
Re: Kicad Tool Framework
> That's independently of the GAL, I think some/most of this stuff would
> be useful even for 'stock' kicad,
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
So if tools are the destination of code, then what are the sources of code for those
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
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?
> 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.