> So my wonder is this: if the SVG rendering of QtWebKit/QtWebEngine is modern > and solid, why not "extracting" it > from those monsters and place it into a brand new QtSvg ?
Very easy to ask for something like that. When do you start? > This would bring two advantages:1- applications that need to render SVG > graphics can rely on a small footprint but > efficient QtSvg library2- QtWebEngine can be built without the SVG support > (if needed) to reduce the library footprint. > Now it's all monolithic and on embedded systems with low memory availability, > a 64MB library is a total killer. This might be. However, if you follow this list, you will now and then read from a Digia developer: Not enough resources. Very hard to argument against this. Apart from that, superficially your proposal sounds good, but it is a maintenance nightmare. The Qt project has no real control over the webkit code. Modularizing a non trivial 3rd party product? Keeping it up-to-date? Forget it. The only thing where I agree is that their proposal to use the webkit to render SVGs is ridiculous. I did it. On systems where the webkit stuff was needed and installed anyways. But even then it was a quite unwieldy solution. For systems with memory restrictions.... Guido _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
