so i've been looking some at the code and one thing that hit me was the lack of 'compilation firewalls' / 'pimpl idioms'

since its a library it really should be firewalled since a new member variable in the interface would force recompilation all the way up the chain that use the library.

it also has pretty heavy use of templates, so i guess its a tradeoff on speed vs abi compatibility.

anyway the reasoning either way should be made clear in the documentation what abi compatibility can be expected on {patch, point, major} release

some quick examples..

QSchematic::View has exposed members for zoom, those should be hidden so they have to be triggered the correct way, and trigger a update of view. if they are supposed to be static const values, well they should be const static values..
private members, well if we add or remove one member, that will break the size of the object unless recompiled.

QSchematic::Scene also have exposed members in header, so same issue here..

i can go on with QSchematic::Settings..

myself I'll use it as a static lib, so it kinda does not matter for me, but it is also buildable as a shared lib, then it does matter, reason i use it as static lib is just this reason, i can't know when the abi will break, so static was the sane solution, and i guess most people use it/will use it as a static lib for this reason.