Re: [Development] Linking androiddeployqt: boot-strap library or libQt5Core
On Monday, 13 May 2019 07:28:55 PDT Edward Welbourne wrote: >> Does anyone know why androiddeployqt links against the boot-strap >> library ? i.e. Is there any good reason not to change it to link >> against libQt5Core instead ? Thiago Macieira (13 May 2019 17:08) replied: > androiddeployqt is a host tool. You don't run it on-device, but on the machine > you compiled Qt on. Thanks for the explanation. Meanwhile, discussion on IRC has yielded two further fixes. The timing is only done as part of debug code, so could be ripped out (or #if !bootstrap wrapped); or we can have a local tool class in the file to use QTime::currentTime() the same way its present timer API does. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] FP calculations and stability in Qt
On Mon, May 13, 2019 at 12:53:42PM +0300, Konstantin Shegunov wrote: > On Mon, May 13, 2019 at 12:42 PM Konstantin Ritt wrote: > > > Writing and proposing a patch would take less time than discussing pros > > and cons here. > > Which I had in a minute fraction done, as a pass-by in the comments. I'm > not, however, willing to take huge technical debt on the issue by investing > copious amounts of time writing a specialized decomposition for this > particular case, in this particular class, for this particular set of > values. I'm not going to do it better than already done, is one, and > secondly it's a huge time sink. Combine both to get: "dubious result for a > big investment". > > What I'd really, really want, ideally, is to have a well tested tool(set) > that I can rely on to do the job, whence my initial question: "can we talk > about how feasible it is to pull something (or parts of it) in Qt, even if > only internally, to facilitate stable fp calculation" The answer is likely "Nobody will stop an attempt to talk, but given that such issues have been around at least since Qt 4.0 (that's when I personally ran into them) and the tendency lately is rather to not include well-known versions of $X anymore but rather depend on random version of 'system' or auto-'updated' $X this is unlikely to happen." Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Linking androiddeployqt: boot-strap library or libQt5Core
On Monday, 13 May 2019 07:28:55 PDT Edward Welbourne wrote: > Does anyone know why androiddeployqt links against the boot-strap > library ? i.e. Is there any good reason not to change it to link > against libQt5Core instead ? androiddeployqt is a host tool. You don't run it on-device, but on the machine you compiled Qt on. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Linking androiddeployqt: boot-strap library or libQt5Core
Hi all, In an attempt to deprecate [0] use of QTime as a timer (in favour of QElapsedTimer, which does the job properly) I've tripped over the fact that androiddeployqt links against the boot-strap library rather than libQt5Core. The former lacks QElapsedTimer, so I can't move ahead with the deprecation until I've either changed it to link against the latter or added QElapsedTimer to the boot-strap library. * [0] https://codereview.qt-project.org/260830 Does anyone know why androiddeployqt links against the boot-strap library ? i.e. Is there any good reason not to change it to link against libQt5Core instead ? Does anyone know a good reason why (if I can't switch libraries) QElapsedTimer should not be included in the boot-strap library ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a module for Qt Quick Timeline Implementation
Hi Frederik, Yes, the module was already created. So the patch in qt/qt5 is 5.14 should be the only thing missing. Yes, I think it is an addon. Best Regards, Thomas Hartmann From: Frederik Gladhorn Sent: Monday, May 13, 2019 1:03:53 PM To: development@qt-project.org Cc: Thomas Hartmann Subject: Re: [Development] Requesting a module for Qt Quick Timeline Implementation Hi Thomas, Since the module exists, it's a bit unclear to me what you request (creating the module would what I'd expect). The next step would be to ask for inclusion in the releases and making a patch to qt/qt5 to enable us shipping the module by default. Then there's the question which state the module would be in, I guess it's "addon" or so. Cheers, Frederik On torsdag 9. mai 2019 10:21:55 CEST Thomas Hartmann wrote: > Hi, > > I would like to request for a new module: > > Name of the repository: qt/qtquicktimeline.git > Description: Module for keyframe-based timeline construction. > Responsible person: Thomas Hartmann > Gerrit user/email: thomas.hartm...@qt.io > > The module is already on gerrit and is in a mature state by now. > The timeline module is used by Qt Design Studio and Qt Quick Designer > but there are use cases independent from tooling. > > One use case is defining 'animations' not in time, but depending on an > expression. This way it is very easy to create complex progress bars or > gauges. > > Best Regards, > Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a module for Qt Quick Timeline Implementation
Hi Thomas, Since the module exists, it's a bit unclear to me what you request (creating the module would what I'd expect). The next step would be to ask for inclusion in the releases and making a patch to qt/qt5 to enable us shipping the module by default. Then there's the question which state the module would be in, I guess it's "addon" or so. Cheers, Frederik On torsdag 9. mai 2019 10:21:55 CEST Thomas Hartmann wrote: > Hi, > > I would like to request for a new module: > > Name of the repository: qt/qtquicktimeline.git > Description: Module for keyframe-based timeline construction. > Responsible person: Thomas Hartmann > Gerrit user/email: thomas.hartm...@qt.io > > The module is already on gerrit and is in a mature state by now. > The timeline module is used by Qt Design Studio and Qt Quick Designer > but there are use cases independent from tooling. > > One use case is defining 'animations' not in time, but depending on an > expression. This way it is very easy to create complex progress bars or > gauges. > > Best Regards, > Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] FP calculations and stability in Qt
On Mon, May 13, 2019 at 12:42 PM Konstantin Ritt wrote: > Writing and proposing a patch would take less time than discussing pros > and cons here. > Which I had in a minute fraction done, as a pass-by in the comments. I'm not, however, willing to take huge technical debt on the issue by investing copious amounts of time writing a specialized decomposition for this particular case, in this particular class, for this particular set of values. I'm not going to do it better than already done, is one, and secondly it's a huge time sink. Combine both to get: "dubious result for a big investment". What I'd really, really want, ideally, is to have a well tested tool(set) that I can rely on to do the job, whence my initial question: "can we talk about how feasible it is to pull something (or parts of it) in Qt, even if only internally, to facilitate stable fp calculation" ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] FP calculations and stability in Qt
Writing and proposing a patch would take less time than discussing pros and cons here. Konstantin пн, 13 мая 2019 г., 12:31 Konstantin Shegunov : > On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud > wrote: > >> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov >> wrote: >> > Doesn't this imply it should be dropped as an API that we can rely on? >> >> No i don't think so, this is just an edge case. I solved it by >> changing the base unit of my graphics view, so that it doesn't have to >> manipulate tiny FP values. >> I remember reporting that, and AFAIR, an example was an arc in a >> QGraphicsPathItem rendered as as a polyline. >> > > Okay, I'll bite. Let's take as an example the bugreport I mentioned, how > would such a transformation of units look like? It's not a loaded question, > I'm genuinely interested if I missed something because really I don't see > it. My point is that the actual calculation is done internally, so > restructuring the units isn't at all trivial, nor perhaps possible, on the > part of the user. If we can accept that we don't want to go through the > motions to make transformations at least correct in all cases, I'm fine > with that too, but we should then warn the user not to expect it from the > library. > > I then turned on specialised library, Qt is a GUI toolkit, and is >> optimised for painting. Qt takes all opportunities to be fast and >> efficient in that context, and that includes being "mathematically" >> imprecised, painting is all about pixels at the end of the day. >> > > Look, I'm not arguing we should aim for 1 epsilon precision, but there's > "imprecise" and then there's "blatantly wrong". > > A pixel is a surface, everything is correct as long as the surface >> covered by the pixel contains the point. >> > > Which it may not, is my argument. Numerical instability is the > disproportionate grow of the relative error. If you don't keep that error > in check then you (can) just get nonsense. I can, and will, accept that we > don't want the most precise algorithm out there, but at least we should > strive for one that's correct, shouldn't we? > > What i was trying to say, is that all geometry operations performed by >> components coupled to QPainter are good enough (and very efficient) >> for painting, by are not usable for "scientific" calculation. >> > > Define "good enough" please. Is "good enough" errors bound by the errors > in the input, is "good enough" errors that explode with some inputs, or > something else? > > OT: By the way, as far as I can tell a LU with pivoting (O(n^3) > complexity) is approximately as efficient as the algorithm currently > employed in the mentioned bugreport. It has two major advantages in my > view, however. One is that it's rank-revealing, thus you can tell if > there's linear dependency with zero cost. Secondly, it's not reinventing a > square wheel. > > >> QPainterPath is not called QPath, expecting to do precise geometry >> boolean set operations with it is a mistake. >> > > To extend my argument from the previous paragraph(s): > How do you take the algebra out of the geometry? I get that the algebra > can go its merry way on its own (e.g. in science), but the geometry just > depends on the algebra. So if the algebra's wrong, the geometry can be all > over the place by simple logical implication, you can't tell if it's > correct or not. > > Kind regards. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] FP calculations and stability in Qt
On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud wrote: > On Mon, 13 May 2019 at 07:47, Konstantin Shegunov > wrote: > > Doesn't this imply it should be dropped as an API that we can rely on? > > No i don't think so, this is just an edge case. I solved it by > changing the base unit of my graphics view, so that it doesn't have to > manipulate tiny FP values. > I remember reporting that, and AFAIR, an example was an arc in a > QGraphicsPathItem rendered as as a polyline. > Okay, I'll bite. Let's take as an example the bugreport I mentioned, how would such a transformation of units look like? It's not a loaded question, I'm genuinely interested if I missed something because really I don't see it. My point is that the actual calculation is done internally, so restructuring the units isn't at all trivial, nor perhaps possible, on the part of the user. If we can accept that we don't want to go through the motions to make transformations at least correct in all cases, I'm fine with that too, but we should then warn the user not to expect it from the library. I then turned on specialised library, Qt is a GUI toolkit, and is > optimised for painting. Qt takes all opportunities to be fast and > efficient in that context, and that includes being "mathematically" > imprecised, painting is all about pixels at the end of the day. > Look, I'm not arguing we should aim for 1 epsilon precision, but there's "imprecise" and then there's "blatantly wrong". A pixel is a surface, everything is correct as long as the surface > covered by the pixel contains the point. > Which it may not, is my argument. Numerical instability is the disproportionate grow of the relative error. If you don't keep that error in check then you (can) just get nonsense. I can, and will, accept that we don't want the most precise algorithm out there, but at least we should strive for one that's correct, shouldn't we? What i was trying to say, is that all geometry operations performed by > components coupled to QPainter are good enough (and very efficient) > for painting, by are not usable for "scientific" calculation. > Define "good enough" please. Is "good enough" errors bound by the errors in the input, is "good enough" errors that explode with some inputs, or something else? OT: By the way, as far as I can tell a LU with pivoting (O(n^3) complexity) is approximately as efficient as the algorithm currently employed in the mentioned bugreport. It has two major advantages in my view, however. One is that it's rank-revealing, thus you can tell if there's linear dependency with zero cost. Secondly, it's not reinventing a square wheel. > QPainterPath is not called QPath, expecting to do precise geometry > boolean set operations with it is a mistake. > To extend my argument from the previous paragraph(s): How do you take the algebra out of the geometry? I get that the algebra can go its merry way on its own (e.g. in science), but the geometry just depends on the algebra. So if the algebra's wrong, the geometry can be all over the place by simple logical implication, you can't tell if it's correct or not. Kind regards. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
