Re: [Development] QtCore missing check for memory allocation
On Tuesday 10 March 2015 10:10:46 Alex Montgomery wrote: Note that we're talking about a standard violation in the first place. The standard says you can replace operator new, so if MSVC doesn't allow you to do it properly, then you can throw the standard out of the window. If an inline operator new (for MSVC only) solved the problem, it would be ok. As in, you'd be ok with individuals locally hacking Qt to work this way, or as in you'd be ok with including a mechanism in a future version of Qt to replace new and delete that (on Windows only) used this methodology? I'm ok with adding small patches that would ease your local maintenance burden, so long as they don't increase ours unduly and as long as they don't have any performance impact by default. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt3d examples with qt5.5 crashing
Hi, When i try to run any of the compiled qt3d application's release version.The application crashes, and this are the error details collected by windows: I don''t see any crashes with MSVC2013 64bit/5.5. Can you please provide a stack trace and the output of the qtdiag tool? Regards, Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtSvg
On 12 March 2015 at 16:47, Massimo Callegari massimocalleg...@yahoo.it wrote: 3- it removes duplicated code between QtSvg and QtWebEngine But there's no such code. QtWebEngine is a thin wrapper around Blink/Chromium. The idea is precisely that Qt currently does not have the resources for maintaining its port/fork of a web engine, so there's nothing to extract to avoid duplication. You would introduce duplication by extracting that subset into its own library. Probably a better approach would be researching a SVG library that then Qt can use (again, by wrapping it). HTH, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] The dark side of QtSvg
Apologies if my mail doesn't have proper carriage returns in pipermail ! (my crappy webmail's fault) Just want to add a third advantage in decoupling QtWebEngine from SVG: 3- it removes duplicated code between QtSvg and QtWebEngine Cheers, Massimo___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] The dark side of QtSvg
Hi everyone,following my last November's email about QtMultimedia (http://lists.qt-project.org/pipermail/development/2014-November/019035.html) (where in 4 months almost all the efforts kept on going to camera support...leaving almost 200 tickets rotting on JIRA) it seems that my lack of luck continues as I found another gray area of the Qt framework. This time the winner is QtSvg. It all started here: https://bugreports.qt.io/browse/QTBUG-44863 The idea is simple: in my opinion a SVG element blends perfectly into the QML world (as in vectorial blend) and in many cases it can be a time saver when needing a custom graphics item. The alternative is using the Canvas element, but it takes much more time and it's not as flexible as SVG.Please note that I am not talking about icons. I am referring to proper UI elements, where one could apply a QML OpacityMask and obtain pretty nice effects in no time. Now on JIRA I've been informed about the component status: http://wiki.qt.io/Qt_Modules_Maturity_Level Qt SVGOverall module state: Deprecated - New maintainer requiredReasoning: SVG Full (as opposed to SVG Tiny) functionality available in Qt WebKit, which should be used instead; we welcome research for a replacement for the SVG-generating code.I found the use webkit statement a big non sense. You surely know that on Windows you need to bundle all the Qt libraries when deploying a Qt application.So basically if I want to write a simple hello world application rendering one single SVG icon, I need to bundle QtWebEngine with all the related ICU stuff.Means a hello world with a delicious size of around 100MB ! Again: non sense. 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 ? 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. Please let me know your views ! Thanks and regards,Massimo___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtSvg
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
Re: [Development] The dark side of QtSvg
On 12/03/2015 16:47, Massimo Callegari wrote: Apologies if my mail doesn't have proper carriage returns in pipermail ! (my crappy webmail's fault) Just want to add a third advantage in decoupling QtWebEngine from SVG: 3- it removes duplicated code between QtSvg and QtWebEngine Just a note. Full svg support requires : - CSS support - animation framework support - scripting support - events support - and probably more… I really don’t know how you’re supposed to do that without a full web engine. SVG Tiny is the way to go if you want something tiny. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtSvg
Guido, Giuseppe, I got your points. It's so sad to read we don't have the resources cause I believe Qt has an enormous potential and I enjoy every day using it (except when I can't get things to work lol) As for me taking care of such matterswellyou don't really want that :) (and I have no time for it anyway) My email was just an idea thrown on the plate, but I understand the technical bits behind it and if Blink is seen as a black box, then it's reasonable to say that the SVG part must stay in there as it is. I did a quick search for SVG rendering libraries and couldn't find any, sorry ! (unless you want to drag Cairo or Skia into Qt...) Regards,Massimo Da: Massimo Callegari massimocalleg...@yahoo.it A: development@qt-project.org development@qt-project.org Inviato: Giovedì 12 Marzo 2015 16:47 Oggetto: The dark side of QtSvg Apologies if my mail doesn't have proper carriage returns in pipermail ! (my crappy webmail's fault) Just want to add a third advantage in decoupling QtWebEngine from SVG: 3- it removes duplicated code between QtSvg and QtWebEngine Cheers, Massimo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt3d examples with qt5.5 crashing (Friedemann Kleint)
When i try to run any of the compiled qt3d application's release version.The application crashes, and this are the error details collected by windows: I don''t see any crashes with MSVC2013 64bit/5.5. Can you please provide a stack trace and the output of the qtdiag tool? Hi, I am sorry but i am not sure how to use the qt diag tool. could you please refer me t the documentation. Just some more hints, i am able to run examples in the qtbase folder like the analog clock,etc that's how i confirmed my build is good. Thanks Regards Arjun ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two source incompatibilities in Qt 5.5 with Clang
On Thursday 12 March 2015 23:22:17 Stephen Kelly wrote: Thiago Macieira wrote: This was intentional and the minor SIC was expected. It only happens if you're calling a static function that only exists for Q_ASSERT -- not many people do that. Oops, nobody told Allen: https://github.com/KDAB/GammaRay/commit/44ac33d970e I think this affects far more code than you seem to think it affects. What *should* Allen do now? Option 1: remove the #ifdef and live with warnings from the compiler that some functions are unused Option 2: option 1 + Q_DECL_UNUSED on the function Option 3: option 1 + force the using with Q_UNUSED or similar. What macro works for multiple versions of Qt? Why should everyone define such a macro themselves in their code? How about contributing it back to qglobal.h? What would it be called? And to bring this full circle, how about swapping the semantic of the old and new macros? I'm sure you considered not making the SIC change and creating a new macro instead. Why did you decide for the SIC? Two main reasons: 1) it improves existing code, since we can get rid of some #ifdefs 2) it allows us avoid CI integration errors because no one compiled in release mode before submitting -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two source incompatibilities in Qt 5.5 with Clang
Thiago Macieira wrote: This was intentional and the minor SIC was expected. It only happens if you're calling a static function that only exists for Q_ASSERT -- not many people do that. Oops, nobody told Allen: https://github.com/KDAB/GammaRay/commit/44ac33d970e I think this affects far more code than you seem to think it affects. What *should* Allen do now? What macro works for multiple versions of Qt? Why should everyone define such a macro themselves in their code? How about contributing it back to qglobal.h? What would it be called? And to bring this full circle, how about swapping the semantic of the old and new macros? I'm sure you considered not making the SIC change and creating a new macro instead. Why did you decide for the SIC? Thanks, Steve. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
