kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> 
> 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.
>