[Interest] QtSVG deprecated
Martin Holmes
<http://labs.qt.nokia.com/2011/05/12/qt-modules-maturity-level-the-list/>
that QtSvg is now deprecated:
[quote]
QtSvg
Overall module state: Deprecated
New maintainer required
Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in
QtWebKit, which should be used instead; we welcome research for a
replacement for the SVG-generating code.
[/quote]
I use QtSvg for toolbar icons and similar application-level graphics, to
provide easy scalability. Will QImage still support SVG images after
QtSvg is gone? I can't imagine how I could use WebKit for this
functionality.
Cheers,
Martin
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mho...@uvic.ca)
_______________________________________________
Interest mailing list
Inte...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Dan White
Contact me off-list, please. (or I will when I get home and dig your address out of my mailing list archives)
I might be willing to volunteer to maintain this piece.
One motivation is that I use it in a project of mine and transitioning to QtWebKit just for the SVG may cause excessive bloat.
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
Chris Meyer
custom webkit" (QtWebKit). The main use was to render SVG into
QImages.
Going forward, I'm planning on using the QtSvg module. Currently, it
partially supports SVG Tiny; but I'm hoping to develop any missing
features as needed.
I am not in a position to volunteer to be maintainer right now, but
I'm interested in contributing code, doing testing, paying money in
the form of feature bounties, and providing guidance where possible.
Other than the issue of a maintainer, is there any other reason QtSvg
is deprecated? I think it's important to have this functionality
independent of webkit.
Jason H
From: Chris Meyer <cmeyer...@gmail.com>
To: mho...@uvic.ca
Cc: "inte...@qt-project.org" <inte...@qt-project.org>
Sent: Monday, January 9, 2012 5:01 PM
Subject: Re: [Interest] QtSVG deprecated
Scott Aron Bloom
This came up at DevDays…
There needs to be a status of “No maintained because we consider it complete”
Meaning, the code is stable, known bugs are fixed, and new enhancements will not be added as “other” classes are better used.
However, the code will NOT be removed from a new version. Another example is the QDom code base.
Scott
Stephen Kelly
On Monday, January 09, 2012 21:40:32 Dan White wrote:
> Thiago !
> Contact me off-list, please. (or I will when I get home and dig your address
> out of my mailing list archives) I might be willing to volunteer to
> maintain this piece.
> One motivation is that I use it in a project of mine and transitioning to
> QtWebKit just for the SVG may cause excessive bloat.
You don't need Thiago.
You just need to create a gerrit account and start maintaining the code.
Thanks,
--
Stephen Kelly <stephe...@kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
Martin Holmes
processing XML documents without it. But the status of Deprecated
definitely means:
"Module or code will be eventually removed (Qt source and binary
compatibility guidelines apply)"
and binary compatibility can be broken when we move to Qt5, so it does
look as though both SVG and DOM could be gone by the end of the year.
That's scary, and seems silly to me.
What are the "'other' classes that are better used" for rendering SVG
toolbutton images, or modelling an XML document?
Cheers,
Martin
On 12-01-09 02:16 PM, Scott Aron Bloom wrote:
> This came up at DevDays…
>
> There needs to be a status of “No maintained because we consider it
> complete”
>
> Meaning, the code is stable, known bugs are fixed, and new enhancements
> will not be added as “other” classes are better used.
>
> However, the code will NOT be removed from a new version. Another
> example is the QDom code base.
>
> Scott
>
> *From:*interest-bounces+scott.bloom=onshor...@qt-project.org
> [mailto:interest-bounces+scott.bloom=onshor...@qt-project.org] *On
> Behalf Of *Jason H
> *Sent:* Monday, January 09, 2012 2:14 PM
> *To:* Chris Meyer; mho...@uvic.ca
> *Cc:* inte...@qt-project.org
> *Subject:* Re: [Interest] QtSVG deprecated
>
> I don't think it's going away, it's just not being maintained.
>
> It's good for what it does, but many of the desired enhancements would
> result in the module blowing up in run-time size. The module exists as a
> good trade-off. And this I think is why it is deprecated. If it were
> maintained it wouldn't be good for the little stuff anymore. I see many
> requested changes wanting to DOM-ify it, which would definitely result
> in bloat (QtDOM is also deprecated, btw)
>
> *From:*Chris Meyer <cmeyer...@gmail.com
> <mailto:cmeyer...@gmail.com>>
> *To:* mho...@uvic.ca <mailto:mho...@uvic.ca>
> *Cc:* "inte...@qt-project.org <mailto:inte...@qt-project.org>"
> <inte...@qt-project.org <mailto:inte...@qt-project.org>>
> *Sent:* Monday, January 9, 2012 5:01 PM
> *Subject:* Re: [Interest] QtSVG deprecated
>> (mho...@uvic.ca <mailto:mho...@uvic.ca>)
>> _______________________________________________
>> Interest mailing list
>> Inte...@qt-project.org <mailto:Inte...@qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/interest
> _______________________________________________
> Interest mailing list
> Inte...@qt-project.org <mailto:Inte...@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/interest
Jason H
From: Martin Holmes <mho...@uvic.ca>
To: "inte...@qt-project.org" <inte...@qt-project.org>
Sent: Monday, January 9, 2012 5:21 PM
Subject: Re: [Interest] QtSVG deprecated
Scott Aron Bloom
Thiago, assure me, QtDom is NOT going anywhere.. However, its depreciated and not supported. While I understand your concern, and I have it as well.. Depricated in Qt world, is not as drastic as other frameworks... Sometimes...
Which is WHY they need another status, and Thiago agreed. However, that doesn’t mean it exists yet.
For QDom, the QXmlStream classes are the replacement...
Scott
Jason H
From: Scott Aron Bloom <Scott...@onshorecs.com>
To: inte...@qt-project.org
Sent: Monday, January 9, 2012 5:29 PM
Scott Aron Bloom
Lets not go down this path … AGAIN… I still use QDom when necessary… It comes up every 4-6 months on the list..
From a Qt POV, QDom has been deprecated, and the stream classes are the future..
Do they support all the functionality today? No… Can they be used, or built upon to give that functionality.. Yes… for some.. no for others..
I can tell you, that the QDom fails so miserably for large XML parses, that using it as QString is just a horrible idea to me… However, I could see a wanting to do so.
And I agree, I like having the “complete” XML data represented in memory… but there are major limitations to that…
Scott
Jason H
Scott Aron Bloom
WRT QDom, I agree… as to the pending MS acquisition, I think we are all a bit concerned on that rumor… and there is no point in speculating unless we plan on coming up with the cash to buy the Qt line from Nokia, or hope the Qt open source KDE system kicks in J
Jason H
Stephen Kelly
On Monday, January 09, 2012 14:52:11 Jason H wrote:
> Then open governance needs to step in and issue assurances to all of us that
> things won't change.
Open Governance is you. At least to the extent of any assurance can be given.
If you want it to be maintained then start maintaining it and assure everyone else that you will keep it working.
Scott Aron Bloom
Qt sold the COMMERCIAL licensing to digia…
Thiago Macieira
> On Monday, January 09, 2012 14:52:11 Jason H wrote:
> > Then open governance needs to step in and issue assurances to all of us
> > that things won't change.
>
> Open Governance is you. At least to the extent of any assurance can be
> given.
>
> If you want it to be maintained then start maintaining it and assure
> everyone else that you will keep it working.
The only guarantee you'll get is the one in the Qt 5.0 mission statement: it's
mostly source-compatible with Qt 4, except for API and classes long
deprecated. And even then there's a lot of discussion about simply moving
those classes to a separate library you can import into your code to keep it
working.
QtSvg and QtXml are in the 5.0 sources today and will most likely remain
there. No one has suggested removing them.
But understand that no one will fix bugs in them either.
--
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
Thiago Macieira
> This came up at DevDays...
>
>
>
> There needs to be a status of "No maintained because we consider it
> complete"
>
> Meaning, the code is stable, known bugs are fixed, and new enhancements
> will not be added as "other" classes are better used.
That's the "Done" state.
QtSvg was in the "Deprecated" camp for two reasons:
1) there's a more complete implementation of SVG inside WebKit
2) QtSvg says it implements SVG Tiny 1.2
The second item is important: we can't consider done if we haven't achieved
full compliancy. Not to mention that any bugs related to being compliant would
need to be fixed.
That's why it ended up in Deprecated: we actually want people to stop using
the module.
> However, the code will NOT be removed from a new version. Another
> example is the QDom code base.
--
Alex Malyushytskyy
which currently works an all platforms including icons (but not
limited to icons).
Would you advice adding webkit dependency for such purpose?
There is a huge difference between not actively adding new futures and
keeping code alive
updating it if necessary,
Status of "No maintained because we consider it complete" would be
fine if it did not assume
stopping bug fixes.
As I understand "No maintained" and "Done" state should have a core
difference - second assumes bug fixes and updates for new platforms if
necessary.
Why would not allow people to maintain it?
Regards,
Alex
Thiago Macieira
> As somebody mentioned above svg is the great way to create scalable graphics
> which currently works an all platforms including icons (but not
> limited to icons).
>
> Would you advice adding webkit dependency for such purpose?
Yes.
> There is a huge difference between not actively adding new futures and
> keeping code alive
> updating it if necessary,
>
> Status of "No maintained because we consider it complete" would be
> fine if it did not assume
> stopping bug fixes.
>
> As I understand "No maintained" and "Done" state should have a core
> difference - second assumes bug fixes and updates for new platforms if
> necessary.
>
> Why would not allow people to maintain it?
You're welcome to do it, but if no one steps up, it will remain in Deprecated
state. That includes not fixing any bugs except for crashes and data loss and
not porting to new platforms.
There was no "not maintained" state when we published the list back in May:
everything is maintained by someone, even if reluctantly. There is still no
such state.
Constantin Makshin
On Jan 10, 2012 7:59 AM, "Thiago Macieira" <thi...@kde.org> wrote:
> On Monday, 9 de January de 2012 16.47.49, Alex Malyushytskyy wrote:
> > As somebody mentioned above svg is the great way to create scalable graphics
> > which currently works an all platforms including icons (but not
> > limited to icons).
> >
> > Would you advice adding webkit dependency for such purpose?
>
> Yes.
Using a 20MB monster just to rasterize toolbar/menu/... icons? That looks crazy to me.
librsvg seems to be better in this case -- the library itself and its dependencies (libcroco, cairo, etc.) will take a few megabytes, but that still would be much more lightweight solution than WebKit.
Konstantin Tokarev
Unfortunately, It's also deprecated (e.g. AFAIK it was removed from Gentoo)
--
Regards,
Konstantin
Jason H
From: Thiago Macieira <thi...@kde.org>
To: inte...@qt-project.org
Sent: Monday, January 9, 2012 10:59 PM
Subject: Re: [Interest] QtSVG deprecated
Martin Holmes
webkit to provide SVG support to QImage?
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.
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.
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? Or would that person end up
maintaining a forked library outside of the main Qt project, to avoid
the eventual end of deprecation (removal)? If so, we'll end up with a
situation like that of Delphi when it was most badly managed, where core
functionality that everyone depended on (such as Unicode support or GIF
support) was written and maintained by volunteers outside the main
project, and no-one could rely on the long term health of some essential
libraries. The overall effect of this was to make the Delphi project
seem incoherent, and to force developers to retrieve and install dozens
of extra bits and pieces before they could get productive with the IDE.
So this is all by way of saying: who does one lobby, and how does one
lobby, to try to get this deprecated status changed?
Cheers,
Martin
On 12-01-10 04:49 AM, Jason H wrote:
> So what we need is not new code, just a new label.
> Seems easier to add a label then to re-engineer the module.
>
>
> ------------------------------------------------------------------------
> *From:* Thiago Macieira <thi...@kde.org>
> *To:* inte...@qt-project.org
> *Sent:* Monday, January 9, 2012 10:59 PM
> *Subject:* Re: [Interest] QtSVG deprecated
> Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> -
> thiago (AT) kde.org <http://kde.org>
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> Interest mailing list
> Inte...@qt-project.org <mailto:Inte...@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/interest
Constantin Makshin
librsvg? Yes, it's [official] web site seems abandoned, but:
http://ftp.gnome.org/pub/GNOME/sources/librsvg/
http://git.gnome.org/browse/librsvg/
http://packages.gentoo.org/package/gnome-base/librsvg
I don't see any signs of librsvg's death.
Thiago Macieira
> 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
Jason H
From: Jason H <scor...@yahoo.com>
To: Scott Aron Bloom <Scott...@onshorecs.com>; "inte...@qt-project.org" <inte...@qt-project.org>
Sent: Monday, January 9, 2012 6:08 PM
Christian Quast
(QSvgGenerator is part of the SVG module isn't it? Otherwise my question is
rendered mute.)
I am also using SVG in my application which is a desktop application that
presents the user with a graphical representation of their data.
I use a QGraphicsScene to do on-screen rendering. The 'images' that are shown
on-screen will at some point be used in scientific publications so I need to
provide an export. A vector format is the obvious choice.
Since Qt can create SVG easily based on a QGraphicsScene and SVG is supported
on all my target platforms I chose SVG. Currently, I am using code that looks
like this:
// setup scene
QGraphicsScene scene;
scene.addItem(...);
// setup svg generator
QSvgGenerator svgGen;
svgGen...
// render scene to svg
QPainter painter( &svgGen );
scene.render( &painter );
As QtSVG is now deprecated and superseded by QtWebKit how would the same be
done using the webkit module. I have never looked at the webkit module because
I haven't seen any use cases so far.
Thanks for your input
Christian
--
sorry if this mail gets posted again, its awaiting moderator approval as I
accidently used the wrong email address before :(
Andreas Pakulat
> This all seems very disappointing to me. How would you actually use
> webkit to provide SVG support to QImage?
>
> 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.
As far as I know every artist will tell you that this does not work, at
least not without creating useless icons on smaller sizes. As Thiago
said you'll probably find quite a lot of icons on your system that look
differently in 16x16 or 8x8 than in the larger resolutions since they
have more details in those larger scales (and the original SVG).
You could of course simply create icons that scale down to 8x8 by
leaving out details etc. but such icons often look pretty sad when
scaled up.
Andreas
Martin Holmes
I don't know whether it's because of the original icon set I chose
(Nuvola), but my icons work just fine at different scales, even down to
16x16. I've created many more icons based on the original Nuvola ones. I
often go in and hand-edit the SVG to keep it simple, so I suspect I'm
not using any features that aren't covered by SvgTiny. Even those I
haven't edited (straight output from Inkscape) have worked fine.
For lots of programmers working on small projects without a resident
artist, the current SVG support in QImage has been a huge blessing,
giving us a lot of flexibility without the need to generate and
distribute huge icon collections.
Cheers,
Martin
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mho...@uvic.ca)
Chris Meyer
> This all seems very disappointing to me. How would you actually use
> webkit to provide SVG support to QImage?
I extracted this code from my source to convert SVG to QImage using
QtWebKit. It's untested in this specific form, but should give you the
idea.
And, again, if you want any chance of being accepted on the Mac App
Store, you can't include QtWebKit (at least in its current form, which
uses a library that Apple provides that uses private API calls).
#include <QGraphicsWebView>
QImage makeSvgImage(const QSize &svg_size,
const QByteArray &svg_byte_array,
const QString &svg_mime_type)
{
QImage image(svg_size);
image.fill(Qt::transparent);
QPainter painter(&image);
painter.setRenderHint(QPainter::Antialiasing);
painter.setRenderHint(QPainter::SmoothPixmapTransform);
painter.setRenderHint(QPainter::TextAntialiasing);
QRect frame(QPoint(), image.size());
std::auto_ptr<QGraphicsScene> scene(new QGraphicsScene(frame));
QGraphicsWebView *web_view = new QGraphicsWebView();
web_view->setGeometry(frame);
web_view->setContent(svg_byte_array, svg_mime_type);
web_view->setOpacity(0.001); // work around bug in web view 4.8
(draws white background without this)
scene->addItem(web_view);
scene->render(&painter);
return image;
Martin Holmes
I'm not bothered about getting in the Mac App Store. Seems like a lot of
difficult hoop-jumping just to give Apple a huge percentage of your
income, with the added risk of being booted out unexpectedly for no good
reason. :-)
Cheers,
Martin
> .
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mho...@uvic.ca)
Uwe Rathmann
> I extracted this code from my source to convert SVG to QImage using
> QtWebKit. It's untested in this specific form, but should give you the
> idea.
Well this code requires a QGraphicsWebView and QGraphicsScene object -
meaning even one more module, I don't need in my application.
This is my use case: we are building user interfaces that have to run on
terminals with different physical resolutions. The user interfaces are
full of images, to decorate the controls or to be touchable itself.
The scalability of SVG images + using QLayout classes saves us a lot of
time as we don't need to #ifdef our layout code for the different devices.
I'm also not thrilled about having to introduce a complete Web Browser
( even the time of cross compiling Qt gets doubled ) + QGV to embedded
devices with limited resources.
But isn't this a problem of missing APIs and modularization of the
QtWebKit module only ?
I wouldn't mind to use its SVG renderer ( as it seems to be the better
one ), if it wouldn't have the requirement for all the other stuff, that
has nothing to do with the simple SVG -> QPixmap functionality.
My 2 cents,
Uwe
Thiago Macieira
> I'm also not thrilled about having to introduce a complete Web Browser
> ( even the time of cross compiling Qt gets doubled ) + QGV to embedded
> devices with limited resources.
A device with limited resources but powerful enough that rasterising SVG on
the fly isn't an issue?
> But isn't this a problem of missing APIs and modularization of the
> QtWebKit module only ?
It can't be done.
> I wouldn't mind to use its SVG renderer ( as it seems to be the better
> one ), if it wouldn't have the requirement for all the other stuff, that
> has nothing to do with the simple SVG -> QPixmap functionality.
The SVG code is about half of WebKit. Plus it pulls in another fourth of
webkit in terms of the JavaScript interpreter.
So if you complain that WebKit is big, remember that it's big *because* of
SVG, not in spite of it.
Uwe Rathmann
> A device with limited resources but powerful enough that rasterising SVG
> on the fly isn't an issue?
It is - but as our layouts are fix during the runtime of the application
this only has to be done once. Later the icons are taken from a pixmap
cache ( a further optimization could be to store the cache to disk ). So
we only have the penalty of a worse startup time and when we show a page
the first time.
I have to admit, that we don't need difficult SVG stuff - only small
icons/symbols, but they are many: > 1000 icons with about 60k lines XML
code today ( see: http://www.fendt.com/int/
tractors_fendtvariotronic_terminalsimulation.asp ).
One idea I had was to "precompile" the SVG images on the PC to something
QPicture can load. Unfortunately QPicture seems to be forgotten, when Qt4
moved to a floating based rendering. It can't be scaled properly because
the boundingRect is not accurate and in integers only.
By the way: because of this limitation I started to implement a
QPaintDevice in Qwt that is intended to have:
- similar record/replay functionality like QPicture ( no save/load )
- the scalability of QSVGRenderer
- it can be copied around like QImage/QPixmap
> So if you complain that WebKit is big, remember that it's big *because*
> of SVG, not in spite of it.
SVG is fine as it is something our designer team can create with their
tools and QSvgRenderer is good enough to render ( I was not even aware,
that it is so limited ). But if there would be any other type of vector
graphic format ( even if proprietary ) it would be fine - or even better
- too.
But at least it would be nice to offer an easy to use API ( if not
available yet ) to the WebKit renderer, that renders a SVG document to a
QPainter without having to use QGV classes.
Thiago Macieira
> On Wed, 11 Jan 2012 11:35:15 -0200, Thiago Macieira wrote:
> > A device with limited resources but powerful enough that rasterising SVG
> > on the fly isn't an issue?
>
> It is - but as our layouts are fix during the runtime of the application
> this only has to be done once. Later the icons are taken from a pixmap
> cache ( a further optimization could be to store the cache to disk ). So
> we only have the penalty of a worse startup time and when we show a page
> the first time.
Can't you pre-rasterise the files and store them on the device's image? Sounds
like a much better solution to me.
> One idea I had was to "precompile" the SVG images on the PC to something
> QPicture can load. Unfortunately QPicture seems to be forgotten, when Qt4
> moved to a floating based rendering. It can't be scaled properly because
> the boundingRect is not accurate and in integers only.
Use PNG.
Martin Holmes
is a really good idea. And we have one, and it works well for the kind
of simple GUI graphics that show up in touch interfaces and on toolbars.
So I ask again: What's the process for lobbying to keep QtSvg as a
supported implementation of SvgTiny?
Cheers,
Martin
On 12-01-11 05:35 AM, Thiago Macieira wrote:
> On Wednesday, 11 de January de 2012 08.59.31, Uwe Rathmann wrote:
>> I'm also not thrilled about having to introduce a complete Web Browser
>> ( even the time of cross compiling Qt gets doubled ) + QGV to embedded
>> devices with limited resources.
>
> A device with limited resources but powerful enough that rasterising SVG on
> the fly isn't an issue?
>
>> But isn't this a problem of missing APIs and modularization of the
>> QtWebKit module only ?
>
> It can't be done.
>
>> I wouldn't mind to use its SVG renderer ( as it seems to be the better
>> one ), if it wouldn't have the requirement for all the other stuff, that
>> has nothing to do with the simple SVG -> QPixmap functionality.
>
> The SVG code is about half of WebKit. Plus it pulls in another fourth of
> webkit in terms of the JavaScript interpreter.
>
> So if you complain that WebKit is big, remember that it's big *because* of
> SVG, not in spite of it.
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mho...@uvic.ca)
Pau Garcia i Quiles
A few years ago everybody in KDE was sure WebKit was going to replace
QtSVG for SVG rendering. It was assumed WebKit would be better for
SVG.
Then someone (Ariya?) actually experimented and compared QtSVG,
WebKit, librsvg and some more (AntiGrain?). Surprisingly The result
was WebKit was usually worse than QtSVG, and the most accurate
renderer was librsvg. Unfortunately I cannot find that blog post now
but it would be interesting to repeat the experiment and see if WebKit
is actually the best choice for SVG rendering.
On Mon, Jan 9, 2012 at 10:29 PM, Martin Holmes <mho...@uvic.ca> wrote:
> I notice here:
>
> <http://labs.qt.nokia.com/2011/05/12/qt-modules-maturity-level-the-list/>
>
> that QtSvg is now deprecated:
>
> [quote]
> QtSvg
> Overall module state: Deprecated
> New maintainer required
> Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in
> QtWebKit, which should be used instead; we welcome research for a
> replacement for the SVG-generating code.
> [/quote]
>
> I use QtSvg for toolbar icons and similar application-level graphics, to
> provide easy scalability. Will QImage still support SVG images after
> QtSvg is gone? I can't imagine how I could use WebKit for this
> functionality.
>
> Cheers,
> Martin
>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mho...@uvic.ca)
> _______________________________________________
> Interest mailing list
> Inte...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Andreas Pakulat
> These are all good reasons why a fast, light implementation of SvgTiny
> is a really good idea. And we have one,
No you don't. You have something which tries to implement Svg Tiny, but
apparently is not complete or bug-free.
> and it works well for the kind
> of simple GUI graphics that show up in touch interfaces and on toolbars.
> So I ask again: What's the process for lobbying to keep QtSvg as a
> supported implementation of SvgTiny?
As Thiago said: Find someone to work on it, which probably means paying
someone to work on/maintain the codebase outside the Nokia/Qt team.
Andreas
Jason H
You bring up a good point. If we moved to the lib with qt wrappers, maybe as a qt plugin we'd keep everyone happy and qtsvg could die. -J |
From: Pau Garcia i Quiles <pgqu...@elpauer.org>;
To: <mho...@uvic.ca>;
Cc: inte...@qt-project.org <inte...@qt-project.org>;
| > _______________________________________________ > Interest mailing list > Inte...@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest |
| -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) |
Jason H
Uwe Rathmann
> Can't you pre-rasterise the files and store them on the device's image?
> Sounds like a much better solution to me.
The sizes of the icons are the result of the calculation of QLayouts - I
don't know them in advance. They might even change during runtime, when
layout relevant attributes are changing ( f.e the user wants a different
language ).
>> One idea I had was to "precompile" the SVG images on the PC to
>> something QPicture can load. Unfortunately QPicture seems to be
>> forgotten, when Qt4 moved to a floating based rendering. It can't be
>> scaled properly because the boundingRect is not accurate and in
>> integers only.
>
> Use PNG.
How does PNG help in the context of scalable vector graphics ?
Thiago Macieira
> On 11.01.12 08:11:19, Martin Holmes wrote:
> > These are all good reasons why a fast, light implementation of SvgTiny
> > is a really good idea. And we have one,
>
> No you don't. You have something which tries to implement Svg Tiny, but
> apparently is not complete or bug-free.
This also assumes that your artists are fine with the QtSvg rendering.
Depending on your artists and where else the same .svg files are used, that's
not possible.
If you have the artist developing these .svg files specifically for your
application, then what she sees in the drawing tool is irrelevant. It's the
QtSvg rendering that matters, so the artist will tweak the .svg file to produce
the wanted result.
If you are taking .svg files from elsewhere or if you're using QtSvg and
another renderer, then you will notice how QtSvg fails to show the same thing.
Thiago Macieira
> On Wed, 11 Jan 2012 14:05:40 -0200, Thiago Macieira wrote:
> > Can't you pre-rasterise the files and store them on the device's image?
> > Sounds like a much better solution to me.
>
> The sizes of the icons are the result of the calculation of QLayouts - I
> don't know them in advance. They might even change during runtime, when
> layout relevant attributes are changing ( f.e the user wants a different
> language ).
>
>
> How does PNG help in the context of scalable vector graphics ?
It would have helped in the scenario I had in my head, which is that the sizes
are fixed per device. I thought you used one codebase for multiple devices, but
each device had it fixed. That would allow you to pre-calculate the sizes and
pre-render before generating the image. The output of the rasterisation would
be PNG.
Martin Holmes
> On 11.01.12 08:11:19, Martin Holmes wrote:
>> These are all good reasons why a fast, light implementation of SvgTiny
>> is a really good idea. And we have one,
>
> No you don't. You have something which tries to implement Svg Tiny, but
> apparently is not complete or bug-free.
It works pretty well whenever I've used it. No code is bug-free, and few
implementations of W3C standards are truly complete; these are not
reasons to throw it away.
>> and it works well for the kind
>> of simple GUI graphics that show up in touch interfaces and on toolbars.
>> So I ask again: What's the process for lobbying to keep QtSvg as a
>> supported implementation of SvgTiny?
>
> As Thiago said: Find someone to work on it, which probably means paying
> someone to work on/maintain the codebase outside the Nokia/Qt team.
A couple of people have already suggested that they might help. I don't
have the graphics skills myself. But I was wondering whether we could
make the case to the Nokia/Qt team themselves that they should
un-deprecate it.
Cheers,
Martin
> Andreas
>
> _______________________________________________
> Interest mailing list
> Inte...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mho...@uvic.ca)
Thiago Macieira
> A couple of people have already suggested that they might help. I don't
> have the graphics skills myself. But I was wondering whether we could
> make the case to the Nokia/Qt team themselves that they should
> un-deprecate it.
The requirement will be the same: the people to work on it. $100k should fund
one developer for a year in Oslo.
It might be easier to convince Digia to do it, as well as (indirectly) fund
that maintainer.
Uwe Rathmann
> It would have helped in the scenario I had in my head, which is that the
> sizes are fixed per device.
To make my point: all I need is a scalable vector format, but it doesn't
need to be SVG. Actually SVG is by far not optimal ( slow XML parsing )
and I would be happy to get rid of its overhead.
When Qt would offer something simple like QPicture ( QPainter commands in
some proprietary format ) but with proper geometries ( bounding
rectangles, control points ) in floating points - I would say goodbye to
QtSvg easily.
Pier Luigi
Have you ever eard of the Haiku Vector Icon Format [*]?
Seems best suited for icons than SVG.
[*] http://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format
--
"Don't let the noise of other's opinions drown out your own inner
voice." (Steve Jobs)
Uwe Rathmann
> Have you ever eard of the Haiku Vector Icon Format [*]? Seems best
> suited for icons than SVG.
No, but something like this would be fine.
But the main issue is, that Qt doesn't offer a scalable paint device like
a QImage - what we have today is QPicture or the combination of
QSvgGenerator/QSvgRenderer.
For a plot library - like my open source project Qwt ( http://qwt.sf.net
) - generating PDF documents is one of its key features. As PDF is a
vector graphic format and the user wants to zoom in to analyze details in
the PDF viewer, Qwt can't rasterize graphics ( f.e crosses marking the
positions of a scatter plot ) like it does it on screen.
The problem here is not about loading icons from files - it is more about
having comfortable class APIs. Qwt is a library and many graphics might
be defined on the application side. The solution today is, that Qwt needs
to call application code through virtual methods, what sometimes leads to
nasty dependencies between unrelated classes.
It would be easier when the application paints its graphics to some
scalable image class and passes it to the Qwt library - like everyone
wants to pass a pixmap to a button instead of subclassing each button
only for overloading some sort of drawButtonLabel method.
That's why I started to implement a trivial paint device for Qwt 6.1,
that records graphic primitives ( as QPainterPath ) and state changes in
memory. But of course I'm not happy to have such a class in a plot
library and I would love to throw it away, when Qt comes up with
something better.
Uwe
Alex Malyushytskyy
> apparently is not complete or bug-free.
I believe you are wrong.
Check discussion above and there was a statement that it is considered
"Complete"
My over 20 years experience shows that there is no bug free software,
there are bugs that either have not being found yet or just ignored.
Regards,
Alex
Andreas Pakulat
> > No you don't. You have something which tries to implement Svg Tiny, but
> > apparently is not complete or bug-free.
>
> I believe you are wrong.
> Check discussion above and there was a statement that it is considered
> "Complete"
Thats not how I read Thiago's first reply in this thread:
On Mon, Jan 9, 2012 at 4:17 PM, Thiago Macieira <thi...@kde.org> wrote:
> On Monday, 9 de January de 2012 14.16.05, Scott Aron Bloom wrote:
>> This came up at DevDays...
>>
>>
>>
>> There needs to be a status of "No maintained because we consider it
>> complete"
>>
>> Meaning, the code is stable, known bugs are fixed, and new
>> enhancements
>> will not be added as "other" classes are better used.
>
> That's the "Done" state.
>
> QtSvg was in the "Deprecated" camp for two reasons:
> 1) there's a more complete implementation of SVG inside WebKit
> 2) QtSvg says it implements SVG Tiny 1.2
>
> The second item is important: we can't consider done if we haven't
> achieved
> full compliancy. Not to mention that any bugs related to being
> compliant would
> need to be fixed.
>
> That's why it ended up in Deprecated: we actually want people to stop
> using
> the module.
To me that clearly says QtSvg does not implement SVG Tiny 1.2 fully and
not just that its implementation is different from other
implementations.
> My over 20 years experience shows that there is no bug free software,
> there are bugs that either have not being found yet or just ignored.
Well, one example of a bug-free application would be
int main()
{
return 0;
}
Sure it does not do anything useful, but its pretty much bug-free. I
agree though that real-world applications always have bugs :)
Thiago Macieira
> > No you don't. You have something which tries to implement Svg Tiny, but
> > apparently is not complete or bug-free.
>
> I believe you are wrong.
> Check discussion above and there was a statement that it is considered
> "Complete"
>
> My over 20 years experience shows that there is no bug free software,
> there are bugs that either have not being found yet or just ignored.
I never said that.
The adjective "complete" was used when we were talking about APIs that had
reached the intended feature level support and we did not plan on extending
them further. That's what the "Done" state in the maturity level means. Some
people suggested that QtSvg might be in that, and we compared to QtXmlPatterns
and QtXml (DOM classes).
QtSvg is by no mean complete or done. It's definitely incomplete and we know
it. That's one of the reasons why it became Deprecated instead of Done.
Atlant Schmidt
> > there are bugs that either have not being found yet or just ignored.
>
> Well, one example of a bug-free application would be
>
> int main()
> {
> return 0;
> }
>
> Sure it does not do anything useful, but its pretty much bug-free. I
> agree though that real-world applications always have bugs :)
This piece of code *MIGHT* be bug-free considered
in isolation, but in a real world runtime environment
with dynamic linking and fancy scheduling, I'm pretty
sure you could detect anomalies in the execution of
even this simple code if you tried hard enough.
For example, what if a new process can't be created
so the shell can't fork-and-exec this process? What
if the handling of Flash memory failures delay the
execution of this code? Are those anomalies? And
remember, there's commonly in-process code that
executes before main() is called.
I might speculate that the only codes that might be
bug-free are small, entirely self-contained snippets
of assembly language loaded from some guaranteed
loading mechanism (like the front panel toggle
switches), but then I'm reminded of the infamous
Pentium floating-point bug; even assembly language
runs in a run-time environment!
Well, maybe something small written in Verilog and
burned into an FPGA...
Atlant
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
Gopalakrishna Bhat
> > My over 20 years experience shows that there is no bug free software,
> > there are bugs that either have not being found yet or just ignored.
>
> Well, one example of a bug-free application would be
>
> int main()
> {
> return 0;
> }
>
> Sure it does not do anything useful, but its pretty much bug-free. I
> agree though that real-world applications always have bugs :)
It all depends on what you want your application to do isn't it. One might think of this as a bug, another it as a required behaviour.
--
My blog http://gkbhat.blogspot.com
Andreas Pakulat
> > > My over 20 years experience shows that there is no bug free software,
> > > there are bugs that either have not being found yet or just ignored.
> >
> > Well, one example of a bug-free application would be
> >
> > int main()
> > {
> > return 0;
> > }
> >
> > Sure it does not do anything useful, but its pretty much bug-free. I
> > agree though that real-world applications always have bugs :)
>
> This piece of code *MIGHT* be bug-free considered
> in isolation, but in a real world runtime environment
> with dynamic linking and fancy scheduling, I'm pretty
> sure you could detect anomalies in the execution of
> even this simple code if you tried hard enough.
Sure, the environment might be buggy, but that does not change the fact
that this piece of software can be considered bug-free.
> For example, what if a new process can't be created
> so the shell can't fork-and-exec this process? What
> if the handling of Flash memory failures delay the
> execution of this code? Are those anomalies? And
> remember, there's commonly in-process code that
> executes before main() is called.
Ok, I shouldn't have said application when I really meant: 'this piece
of code' :). The above function is bug-free, executing it in a
buggy environment does not mean it suddenly has a bug.
Andreas
Atlant Schmidt
> Ok, I shouldn't have said application when I really meant: 'this
> piece of code' :). The above function is bug-free, executing it
> in a buggy environment does not mean it suddenly has a bug.
Do you *REALLY* know that? You might even know
that your C(++) code doesn't have any bugs, but
what you actually execute is machine language
produced by your compiler toolchain (etc.).
Unless you inspect the ultimate binary code
while loaded in execution memory, how can you
be sure?
(Compiler/toolchain validation is a huge area
of very serious discussion.)
And, as another poster to the thread pointed out,
it's only bug-free if it meets the specs. We
haven't seen those ;-) !
Atlant
Andreas
Click https://www.mailcontrol.com/sr/WfaZNZpboVjTndxI!oX7UuoY1VmXKYhKizEsIk+zxQbMYzcFpPArZDwgVQ8+dKHUO9sXebjFfhK7aUicAedHBg== to report this email as spam.
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
Thiago Macieira
> (Compiler/toolchain validation is a huge area
> of very serious discussion.)
For example, I've found a serious issue with the toolchain today, relating to
Qt 5.
André Pönitz
> On Wednesday, 11 de January de 2012 15.34.34, Alex Malyushytskyy
> wrote:
> > > No you don't. You have something which tries to implement Svg
> > > Tiny, but apparently is not complete or bug-free.
> >
> > I believe you are wrong. Check discussion above and there was a
> > statement that it is considered "Complete"
> >
> > My over 20 years experience shows that there is no bug free
> > software, there are bugs that either have not being found yet or
> > just ignored.
>
> I never said that.
>
> The adjective "complete" was used when we were talking about APIs
> that had reached the intended feature level support and we did not
> plan on extending them further. That's what the "Done" state in the
> maturity level means. Some people suggested that QtSvg might be in
> that, and we compared to QtXmlPatterns and QtXml (DOM classes).
>
> QtSvg is by no mean complete or done. It's definitely incomplete
> and we know it. That's one of the reasons why it became Deprecated
> instead of Done.
This whole "Deprecated" and "Done" talk does honestly not make
much sense to me.
Calling something "Deprecated" just because it is missing
features and there is nobody actively working on it is
simply wrong.
It also sends the message "I'd like to get rid of it, rather
sooner than later, and any minute someone spends on it is
likely to be wasted".
"Useful, but incomplete" essentially describes the same state
but sends a completely different message.
Andre'
PS: If you don't agree then you'd better call rcc "deprecated",
too. Missing features, no active maintenance. Meets your
definition, doesn't it?