Instead of modifying setSampler() I have added the new setGeometryProg() API. I think this is better if we want to add later tessellation evaluation and control shader.
But this has a little downside, because you need to call first setGeometryProg() and then setSampler() to compile the shader with the geometry shader.
Otherwise if we extend setSampler(), the we need to add keyword arguments to it, if we add later other shader types to it.
Actually I don't know which one we should use. Please make comment on this.

Test file:

I am assuming in your earlier post you meant to say setSource instead of setSampler. I would like to see the setting of sources to be consistent. So either being able to set them all with setSource with keyword arguments, or adding a setVertexProg, setFragmentProg, and a function to call once all programs are set to actually handle the compiling. If possible it would be nice to replace one shader without replacing all of them. For example, being able to change the vertex shader and continue using the fragment shader that Blender generated. I haven't looked at that part of the code in a while to know how feasible that is.

I dislike this compatibility problem, @Campbell Barton (campbellbarton), @Mitchell Stokes (moguri) for you what the best for function setSource, add the new argument at the end or reorganize arguments order to setSource(vert, frag, geom, apply) ?

In D1338#30605, @Porteries Tristan (panzergame) wrote:

I dislike this compatibility problem, @Campbell Barton (campbellbarton), @Mitchell Stokes (moguri) for you what the best for function setSource, add the new argument at the end or reorganize arguments order to setSource(vert, frag, geom, apply) ?

Reorganizing the arguments will make compatibility problems. Because the actually setSource will take the parameters in this order. setSource(vertexProgram, fragmentProgram, apply). If I move geometryProgram between "fragmentProgram" and "apply" it will break compatibility.

So setSource(vertexProgram, fragmentProgram, apply, geometryProgram) is the only way without braking compatibility for the old setSource method.

Reorganizing the arguments will make compatibility problems. Because the actually setSource will take the parameters in this order. setSource(vertexProgram, fragmentProgram, apply). If I move geometryProgram between "fragmentProgram" and "apply" it will break compatibility.

i know, but setSource(v, f, g, apply) seems more logical, we already have function which had these compatibility problems before ?

In D1338#30616, @Porteries Tristan (panzergame) wrote:

i know, but setSource(v, f, g, apply) seems more logical, we already have function which had these compatibility problems before ?

Sure setSource(v, f, g, apply) is more logical, but will break all actual shaders. And I don't want to do that.

So we have only three ways to don't break the old API.

1. Doing it like I have done before with setGeometryProg().
2. Using the actual setSource(v, f, apply, g).
3. adding a new API setShader(v, f, g) (apply is useless).

hmmm, well, setSource(v, f, a, g) is the easier currently.

My suggestion is to create a new API and deprecate the old one. This new API should be flexible to changes so this does not happen again if we want to add support for tessellation shaders.

What about use:

shaders = {
    "vertex" : vertex_shader_text,
    "fragment" : fragment_shader_text,
    "geometry" : geometry_shader_text
}
setSource(shaders, true)

By this way you limit compatibility issues. For the moment you have to keep the old API too. I think you can override the setSource function by only checking if the first argument is a dictionnary, if not use the old API. The other way is to use an other function name, maybe:

• setSources ;
• setSourceDict ;
• setSourceList.

Maybe replace string by constants is better, e.g BL_Shader::[VERTEX/FRAGMENT/GEOMETRY]_SHADER_TEXT