[Interest] QtSVG deprecated

Thiago Macieira thiago at kde.org
Tue Jan 10 14:50:50 CET 2012


On Tuesday, 10 de January de 2012 05.13.57, Martin Holmes wrote:
> When I moved to Qt (from Delphi), I was delighted to discover that
> QImage supported SVG, because I'd been used to having to provide icon
> sets in multiple resolutions just to enable users to change toolbar
> sizes. SVG icons seemed a huge step forward, just as they do when you
> discover that your desktop icons on Linux are SVG and are scalable. Now
> it seems that the Qt team (or community, or whatever) are not interested
> in maintaining this forward-looking feature. Perhaps this is because the
> person or people who developed it are no longer involved, and no-one
> else wants to take it on; if so, I'd expect it to be classified as
> QXmlPatterns:
> 
> Overall module state: Done
> New maintainer required.

I've already explained why it's different. There is a replacement for SVG 
functionality in WebKit, however big that module is. It's far more complete 
and it supports a larger specification of SVG. QtSvg was designed and 
documented to support SVG Tiny 1.2 and even then we know of a few 
shortcomings.

QtXmlPatterns also chases after a standard or three, but unlike QtSvg, there 
is no other replacement for it. The few shortcomings that exist are 
documented.

By the way, the icons you see on Linux are often *not* the SVG versions of 
them. True, they often start as SVG, but they are pre-rendered to a few 
resolutions by the artists themselves. Often, they retouch the resulting PNGs 
so that the details are clear at that resolution and unnecessary noise is 
removed.

And one of the reasons why that started is *because* QtSvg was too limited. 
Artists don't care about SVG Tiny 1.2. They design their icons the way they 
like it and then we have developers and artists complaining that the QtSvg 
rasterisation wasn't the expected output.

> However, it seems things have gone further than this. The decision to
> deprecate seems to be based on the contention that webkit can be used
> instead, but frankly I don't see how, and in any case, that's an
> enormous overhead to get simple functionality in QImage. If the
> objection is that QtSvg supports only SvgTiny, then let it by all means
> be renamed QtSvgTiny.

Renaming doesn't solve any of the problems. It only introduces more.

> We're all familiar with the argument that "if you want it to be
> available, write and maintain it yourself", and of course that's a valid
> response to any complaint like this in an open source project. But if
> someone steps up to maintain it, could we expect that its status would
> be changed and the deprecation undone? 

Yes, definitely.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120110/df008858/attachment.sig>


More information about the Interest mailing list