Re: [Interest] Tricks to improve moc performance?
On 12/6/19 7:02 PM, Richard Weickelt wrote: By the way: does anyone know about an implementation that avoids moc runs in a similar way how ccache avoids compile runs ? You mean concatenating header and source files containing a Q_OBJECT macro and feeding moc the result? No - the ideas would be to calculate a hashsum from the files, that have an effect on the moc file and store it together with the moc file in a cache. Then you have a replacement for moc, that compares the hashsum of the cache with the current hashsum and copies the cached moc file if they match - otherwise it is calling moc and copies the result into its cache. Not 100% sure but IIRC this is how ccache works. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Best way to threaded render (images) going forward?
On 11/22/19 2:14 PM, Roland Hughes wrote: There have been many requests over the years to allow QPainter operations outside of the primary thread. In particular for running graphs like heart rate monitors which are just a brick on the screen the user generally cannot interact with. With X11 it is at least possible to draw outside of the paint event - see Qt::WA_PaintOutsidePaintEvent. This type of operation is used in the Qwt plot package for exactly the use case you have mentioned. I'm not 100% sure if it wouldn't be possible to the same in an extra thread. With Qt3 it was even possible to draw in XOR mode, what was at that time the way how rubberbands were implemented. This was an operation where you could erase content without having to repaint from scratch. But this one seems to be gone forever. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 12/6/19 9:48 AM, Giuseppe D'Angelo via Interest wrote: This trick is used in several places in Qt itself (look for "includemoc" in commits). Not only it helps build times but also it produces slightly better code overall. By the way: does anyone know about an implementation that avoids moc runs in a similar way how ccache avoids compile runs ? Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 12/6/19 2:09 AM, Adam Light wrote: Does anyone else have any ideas of how we could change our build to improve moc performance when Windows decides to be "slow"? Something you can try is to include the moc file at the end of your cpp file. This can be done like this: #include "moc_XYZ.cpp" This type of construction is at least supported by qmake. This does not reduce the number of moc runs, but it reduces the number of compiler runs. As a rule of thumb for not too large classes I would expect, that ~50% of the compile time is spent inside the Qt headers and by including the moc file the overall compile time goes down by 33% as the headers need to be processed only once. A side note: the code of Qwt project runs with all Qt versions >= 4.4 and therefore allows to compare the impact of the Qt headers on the compile time. It is some time ago, when I did this, but the differences were significant. IIRC there was a major slowdown around ~4.7 that gets worse during the Qt5 cycle. HTH, Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
On 10/9/19 5:32 PM, Thiago Macieira wrote: All cases are good. It just depends on how much you pay. Today: "If you have already started the development with an open-source version of Qt and wish to move to a commercial license you need to have a written explicit permission from The Qt Company to facilitate this change. The Qt Company reserves the right to grant the permission at its own discretion." ( see https://www.qt.io/faq 3.13 ). Of course this information is useless for someone who wants to change the license - the decision for the LGPL had been made long before. It is about sending the message that you should not do LGPL, if you don't want to be banned later. [Note: I am not an employee of the Qt Company, I don't know their sales strategy today. And you don't care ? Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
Hi Tuukka, This is not about making closed source applications with LGPL licensed Qt, or whatever kind of business is done with such. Of course this thread is also about these options - I'm criticizing the way how the Qt Company tries to prevent users from taking this route. The point is that Qt as a dual licensed technology has some rules related to the commercial license option. I'm not qualified to comment the rules of the commercial options. Similar rule is related to not being ok to develop the solution with free version and then ship under commercial one. We do allow migration from open-source to commercial - of course. The case by case acceptance rule is there to avoid misuse. Not being clear about what cases are good and which are bad is FUD. The intended effect is to intimidate users, that would be totally fine with the LGPL, because they might lose the commercial option in case their situation changes. As long as the Qt company is not willing to be crystal clear on this subject my judgment stands. What comes to using FUD as sales strategy, that is not what we aim for at all. I attended one of the Qt roadshows in Munich - guess it was 2017. If FUD is not the intention of the Qt Company you should talk. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
On 10/8/19 7:13 PM, Ilya Diallo wrote: In the latter case, the rational is (I guess) to prevent a company, say, to work with 20 developers for 3 years on an OSS Qt license, then switch to commercial when it's time to ship the product and the team is reduced to a core maintenance crew. That late switch is unfair to companies that are playing by the rule, ... Please allow me to quote Wikipedia: "The license allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components." The motivation for not using the LGPL - at least on the desktop - is usually, that you want to avoid its obligations, when linking statically. That's all. There is no inner logic behind bundling the commercial license with support contracts and the number of developers using it - beside, that the Qt company makes this connection. I don't have much opinion on this topic - not my business - but I don't agree that "fair/unfair" is a valid category in this context. But I have a strong opinion about using FUD as sales strategy: - intimidation paragraphs - blacklisting projects that follow the rules of the LGPL properly - giving wrong information ( check the video ) about the LGPL Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
On 10/8/19 1:21 AM, Melinda Seifert wrote: You can use commercial if you previously used Open Source but it’s on a case by case basis and you need to get approval from the Qt company. Like you need to get approval from the Qt company when not having been Open Source before - it is the basic right of any seller not to sell. But your statement implies, that the Qt Company is blacklisting users because of contributing to Open Source projects. Am I already blacklisted because of offering code under an Open Source license ? How does this all fit to the Qt project, that is in parts based on contributions from Open Source developers. Am I invited to contribute to the code base, while not being allowed to buy my own contribution afterwards ? Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
On 10/6/19 12:03 PM, Giuseppe D'Angelo via Interest wrote: Hey, I linked it two emails ago :-) Ah yes, sorry. My response was initially more explicit about FUD, before I decided, that it is not worth the effort. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
On 10/5/19 7:57 PM, Giuseppe D'Angelo via Interest wrote: Anyhow: please direct these comments to your Qt sales representative; this is NOT a sales mailing list (in other words, chances are high that no one from sales ever reads these messages). Asking sales people if you don't need to buy a commercial license - don't believe, that this a good advice. Maybe this presentation helps: https://www.youtube.com/watch?v=bwTlCBbB3RY Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
On 9/30/19 4:43 PM, Thiago Macieira wrote: It's not advisable to use nested event loops. It is not the first time that you gave this warning, but something like QDialog::exec is simply too handy for GUI development. Of course there are known side effects, but IMHO it should be the job of a GUI framework to solve them as good as possible to make the life of the application programming easier. And yes: issues like this one ( https://bugreports.qt.io/browse/QTBUG-73432 ) belong to the category of problems that should not exist. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] [SPAM] Re: QPainter drawLine zValue?
Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/25/19 10:58 PM, André Pönitz wrote: > Is drawing the grid so expensive that you can't simply do that on > each update of the "lower levels"? I don't know about the specific situation of Israel, but a grid is often made of dotted lines and in oscilloscope alike situations it is not unlikely to be more expensive, than drawing the curve - if it is a solid line of not too many points. [...] Content analysis details: (4.5 points, 4.0 required) pts rule name description -- -- 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4910] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.4 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla --- Begin Message --- On 9/25/19 10:58 PM, André Pönitz wrote: Is drawing the grid so expensive that you can't simply do that on each update of the "lower levels"? I don't know about the specific situation of Israel, but a grid is often made of dotted lines and in oscilloscope alike situations it is not unlikely to be more expensive, than drawing the curve - if it is a solid line of not too many points. So yes having to redraw the grid with each frame can be a bottleneck for plot widgets. I did not check the code of the QGraphicsView framework since quite some time, but IIRC correctly it "renders" before clipping - like Qt does in general. So in situations where you zoom in deep and the coordinates of some lines reach far out the visible area it can become a significant factor. I remember that in the early Qt4 days I was running into situations, where rendering a grid took minutes(!) for a zoomed-in polar plot ( https://qwtpolar.sourceforge.io/ ). The time was spent on calculating millions of dots that were far outside the visible area. It might be more than 10 years ago since I suggested adding a ClipPolygon flag to the QPainter renderHints, without having much success. This is why Qwt always manually clips before calling QPainter methods. Uwe --- End Message --- ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Mailing list issues [ was : QML and sensitive data ]
On 9/10/19 5:42 PM, Giuseppe D'Angelo via Interest wrote: https://bugreports.qt.io/browse/QTQAINFRA-3072 Looks like something has changed - at least my previous mail was not marked as spam anymore. Instead I received an email with this information: "You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at interest-ow...@qt-project.org." Not sure about this one as my posting obviously made it to the list. Uwe PS: I'm also behind gmane ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML and sensitive data
On 9/10/19 3:08 PM, Alexander Ivash wrote: Under what conditions? I mentioned that Quick Controls 2 is a must to make behaviour more deterministic. F.e QTextInput ( QC2 has nothing to with it ) is completly done in C++ and if you are willing to include private headers ( not private in the meaning of C++ ) you can also use it from C++. So you could implement a small C++ wrapper item around QTextInput that hides the text property of the API and exposes the part of the API you need in QML. Then it doesn't matter how secure/insecure the QML runtime environment actually is as it never sees the text. Uwe PS: could someone in charge of this mailinglist please have a look at the spam filter ? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] [SPAM] Re: QML and sensitive data
Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/5/19 6:29 PM, Giuseppe D'Angelo via Interest wrote: > A QLineEdit is just as secure as an equivalent QML control (which means, > it's not secure). Well, with QML you always add its runtime environment to the bill. [...] Content analysis details: (4.1 points, 4.0 required) pts rule name description -- -- 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.0 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla --- Begin Message --- On 9/5/19 6:29 PM, Giuseppe D'Angelo via Interest wrote: A QLineEdit is just as secure as an equivalent QML control (which means, it's not secure). Well, with QML you always add its runtime environment to the bill. Uwe --- End Message --- ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] [SPAM] Re: QML and sensitive data
Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 9/5/19 5:16 PM, Alexander Ivash wrote: > Unless of course your suggestion is really about injecting my custom > QQuickItem into scene graph purely from C++ side, without > instantiating it from QML. But as I understand in this case I also > have to implement all the event-handling & focus support from scratch. [...] Content analysis details: (4.1 points, 4.0 required) pts rule name description -- -- 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4992] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 0.0 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS 2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla --- Begin Message --- On 9/5/19 5:16 PM, Alexander Ivash wrote: Unless of course your suggestion is really about injecting my custom QQuickItem into scene graph purely from C++ side, without instantiating it from QML. But as I understand in this case I also have to implement all the event-handling & focus support from scratch. No this is done inside of QQuickItem/QQuickWindow and works out of the box when instantiating them from C++. Uwe --- End Message --- ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Track global mouse position in QML
On 3/21/19 2:36 PM, René Hansen wrote: And it's not all too bad, but if anyone can tell me of a more dogmatic QtQuick based approach, please let me know. Qt/Quick applications are always a combination of C++ and QML and making use of the C++ part is absolutely not bad. If something is wrong, than it is that Qt/Quick does not offer that option for many situations, where the declarative approach is not optimal. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
On Fri, 22 Feb 2019 22:27:49 +1300, Christian Gagneraud wrote: > If you do not want to support qreal=float anymore, please do not allow > ./configure to make that choice and maybe get rid of qreal typedef, > and delete qreal from Qt6 API while you're at it. Actually there are several versions of Qt5 that do not even compile when setting qreal=float. After reporting such a bug the fix did not even go into the relevant LTS version ( Qt 5.9 at that time ). Obviously building with qreal=float seems not to be covered by the Qt tests and also does not seem to be seen as import by the development. But the whole concept of qreal is questionable as it implies, that how to store values is always related to the hardware architecture and/or rendering. For a library like Qwt this is not the case and and algos like f.e spline interpolation suffer, when using QPointF an friends. So yes, please remove the qreal=float option with Qt6. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Segmentation fault on exiting Qt event loop
On Thu, 20 Dec 2018 20:27:30 -0200, Thiago Macieira wrote: > I understand you're working with 4.8. I don't care. I participated in one of the marketing road shows of the Qt company in Munich/2017: one of the speakers asked the audience which Qt version they are using. I don't have exact numbers, but to me it looked like about 25-33% of the fingers were for Qt4. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt API annoyances: where to log/discuss?
On Mon, 05 Nov 2018 14:41:11 +0100, Giuseppe D'Angelo via Interest wrote: > Didn't you hear from Microsoft? They went from being the > slowest adopter to the fastest -- to this date, MSVC 2017.7 is the > _only_ C++ compiler that supports the entirety of C++17! That indeed > shows their commitment! Hm, it's only a couple of days ago that I had this one: https://github.com/uwerat/qskinny/issues/65 The related quote of this bug report is: > The problem is hit by macros like: > #define QSK_STATES( ... ) static const QskAspect::State VA_ARGS; > from QskAspects.h. > When building as a shared library, the static member variables defined > by the macro on exported classes are not all exported, only the first > one. The bug has been known for over 17 (!) years and is present in all > modern MSVC compilers (see https://jeffpar.github.io/kbarchive/kb/127/ Q127900/) So what are my options: waiting 17 more years or writing this totally stupid workaround you find at the end of: https://github.com/uwerat/ qskinny/blob/master/src/common/QskAspect.h ? My other project ( http://qwt.sourceforge.net/ ) supports all versions of Qt >= 4.4 from the same code base - for tons of build and runtime environments. Of course I have to pay with limiting myself in what features of C++ or Qt I'm using - but this is what needs to be done if you take the LTS idea seriously. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Porting Qt to our RTOS
Hi Guiseppe, > (The topic is still "how to port Qt to another platform".) It is in the nature of discussions, that they might change direction - like it happened with the AGILE side track. > (Yes, I 100% agree that QtQuick could be modularized much further, e.g. > drop its dependency from QtQml altogether, expose C++ APIs for the > QtQuick items, offer ready-made "rich" scene graph items, have clear and > explicit support for more than just OpenGL. A good summary of my point of view - even if the last one was not on my list so far and I would add "being more careful with resources". > But I don't want to start this conversation in this thread, let's have > it in the right places.). You might have access to these "right places", public forums is all what I have. Actually we already made a presentation at the QtCon 2016 ( https:// conf.qtcon.org/en/qtcon/public/events/428.html ) without seeing much of an effect. Showing an implementation is probably my best option to fuel the discussion. If you are trying to improve things from the inside and you are interested in experiences on our journey - don't hesitate to contact me. ciao, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Porting Qt to our RTOS
On Thu, 27 Sep 2018 18:03:55 +0200, Giuseppe D'Angelo via Interest wrote: > This is another blatant false statement, because you can port just the > parts of Qt that you need, and even those can be further trimmed down > using the feature system. (That's actually how you would do a port in > the first place.) While I agree with almost everything of your posting I don't do with this one: Qt/Quick has gone into the direction of Web technologies and you can't change this by simply disabling some features. This goes much deeper and has to do with the philosophy/mindset behind the product. Have a look at https://www.qt.io/qt-vs-html-5-strengths-and-weaknesses. There is nothing wrong with these articles, but "four to eight times lower RAM requirements" than a beast like HTML5 does not put Qt into a different category. Actually we were so disappointed ( learning it the hard way with a project using QML ) about the direction Qt has taken, that we finally started our own framework on top of ~ QuickItem/QQuickWindow ( https:// github.com/uwerat/qskinny ). Uwe PS: would be nice to have a feature to get rid of all QML related members/ interfaces of QQuickItem/QQuickWindow ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
On Thu, 15 Mar 2018 14:17:00 +, Shawn Rutledge wrote: > That sounds interesting. What format do you want to precompile them to? Well, as all we need is to restore the members of a class exactly, like they have been in memory, before we wrote them to disk, there should be a way to do this without having to write a parser. But this is all I have to offer so far. The idea of using mmap exists since the very beginning of our project, but as we already have no performance issues with how we load the images today it has a low priority. The format we are using today can be found here: https://github.com/ uwerat/qskinny/blob/master/src/graphic/QskGraphicIO.cpp. To be complete I also implemented embedded QImage/QPixmap, but in reality we only have QPainterPath vector data and state change informations - both stored stored in a QVector. Beside that there is some Meta Data ( supporting proper layouting of scaled vector graphics ) - so all in all it should be doable. -- Unfortunately Qt development never really saw much potential in using vector graphic formats for writing user interfaces. It was never a first class citizen for widgets, but with Qt/Quick the idea totally got lost, as the one-window-always-in-fullscreen use case has become dominant. I remember, that there once was a page ( maybe it is still there, but I can't find it ) in the Qt documentation, that explicitly mentioned the combination of Layouts and SVG as solution for writing scalable user interfaces. But IIRC SVGs do not even exist in the complete Qt/Quick API and the thin layer ( a.k.a Qt/Quick Layouts ) on top of QGridLayoutEngine does not even forward the available features ( f.e dynamic constraints ) of this powerful class to the user. If you like you can compare it with the layout system I have implemented on top of the same engine: https://github.com/uwerat/qskinny/tree/master/ src/layouts. It is more or less the same, what the widget layouts offer + a couple of extras I always missed in the past when using them. ciao, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
On Thu, 15 Mar 2018 14:26:41 +, Shawn Rutledge wrote: >> I see that Uwe has pointed out a performance issue which can happen >> because of multiple renderings due to size changes. Is that it? Or are >> there other reasons behind preferring PNG icons over SVG? > > I think it’s mainly that SVG rendering is slow because it’s done in > software, ... In our use case we have more of 1000 different SVGs - all of them small and simple - the type of icons you usually have on buttons. For those I can't confirm, having any performance problems with rendering them. The problems we noticed are related to the classes in Qt/Quick core: a) QQuickImage The caching strategy of QQuickImage, does not take into count, that scalable graphic formats do not offer a reasonable source size and that it doesn't make sense to render anything before the layout system has calculated the final size for the image. But this one is not a serious problem as long as you are aware that QQuickImage is for raster data formats and for all sort of vector base images better use QQuickPaintedItem. b) QQuickItem QQuickItem and friends are not careful about avoiding geometryChanged notifications. Binding sizes results in setting width/height in 2 separate call resulting in 2 geometryChange events. Even worse: QQuickItem does not even have a public API where you can set its geometry in one call. Without using the private APIs you have to set size and position in 2 calls - always resulting in 2 geometryChanged notifications. And here we are talking of a public C++ API - the one for the base class of all Qt/Quick Items ! c) Layouting With QWidgets layout update requests are indicated by an event ( LayoutRequest ) to the parent and usually processed asynchronously. This way several layout requests can be collected and lead to one calculation only. When binding implicitSize properties this is not the case and leads to several updates - often irrelevant as only the last one is important. In QSkinny I implemented a layout system, that is similar to what QWidgets does. Layout Requests are not processed before updatePolish. Something I have not yet fixed in our environment is, that layouting always has to be done in top/down order. That requires sorting the items in the to-be-polished list. I would expect to see some nice improvements in our ( already almost non existing ) startup time. d) Once more QQuickImage From what I written above my conclusion is, that no class should do any expensive operation in geometryChanged. -- Finally an unrelated comment on QQuickItem::geometryChanged, QQuickItem::itemChange and QQuickItemChangeListener: why do those APIs exist at all ? Sending events is a well established mechanism that exists since ever and event filtering is public, available and more powerful ( swallow events ) than those listeners. ciao, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
On Wed, 07 Mar 2018 20:55:03 +0100, Jason H wrote: > How is QPicture not appropriate for SVG? At the time, when Qt changed its APIs from integers to doubles ( Qt 4 ) QPicture::boundingRect() was forgotten, what makes layouting of scaled pictures too inaccurate. Another important detail are non cosmetic pens. You need to know about them as they might grow outside the bounding rectangle. Beyond that QPicture stores painter commands in a platform-independent format, what makes it less performant and the file sizes are larger. In the end ( not yet implemented ) I want to mmap my precompiled SVGs into memory. Then, copying all precompiled SVGs at boot time into a RAM drive and you have almost zero overhead for IO. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
Hi Shawn, > It should also be considered a bug IMO. The only obvious part of the whole disaster that IMO qualifies as a "bug" is the fact, that binding a size ends up in 2 calls - but AFAIK this is not specific to QQuickImage. Maybe one could say, that QQuickImage shouldn't do any updates before updatePolish, but this would be the opposite of the overall "as soon as much as possible" caching strategy implemented in Qt/Quick. I once derived a small class from QQuickImage ( https://github.com/uwerat/ qskinny/blob/master/playground/images/Image.h ), to avoid some of these issues, but I never used it as we later decided to go with writing our own code for displaying images. This code uses a class that is called QskGraphic, what in the end is a record/replay paint device - similar to QPicture, but tailored for scalable vector graphics. This way we can precompile our SVGs at build time into QPainter commands and store them into as something we call a qvg file. As we have small iconic graphics only we can load those files from disk in updatePolish and replay the commands in updatePaintNode without needing any cache at all. ( If you are interested: the qvgviewer example in qskinny uses it. ) Maybe a side node: IIRC creating a QImage and translating it into a FBO seems to be faster - when having simple icons - than creating the FBO directly. Looks like the tesselation done inside the OpenGL paint engine is as expensive as what the raster paint engine has to do for pixeling down the RGB values. ( But this is something I noticed 2 year ago and might have changed in the meantime ? ) Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to render small Images decently on non retina displays with QtQuick?
On Tue, 06 Mar 2018 16:55:23 +, Nuno Santos wrote: > I just had to add it to resources and pass it to the image element. Using Image works, but its implementation is far from being optimal in combination with SVGs. For small applications with only few SVGs this might be no problem, but when having many of them it is often a serious performance killer for the startup time. In short: the overall strategy of Qt/Quick is to cache as much and as early as possible - in case of the Image/SVG too early: it loads and renders the SVG according to its sourceSize as soon as it sees the URL. But in case of scalable graphic formats the sourceSize ( usually the viewBox of the SVG ) does only provide the aspect ratio, but not the size that is needed to be rendered. This is usually solved by binding the sourceSize to the size being calculated from the layout code, but ... When having a layout system that relies on binding the implicit sizes the geometry of each item changes several times until it reaches its final size - each time re-rendering the SVG. ( In fact it gets re-rendered twice each time, because binding a size leads to separate updates of width and height ) I remember an application, where SVGs have been re-rendered more than 10 times before they had their final size. This application had more than 1000 SVGs and - even if only few of them were visible in the beginning the caching strategy of Qt/QQuickImage lead to more than 1 image re- rendering operations. So I would recommend for every application having many SVGs: never ever use Image and always go with QQuickPaintedItem. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qml or qwidget
On Thu, 22 Feb 2018 13:54:39 +, Jérôme Godbout wrote: > I for one would go Qml, since it's the new thing with more development > on it, which seem more future proof. On the developer mailing list it has been recently announced, that Quick Controls 1 is going into deprecated mode. So at least for desktop applications, widgets seems to be the only solution having a future. HTH, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using private QtQuick APIs
On Wed, 17 Jan 2018 11:59:41 -0800, Thiago Macieira wrote: > True. Maybe it has never occurred to them that the API would be needed. > You can help make it happen by adding this API yourself too. In the case of QSkinny we are not talking about some APIs it is a fundamentally different philosophy about what Qt/Quick is supposed to be. And as long as C++ has not been agreed to be an officially supported API to implemented Qt/Quick applications I don't have many arguments for my patches. IMHO the only way to add something new to the discussion is to offer an implementation, that makes arguments quantifiable. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using private QtQuick APIs
On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > It is just sharing code. The important difference is that both modules > are developed at the same time and released at the same time, by the > same team. Yes of course, but my project is developed at a different time, released at a different time by a different team. That makes things more difficult, but the only one who can solve the problem is the Qt development by making the necessary APIs official. Please don't blame me for using the same level of APIs that are used by a module like QQuickControls 2, when I have to solve a similar type of problems. > Import it into the Qt Project. What exactly is the Qt Project in your opinion ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using private QtQuick APIs
On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote: > Why do you need private headers in the first place? For the same reason, why a module like QuickControls 2 is using private headers of Quick Core. The qskinny project is about creating a C++ framework ( QML is only optional ) with an API in the spirit of Qt/Widgets, but using the modern graphic stack of Qt/Quick. It needs way less memory and we don't have any startup performance issues - categories, where we failed with our previous version of the product using Qt/Quick in the standard way. The code you can see on github is coming from a project in the automotive industry, that is currently under development. Unfortunately I can only release a subset of our code under an Open Source License and I didn't have the time yet to pimp up the provided examples and skins to be more impressive. Maybe once our product has been introduced to the public I can give a better demonstration of what we achieved with this alternative approach. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Using private QtQuick APIs
On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote:
This how I do it ( see https://github.com/uwerat/qskinny ):
QT += quick quick-private
CONFIG += no_private_qt_headers_warning
To get rid of warnings from Qt headers, when doing pedantic checks I also
have the following lines:
linux {
QMAKE_CXXFLAGS += \
-isystem $$[QT_INSTALL_HEADERS] \
-isystem $$[QT_INSTALL_HEADERS]/QtCore \
-isystem $$[QT_INSTALL_HEADERS]/QtGui \
-isystem $$[QT_INSTALL_HEADERS]/QtGui/$$[QT_VERSION]/QtGui \
-isystem $$[QT_INSTALL_HEADERS]/QtQuick \
-isystem $$[QT_INSTALL_HEADERS]/QtQuick/$$[QT_VERSION]/QtQuick \
-isystem $$[QT_INSTALL_HEADERS]/QtQml \
-isystem $$[QT_INSTALL_HEADERS]/QtQml/$$[QT_VERSION]/QtQml
}
HTH,
Uwe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support
On Fri, 20 Oct 2017 09:14:09 +0200, Vlad Stelmahovsky wrote: > I've created much more complex apps using QtQuick 1 on HW much weaker > than RPi2 (Symbian phones) w/o such laggin as in this simple calc > example. Obviously, there something wrong with code and/or system setup A simple push button is made of ( IIRC ) more than 30 QObjects with Quick Controls 1, the version of Quick Controls 2 with less features still consists of 7 QObjects. Each stop of a gradient is made as QObject for no other reason, than to make it accessible from QML. I could continue with almost every control, but let's summarize it this way: Qt/Quick has not been designed to be a lightweight technology. But I never heard anyone complaining about the scene graph ! I would have some critics myself about the C++ part on top, but beside its strategy, about when to create the scene graph nodes, it does not prevent you from having an efficient application. The problems start with the fact that the API of most of those C++ classes are designed to serve the QML use case, making QML mandatory. Finally QML on top does not contribute to performance in any positive way - it is about convenience only. In the best case ( small applications ) you won't notice the startup performance penalties, but you definitely always have to pay with a very significant memory footprint. -- IMHO criticizing having to use QML is very valid and it can't be answered because of having a good performance from the scene graph. And to be clear: it is not QML to blame - it is the fact that you have to use it, when you are in need for a modern graphic stack. And this is exactly why I'm trying to create the QSkinny alternative - one where the decision for the graphic stack is independent from the decision about the programming language you prefer to write your application code with. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support
On Thu, 19 Oct 2017 08:06:26 -0500, Roland Hughes wrote: > 1) It's QML ... In case you prefer using the Qt/Quick graphic stack without QML you might be interested in what I'm working on: https://github.com/uwerat/qskinny. In fact the heaviness of Qt/Quick is not only QML related and I had/have to reimplement almost everything of the Qt/Quick C++ layer - beside of the scene graph and QQuickItem/QQuickWindow. The project is far from being complete, documentation has not been done and the quality of the examples is pretty poor. But I hope I will have something in a few months, that is good enough to show its potential and I can decide if there is enough interest to continue. Uwe PS: the project is driven by a commercial application and on github you can see only the subset I'm allowed to release. We have reached an initial version ( about ~50 different pages full of content ) and the startup time feels like 'ls' in the terminal. ( the previous generation of the product - less pages, but with QML - needs seconds ). ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Which "Widget" technology to use when starting a new desktop app
On Thu, 05 Jan 2017 16:58:00 -0500, Mike Jackson wrote: > After reviewing the responses and doing some more research online we > decided to stick with the traditional QWidgets IMO the only reasonable choice for a classic desktop application ... > ... for our desktop app but > get away from the QGraphics* classes and replace that older code with > code based on QOpenGlWidget so we can get accelerated 2D rendering. QGraphics* can also run over the OpenGL paint engine. So as long as you need QPainter dropping QGraphics* buys you nothing - beside you are not happy with the quality of the implementation of this framework. And going away from QPainter means no more PDF export ! Concerning mixed mode ( QOpenGL + Raster ) applications. I once tried it an soon ran into: https://bugreports.qt.io/browse/QTBUG-50916 I don't want to say that doing pure OpenGL is the wrong decision, but one, that needs to be made carefully. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What don't you like about Qt?
On Sat, 17 Sep 2016 21:20:43 +0100, Sérgio Martins wrote: > Please state your top ones, even if it was already stated by someone > else, so we have an idea about which ones matter more. a) C++ ( far beyond everything else ) The 2 language approach is a pain. In our application we have thousands of totally pointless lines of code only for bridging between C++ libs and QML. Having a compact syntax - for code, that would be trivial in C++ as well - IMO simply doesn't justify this extra work. Beside that QML has bad instantiation times for large projects and its concept of item composition makes applications heavy. More than 30 QObjects for a button ( Quick Control 1 ) says it all. My experience with working on C++ controls with an optional QML API shows how surprisingly easy it would have been to have both APIs. Too sad, that with Qt Quick Control 2 this chance has been missed. b) Vector graphics Qt has no strategy for handling vector graphics - neither Widgets nor Qt Quick. Not having full featured layout classes ( dynamic constraints etc ) are another problem, when trying to implement user interfaces, that need to work on different devices. c) Compatibility policies The compatibility policy of Qt makes it impossible to fix design problems of X.0 versions. This leads to adding balconies instead of getting the foundations stable. F.e. have a look at the font/locale propagation. It obviously has been identified as being forgotten and has been added to QQuickControl ( Quick controls 2 ) - instead of QQuickItem. In consequence Qt Quick Control 2 does not play together with controls of other libs ( and v.v ). e) X11 paint engine Being the maintainer of the Qwt project I'm missing a hardware accelerated paint engine, that just works. -- In general I would like to see Qt being more focused on what it is good at - for me this is cross platform desktop development ( Qt/Widgets ) and Qt Embedded projects - not Android/iOS. A a long term goal I would also like to see desktop and embedded technologies being reunited. Even if user interfaces on desktop and for embedded are ( and probably will stay ) different I don't see why writing them needs to be totally different. My 2 cents, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Relationship between a QEventLoop and QCoreApplication::exec().
On Wed, 03 Aug 2016 13:41:51 -0700, Thiago Macieira wrote:
> It's still a source of errors because the nesting counter can be
> incremented in different ways, depending on what triggered the event. So
> the recommendation remains: avoid nesting like the plague.
void doIt()
{
...
int option = askForOption();
...
if ( doYouReallyWantTo( option ) )
{
...
}
}
Having to write this code without nested loops ( f.e. QDialog::exec() )
leads to 3 method ...
- before askForOption
- between askForOption and doYouReallyWantTo
- after doYouReallyWantTo
... where you always have the problem to transfer the variables from the
stack ( here option ).
Once your code ends up in sequences of between-GUI-interactions methods
you will have way more problems, than what nested event loops might be.
So yes nested loops might be a problem, but not using them is IMHO the
wrong consequence.
Uwe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating Qt Quick controls from C++
On Tue, 19 Jul 2016 15:45:44 +0200, Jean-Michaël Celerier wrote: > Is there some code somewhere ? Sure on my disk ;) Being serious: the code is supposed to be available under an Open Source License, but it needs to have an initial level of quality first. And there is still a long way to go. But even then - don't expect to find a set of controls, that is nearly as feature rich as Quick Controls 1, it won't not even be close to Quick Controls 2. But of course it could be a starting point to get there. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating Qt Quick controls from C++
On Tue, 19 Jul 2016 11:10:26 +0200, Benjamin TERRIER wrote: > * you can't even create ... As I'm currently working on a library offering Quick Controls with an C++ API ( having a QML API as well ) I already have some experience in what it means. The very first thing you will notice is that the Quick classes available as private or public headers from the Qt Quick core module have never been consequently designed for the C++ use case. Next you will notice, that this module does not follow concepts you would expect, when being used to widgets. This starts with using homebrew notification hooks instead of events, continues with having 2 different object hierarchies and ends with being inconsistent with QGuiApplication. Next you will see, that you don't have a powerful layout system. The existing implementation for QML builds an API using attached properties. But this is only a frontend for QGridLayoutEngine and it is not that much work to write another one, that offers a C++ API ( my version is around 1000 lines of code for Grid/Box/Stack layouts ), that can be used like the QLayout classes. So there is a lot of initial work to be done before you are in the position to start with implementing Quick Controls in C++. But once you have it you can easily outperform the existing QML implementations in terms of instantiation times and memory footprint - not to mention that you are free to decide to have a pure C++ code base. More details about my experiment will be presented at: https:// conf.qtcon.org/en/qtcon/public/events/428 Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Utilizing the GPU, how to start?
On Fri, 08 Jul 2016 18:51:47 +0200, Giuseppe D'Angelo wrote: > This seems _very_ interesting and worth researching, are you going to > share some results during the QtCon session you mentioned earlier? When time has come I will release my package under a Open Source License, but I first need to reach a certain level of features and quality. But at least Andrew ( when I can't make it myself ) will have the code with him. We have not yet decided which details we like to present, but to be honest I wouldn't consider details of this vertex list generation being the most interesting aspect. The features are quite obvious, the implementation is in line with the design of the other QSG classes ( very similar to what you find in QSGRectangleNode ) - nothing specific sexy, it's simply: someone has to do it. An approach I would prefer to what I have today is some sort of paint engine. Something you could feed - at least - with a painter path - that spits out vertex lists. Maybe more interesting from my point of view is code, that is currently implemented inside of QQuick classes, but could be moved to more lightweight QSG classes. F.e creating texture nodes with QPainter or the node tree generation for texts ( currently I'm needs a static QQuickText item as helper ). -- But when it comes to the QQuick classes my way of thinking is often controversial to the existing code: I would like to have the C++ class APIs more compliant with what I consider being "well established Qt standards". The Quick framework itself could be smarter: stuff like not calling updatePaintNode for invisible items or delaying expensive operations until updatePolish ( where the layout is stable ) are obvious examples for how to improve the overall performance. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Utilizing the GPU, how to start?
On Fri, 08 Jul 2016 10:19:14 +0100, Giuseppe D'Angelo wrote: > I think the question was more about measuring CPU and GPU performance > than memory. Yes, but as we don't have any problems with the performance of the render engine we never benchmarked it. And our problem - the time spent for creating the quick item subtree - does not depend on the GPU. What I did is to check a couple of animations, we need for another product comparing Widgets, Quick and OpenGLWidget. All options have been fast enough for a pleasing result, but the widget version - no surprise - needs for the majority of them more CPU load. ( Unfortunately I had to rule out the QOpenGL path because of certain bugs ) > This point about memory usage however is extremely valid, and amongst > other things shows that allowing styling in QML itself is hard if not > impossible due to the QObject bloat (and privileging composition over > vertical integration for "simple" UI elements makes you pay a lot for > it.) This is exactly my point - beside, that I believe ( hard to produce numbers ), that the consequences of this "bloat" are also significant for the overall performance. That's why I'm trying to do my controls with scene graph node composition - as much as possible. But this is no fun either as the feature set offered by the QSG-nodes ( public or private ) is surprisingly limited and I had to implement very basic stuff, like creating vertex lists for gradients ( only vertical linear gradients are there ), raised/ sunken borders etc. Cheers, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Utilizing the GPU, how to start?
On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote: > Interesting choice. I would have done the exact opposite. Application > logic in C++ and UI declaration in QML. Well this is actually not a choice - we did it in QML and ended up with a disappointing performance, because of QML. And we did it exactly like you recommend - we simply have a lot of UI. > Declaring fluid animated UIs in > QML is a joy, writing animations in C++ is not so. In case of the animations QML offers a compact syntax to access a library of C++ classes mostly setting up a QPropertyAnimation. Using similar ( or even the same ) classes from C++ is not uncomfortable either. My experience so far is, that using Qt/Quick from C++ does not have to be that different from writing a widget application: creating controls, setting up signal/slot connections and arranging them into layouts. The graphic stack behind is irrelevant for the vast majority of the application code and I disagree with Thiago, that it is not possible to implement controls with a similar API as their widget counterparts. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Utilizing the GPU, how to start?
On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote: > So what you want isn't QWidget with OpenGL support. We've proven it > won't work. What you want is a powerful, Scene Graph-based set of > widgets with native look and feel (that is Qt Quick Controls). > > You're probably also asking for a C++ API instead of a QML one. And this is exactly what I'm currently trying to do - creating a set of Quick controls offering full featured C++ and QML APIs. Our main motivation is the well known instantiation problem of QML, that is totally dominating the overall performance of our user interface. As most of our QML code is application code, having a C++ API for the controls is mandatory to significantly limit the amount of QML. We will present some results from this attempt at the QtCon: https:// conf.qtcon.org/en/qtcon/public/events/428 Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Performance of QGraphics[View Scene] changes with zoom
On Wed, 18 May 2016 15:57:04 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Now if I add a lot of straight lines (QGraphicsLineItem instances) > performance (number of movements seen on screen per second) varies > according the zoom. If I zoom in I get to a point in which everything is > too slow. Qt does the polygon clipping very late, so a huge amount of pointless caclulations is going on before it detects that it is not needed. IIRC the Graphics View framework isn't any better than QPainter - but I havn't checked the code quite some time. If this is still the case you need to implement your own polygon clipping before entering Qt rendering code. At least this is what I do it in the Qwt project ( qwt.sf.net ). If you need an implementation for polygon clipping you find something there too: see https://sourceforge.net/p/qwt/code/HEAD/tree/trunk/qwt/src/ qwt_clipper.cpp HTH, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Stacking QOpenGLWidgets
Hi all, I'm trying to create an application with several QOpenGLWidgets ( no regular QWidgets involved ), where some of them are on top of others. My first results are promising, but I couldn't find out how to enable a transparent background for the widgets on top. I would like to have a similar effect as with setAutoFillBackground( false ) - seeing pixels from the widget below. But I also couldn't get setAutoFillBackground(true) working and had to fill widgets myself in paintGL(). As it is explicitly mentioned in the docs ( http://doc.qt.io/qt-5/qopenglwidget.html ) I guess it is something wrong on my side. When having a regular widget on top of a QOpenGLWidget everything works like expected, but with QOpenGLWidget the background is always black. Has someone ever tried this or knows if it is possible to set up QOpenGLWidget not drawing a background at all ? I'm using the Qt 5.6 beta from December. Thanks a lot, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On Fri, 08 Nov 2013 11:47:36 +0100, Bo Thorsen wrote: With a 7 year old board, this is what you can expect to start hitting. It's so old, that you just can't expect brand new software to run on it. The strategy of Qt5 is to introduce a new graphic stack but also to keep the old old one alive. Of course I can't expect to run something new on an outdated board, but it doesn't necessarily has to mean regression when using the old graphic stack. Almost all embedded applications with some history are running QWS/ widgets where is no comparable replacement in Qt5 ( I know nobody wants to work on QWS code for understandable reasons ). In fact this is the point where our Qt5 consideration failed - sorry for my ignorance about the no-opengl flag, but we never got so far. -- If someone is interested: we are also writing a new application on a brand new type of hardware - so no legacy issues here: Our main problem is/was, that our test department is using a VNC based test tool and beside X11 there is no easy way to get it running with Qt5 ( Qt4/QWS supports it out of the box ). For a QML application Qt5/X11 is o.k., but when using widgets only the combination Qt4/X11 offers hardware acceleration. Finally we decided to go with Qt5/X11 ( hoping for some VNC support in Wayland later ) - and for no strong reason with QML. I don't think you will see a Qt 4.9. I might be wrong, but I doubt it. What you could do instead is to start a backport library for 4.8 where you put stuff like the JSON class in. Such a backport already exists - that's why I mentioned it. Being the maintainer of the Qwt project I'm in contact with many developers of Qt applications and as far as I can see almost nobody did a Qt5 migration - even if it would be pretty easy for average desktop application code. Maybe you have a good explanation for this ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] What for does qt5gui need OpenGL?
On Wed, 06 Nov 2013 08:03:47 -0800, Thiago Macieira wrote: Shouldn't they be in Qt5OpenGL.dll? No, they are where they were supposed to be. That's by design. With some nasty consequences for us users: Our applications run on several pieces of embedded hardware, where one of them had been designed 7 years ago with a graphic chip, where only OpenGL ES 1.1 is supported. This board needs to be supported and updated for many, many years - no way to exchange it by something more recent. Even if we don't need OpenGL ( using widgets only ) we are stuck with Qt 4 forever, because Qt5 has this unnecessary OpenGL dependency. So far this had been no big problem - Qt4 is pretty fine - and there are some backports of new Qt5 features ( by the way: it would be nice to add the json classes to Qt 4.9 ), but sooner or later this will become an issue. There are reasons why Qt 4.8 is still the platform, where most users are, and one of them is because of such a design decision. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Semi-OT: Was Nokia net good or bad for Qt?
On Fri, 27 Sep 2013 11:20:24 -0700, Thiago Macieira wrote: The Qt development team grew considerably during the Nokia time (which is a good thing of that time too), faster than the commercial business. The insane growth of the Qt development happened before - in the TrollTech days. From the outside it looked like the owner had made the decision to retire and sell the company - a situation, where size is more important than being profitable. Finally Nokia was the one who bought it - otherwise it would have been someone else. IMO the business strategy of Digia today is better for Qt than Nokia was, but Nokia was better than many other options I was afraid of. We could have completely refactored the widgets and tried to make them work on all platforms again. The consequences of that would be: 1) a much-delayed Qt 5.0 2) a source-incompatible set of classes (I have to deal with 2 different platforms) 3) a LOT of behaviour incompatibility, plus 4 years worth of fixing regressions (remember Qt 3 to 4, anyone?) Consider what the majority of the code of a user interface looks like: creating controls organizing them in layouts and setting up signal/slot connections. I don't see why this has to be different because of the scene graph. If you would have released Qt 4.x versions with all other changes and a much delayed Qt 5 ( = 2014 ) with a new graphics system ( offering a migration path better than a complete rewrite in QML ) - what would have been the consequence for today: On the desktop none, as almost everyone sticks to the old system. On smartphones/tablets - not sure, Qt is not available on the relevant platforms yet. I bet there are not too many projects - outside the now dead Nokia ecosystem - where having the scene graph one year earlier really had mattered. And this is where I believe that the ownership of Nokia led into a less optimal situation. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Semi-OT: Was Nokia net good or bad for Qt?
On Thu, 26 Sep 2013 14:13:33 -0400, K. Frank wrote: Did this detour (for lack of a better word) end up being helpful? Nokia was not interested in the desktop and the previous user base. IMHO this had 3 effects: a) LGPL Good and bad: the business case of selling support licenses is dead ( almost all Qt developers are payed ), what is IMO one of the reasons behind the missing resources. b) Symbian Only bad - nobody was interested beside Nokia - and has been removed again with Qt5. c) QML No migration path from C++/Widgets with the result, that almost all existing projects are not interested. With Qt 5.1 QML might have become an option for a desktop application - but to be honest I never heard of one. The existence of 2 different systems is a problem of itself. The development is working on the QML side, while the majority of the user base is doing widgets. For me as an author of a 3rd party lib it means I have to deal with 2 different platforms. The opposite of code once ... what used to be the mantra of Qt in the TrollTech days. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qwt and upgrading to Qt 5
I'm not using X11 at the moment, so it doesn't matter much to me, but this sounds like a significant issue. Note that you will *not* see that regression if you're coming from Qt 4.8. The raster engine is the default in 4.8 already. The native engine was default in 4.7 and before. Hm - my posting from the Qwt list hijacked without any further indication to a completely different list ??? Anyway - which paint engine is used for Qt4.8 on X11 is a matter of configuration. F.e. in my profile you find the line export QT_GRAPHICSSYSTEM=native. Everybody who has a use case where the X11 paint engine counts ( for Qwt it is drawing of polylines ) probably does something similar. So this is not a question of a default setting - with Qt5 an option is gone. About remote desktops: my environment for the last years was a noisy system in the basement and a really slow but silent system in the room where I'm working. I was using NX for the remote desktop. With Qt5 this combination has become hard to use: falling curtains instead of fast responses. So I had to buy a new system - fast, but without fans - to have a comfortable local desktop environment again ... There is no QWS in Qt 5. It's replaced with QPA. But when comparing QPA/5.0 with QWS/4.8, what does it mean in terms of improvement/regression for a user today ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qwt and upgrading to Qt 5
On Sat, 23 Mar 2013 09:25:11 -0700, Thiago Macieira wrote: You may have heard stories about Wayland and whether it's ready for desktop usage. That's irrelevant... it's ready for embedded use already and has been for a year. I have to make a platform decision ( unrelated to Qwt ) in the following months for new types of hardware. QWS was o.k. for the past, but the missing integration of OpenGL is an issue I would like to avoid for the future. As we have tons of widgets based libraries QML is no option, but using Wayland is an realistic option - if stable. And will have definitely surpassed the old QWS server when the input method mechanism is integrated into Wayland in the next feature release. What we have is a touch, a couple of hard keys ( mapped to buttons ) and an encoder used like a mouse wheel - guess you wrote about less basic input methods. Thanks a lot for the hint, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [interest] Qt Installer Framework: How good is that?
Hi, I have to admit that I completely missed the existence of the installer framework so far. Before starting further investigations, please let me ask if it is a possible solution for me: I'm maintainer of the Qwt ( http://qwt.sf.net ) library and thought about offering binary packages that are compatible to the offical Qt SDKs. These packages need to be for Windows only as on other platforms binary packages are offered by distributors and/or users are experienced enough for building and installing from source code. Basically all what needs to be done is to copy some files ( libraries, headers, documentatio, prf files - but no application or parts from the Qt installation ) into some install directory and maybe: - adjusting the PATH variable - adjusting QT_PLUGIN_PATH - configuring qmake ( setting QMAKEFEATURES ) Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Looking for help or for a QT developer
On Sat, 28 Apr 2012 10:53:03 +0200, Cyril HAENEL wrote: Thus what I need is just a QT app which simulate a TFT screen by creating an 480x272 image in which ... Are you trying to reinvent qvfb ( http://qt-project.org/doc/qt-4.8/qvfb.html ) ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtSVG deprecated
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. 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. Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtSVG deprecated
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 ). 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 ? Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
