Hi
QMatrix4x4 is still qreal, which is still target depend? Is there any
intention to change that?
Best regards, Marco
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On terça-feira, 21 de fevereiro de 2012 06.34.35, BRM wrote:
> Perhaps a template is not the best option?
> Perhaps an abstract/virtual class that is derived from for the various
> classes would be better?
Perhaps templates are not the best option, but a class with virtuals definitely
isn't. I don
On terça-feira, 21 de fevereiro de 2012 15.40.16, jan-arve.saet...@nokia.com
wrote:
> Sorry for top-posting from my N9...
>
>
> I was thinking the same, but I'm afraid we can't change it, since it would
> cause too many subtle bugs.
> The best thing I can think is to deprecate it, and add a QRectS
Sorry for top-posting from my N9...
I was thinking the same, but I'm afraid we can't change it, since it would
cause too many subtle bugs.
The best thing I can think is to deprecate it, and add a QRectS or QRectI, but
I'm not utterly convinced...
Jan-Arve
21.02.12 15:31 skrev ext Andreas A
BRM [bm_witn...@yahoo.com]
> Perhaps a template is not the best option?
> Perhaps an abstract/virtual class that is derived from for the various
> classes would be better?
Not at all.
The discuasion was initiiated by performance and size considerations.
Andre'
_
> From: Thiago Macieira
> On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
>> A tangential question: should QRect be QBasicRect (in which case
> it
>> would probably have a class invariant of right()-left()==width() instead
>> of width()-1 as now. If there is a plan to move
2012/2/21 Thiago Macieira
> On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
> > sure I'd like that), then keeping QRect and using QRectI =
> QBasicRect
> > could do the trick.
> QRect must have the same semantics as it has today. Whether we want to add
> a
> *second* rectangle
On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
> A tangential question: should QRect be QBasicRect (in which case it
> would probably have a class invariant of right()-left()==width() instead
> of width()-1 as now. If there is a plan to move to CRect semantics (not
> sure I'd l
On terça-feira, 21 de fevereiro de 2012 10.02.24, Marc Mutz wrote:
> One would disallow compilers to instantiate the template with C++11 extern
> templates (this would be a good idea for all templates, esp. those with
> arguments constrained to just a few potential types). All other compilers:
> wh
On Tuesday February 21 2012, André Somers wrote:
> Op 21-2-2012 9:35, Thiago Macieira schreef:
> > On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> >> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> >> const" etc. Can that be done with the typedefs
On Tuesday February 21 2012, Thiago Macieira wrote:
> On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> > Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> > const" etc. Can that be done with the typedefs proposed above, or does
> > it require having "
On terça-feira, 21 de fevereiro de 2012 09.38.58, André Somers wrote:
> Just wondering: while I think using templates for these classes is a
> good idea in principle, will using such template magic as you are
> suggesting here hurt compilation times, both of Qt itself and Qt
> applications using th
Op 21-2-2012 9:35, Thiago Macieira schreef:
> On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
>> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
>> const" etc. Can that be done with the typedefs proposed above, or does
>> it require having "QRectD QRec
On terça-feira, 21 de fevereiro de 2012 08.24.52, Samuel Rødal wrote:
> Also, I guess we'll want convenience functions "QRectD QRectF::toRectD()
> const" etc. Can that be done with the typedefs proposed above, or does
> it require having "QRectD QRectD::toRectD() const" as well?
With some template
On 02/20/2012 08:16 PM, ext Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 18.36.50, Marc Mutz wrote:
>> Please look at the numbers that Boudewijn posted in the footnote (in the
>> mail that you replied to) and realise that you need to keep qreal/QFooF in
>> deprecated peace. I
On segunda-feira, 20 de fevereiro de 2012 18.36.50, Marc Mutz wrote:
> Please look at the numbers that Boudewijn posted in the footnote (in the
> mail that you replied to) and realise that you need to keep qreal/QFooF in
> deprecated peace. I, too, know of too much customer code that'd break
> oth
On Monday 20 February 2012 18:20:08 Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 17.47.49, Olivier Goffart wrote:
> > On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> > > On segunda-feira, 20 de fevereiro de 2012 16.12.24,
> > > andre.poen...@nokia.com
> > >
> > >
Abecasis Joao wrote:
> What's the porting effort for applications that use and depend on qreal?
The effort depends mainly on whether there will be a way to have a "double"
incarnation of the "coordinate classes".
_If_ there is a *D set (e.g. the proposed thin wrapper around a *Base
then the port
On Monday February 20 2012, you wrote:
> > Why not just use a typedef:
> >
> > typedef QRectImpl QRect;
> > typedef QRectImpl QRectD;
> > typedef QRectImpl QRectF;
>
> To keep it source compatible with code using forward-declarations of
> QRectF etc. Not exactly a big issue, but no need to b
On Monday February 20 2012, João Abecasis wrote:
> Boudewijn Rempt wrote:
> > Well, Qt is a library, a platform -- and that means that you cannot
> > predict how and when classes and things like qreal will be used, and that
> > if something is changed there, it _will_ mean a porting effort,
> > pot
On segunda-feira, 20 de fevereiro de 2012 18.27.47, Mark wrote:
> Qt4 was going to have a "qt4support" module right?
No, that was never the intention.
> Why not drop it out of
> Qt5 and put it in the Qt4 support module?
> That way users know it's deprecated and should not be used but does allow
>
2012/2/20 João Abecasis
>
> Boudewijn Rempt wrote:
> > Well, Qt is a library, a platform -- and that means that you cannot
> predict how and when classes and things like qreal will be used, and that
> if something is changed there, it _will_ mean a porting effort, potentially
> a big one. Heck, w
On segunda-feira, 20 de fevereiro de 2012 17.47.49, Olivier Goffart wrote:
> On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> > On segunda-feira, 20 de fevereiro de 2012 16.12.24,
> > andre.poen...@nokia.com
> >
> > wrote:
> > > To keep it source compatible with code using forward-decl
Boudewijn Rempt wrote:
> Well, Qt is a library, a platform -- and that means that you cannot predict
> how and when classes and things like qreal will be used, and that if
> something is changed there, it _will_ mean a porting effort, potentially a
> big one. Heck, we haven't even really recove
On 02/20/2012 05:20 PM, ext Boudewijn Rempt wrote:
> On Monday 20 February 2012 Feb, Samuel Rødal wrote:
>> On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
>>> On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
I also thought we had agreed that QRectF should be float on all
plat
On Monday 20 February 2012 17:38:42 Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 16.12.24, andre.poen...@nokia.com
>
> wrote:
> > To keep it source compatible with code using forward-declarations of
> > QRectF etc. Not exactly a big issue, but no need to break it...
>
> To
On segunda-feira, 20 de fevereiro de 2012 16.12.24, andre.poen...@nokia.com
wrote:
> To keep it source compatible with code using forward-declarations of QRectF
> etc. Not exactly a big issue, but no need to break it...
To keep source compatibility with forward declarations, you need:
class QRec
On Monday 20 February 2012 Feb, Samuel Rødal wrote:
> On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
> > On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
> >> I also thought we had agreed that QRectF should be float on all
> >> platforms and we don't need double-precision geometric cla
Marc Mutz [marc.m...@kdab.com]
> On Monday February 20 2012, andre.poen...@nokia.com wrote:
> > PS: If we agree that template QRectBase; class QRectF :
> > QRectBase class QRectD : QRectBase etc would be acceptable
> > for 5.0 I'd try to come up with a patch for (b). For (a) the short solution
>
On 02/20/2012 04:58 PM, ext Christoph Feck wrote:
> On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
>> I also thought we had agreed that QRectF should be float on all
>> platforms and we don't need double-precision geometric classes
>> anyway.
>
> I think we agreed on the former, but hop
On Monday February 20 2012, andre.poen...@nokia.com wrote:
> PS: If we agree that template QRectBase; class QRectF :
> QRectBase class QRectD : QRectBase etc would be acceptable
> for 5.0 I'd try to come up with a patch for (b). For (a) the short solution
> would be simply making the typedef unc
On Monday 20 February 2012 16:02:09 Thiago Macieira wrote:
> I also thought we had agreed that QRectF should be float on all
> platforms and we don't need double-precision geometric classes
> anyway.
I think we agreed on the former, but hopefully not on the latter. Many
geometric classes, such as
Thiago Macieira wrote:
> I also thought we had agreed that QRectF should be float on all platforms
This part is fine with me.
> [...] and we don't need double-precision geometric classes anyway.
Such opinions have been voiced, there was, however, no consensus, at least
not in the '"we" == "all
On segunda-feira, 20 de fevereiro de 2012 14.34.57, andre.poen...@nokia.com
wrote:
> Thiago Macieira [thiago.macie...@intel.com]
>
> > [...] How about we leave it defined to double in all platforms and
> > deprecate it?
> Replacing all 'qreal' occurrences with 'double' would be a significant
> per
On segunda-feira, 20 de fevereiro de 2012 14.17.29, gunnar.sle...@nokia.com
wrote:
> > How about we leave it defined to double in all platforms and deprecate it?
>
> On embedded, this has the side effect that QML items would grow in size, and
> quite significantly as well. In addition, parts of sce
Thiago Macieira [thiago.macie...@intel.com]
> [...] How about we leave it defined to double in all platforms and deprecate
> it?
Replacing all 'qreal' occurrences with 'double' would be a significant
performance
hit for some embedded people. Replacing all 'qreal' occurrences with 'float'
spoil
On Feb 20, 2012, at 2:36 PM, ext Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 09.33.27, andre.poen...@nokia.com
> wrote:
>> This needlessly removes existing functionality. We promised to try
>> hard to not do that in the Qt 4-> Qt 5 transition. Removing the typedef
>> is es
On segunda-feira, 20 de fevereiro de 2012 09.33.27, andre.poen...@nokia.com
wrote:
> This needlessly removes existing functionality. We promised to try
> hard to not do that in the Qt 4-> Qt 5 transition. Removing the typedef
> is essentially a showstopper for people currently relying on double.
>
> Ramsay Lincoln (Nokia-MP/Brisbane) wrote:
> On 02/17/2012 09:58 PM, ext lars.kn...@nokia.com wrote:
> > On the idea itself I'd like to hear some more opinions. Removing qreal
> > would cause some SC breakage, but you would also get a compile error on
> > places that could break. Unfortunately the
On segunda-feira, 20 de fevereiro de 2012 14.05.22, craig.sc...@csiro.au
wrote:
> Rather than an outright removal, perhaps it would be better to simply #ifdef
> it out with some way for devs to re-enable it. Thus, by default it will be
> as though it was no longer defined (hence prompts people to u
On 20/02/2012, at 1:29 PM, Lincoln Ramsay wrote:
> On 02/17/2012 09:58 PM, ext lars.kn...@nokia.com wrote:
>> On the idea itself I'd like to hear some more opinions. Removing qreal
>> would cause some SC breakage, but you would also get a compile error on
>> places that could break. Unfortunately
On 02/17/2012 09:58 PM, ext lars.kn...@nokia.com wrote:
> On the idea itself I'd like to hear some more opinions. Removing qreal
> would cause some SC breakage, but you would also get a compile error on
> places that could break. Unfortunately the signal to noise ratio would
> most likely be pretty
On 2/17/12 12:39 PM, "ext Atlant Schmidt"
wrote:
>João:
>
>> I think the even better approach, once the necessary changes are done
>> inside Qt and things settle down, is to drop qreal completely. Don't
>> pick float or real, don't define it. Or typedef it to some dummy type:
>>
>>class qreal
João:
> I think the even better approach, once the necessary changes are done
> inside Qt and things settle down, is to drop qreal completely. Don't
> pick float or real, don't define it. Or typedef it to some dummy type:
>
>class qreal_IsNoMore {};
>typedef qreal_IsNoMore qreal;
>
> Force
Ben wrote:
> The concerns are not the signals/slots. Yes, that is one aspect.
> The concern is other code that uses qreal - e.g. people embedding it
> in binary protocols, or using it in printf()'s, etc.
> The vast majority of Qt is probably in the desktop arena, and there
> qreal is a double; and
> >
> > On Thu, Feb 16, 2012 at 5:03 AM, wrote:
> > > On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo"
> wrote:
> > >>On 15 February 2012 22:56, Sean Harmer
> wrote:
> > >>> On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
> > Anyway. It's probably better to go for any kind of uniformity. I
> From: "lars.kn...@nokia.com"
> On 2/16/12 6:21 PM, "ext Girish Ramakrishnan"
>
> wrote:
>
>> Hi Lars,
>>
>> On Thu, Feb 16, 2012 at 5:03 AM, wrote:
>>> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo"
> wrote:
>>>
On 15 February 2012 22:56, Sean Harmer
> wrote:
> On 15/02/2012
Olivier Goffart wrote:
> > I thought we were agreeing upon deprecating qreal (i.e leave it as-is)
> > and use float and double explicitly inside Qt. At least, that's what I
> > +1d for :) The patch above changes qreal and doesn't deprecate it.
>
> Can be done in another commit,
> One after the mas
On 2/16/12 6:21 PM, "ext Girish Ramakrishnan"
wrote:
>Hi Lars,
>
>On Thu, Feb 16, 2012 at 5:03 AM, wrote:
>> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" wrote:
>>
>>>On 15 February 2012 22:56, Sean Harmer wrote:
On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
> Anyway. It's prob
On Thursday 16 February 2012 09:21:34 Girish Ramakrishnan wrote:
> Hi Lars,
>
> On Thu, Feb 16, 2012 at 5:03 AM, wrote:
> > On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" wrote:
> >>On 15 February 2012 22:56, Sean Harmer wrote:
> >>> On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
> Any
Hi Lars,
On Thu, Feb 16, 2012 at 5:03 AM, wrote:
> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" wrote:
>
>>On 15 February 2012 22:56, Sean Harmer wrote:
>>> On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
Anyway. It's probably better to go for any kind of uniformity. If
that's sin
On Thu, Feb 16, 2012 at 2:03 PM, wrote:
> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" wrote:
>
>>On 15 February 2012 22:56, Sean Harmer wrote:
>>> Why not make these classes into templates and have typedefs for the
>>> float and double cases? It always confused me why QVectorD mixed
>>> qreals
On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo" wrote:
>On 15 February 2012 22:56, Sean Harmer wrote:
>> On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
>>> Anyway. It's probably better to go for any kind of uniformity. If
>>>that's single precision, it should be made clear that QPolygonF/QRec
On 15 February 2012 22:56, Sean Harmer wrote:
> On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
>> Anyway. It's probably better to go for any kind of uniformity. If that's
>> single precision, it should be made clear that QPolygonF/QRectF are not
>> meant for applications needing "polygons"
On quinta-feira, 16 de fevereiro de 2012 08.28.22, Robin Burchell wrote:
> On Thu, Feb 16, 2012 at 8:01 AM, Girish Ramakrishnan
>
> wrote:
> > I think changing qreal to float will result in subtle porting bugs:
> > like when a Qt4 QDataStream (a double) is read by Qt5 (which is now
> > suddenly fl
On Thu, Feb 16, 2012 at 8:01 AM, Girish Ramakrishnan
wrote:
> I think changing qreal to float will result in subtle porting bugs:
> like when a Qt4 QDataStream (a double) is read by Qt5 (which is now
> suddenly float).
Huh? QDataStream doesn't have any stream operators for qreal, does it?
The doc
Hi,
On Wed, Feb 15, 2012 at 3:26 AM, wrote:
> On 2/15/12 12:11 PM, "ext Olivier Goffart" wrote:
>
>>On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote:
>>> On 15/02/2012, at 8:58 PM,
>>>
>>wrote:
>>> > On 2/15/12 10:28 AM, "ext Thiago Macieira"
>>> >
>>> > wrote:
>>> >> On quar
On 15/02/2012 11:53, andre.poen...@nokia.com wrote:
> Anyway. It's probably better to go for any kind of uniformity. If that's
> single precision, it should be made clear that QPolygonF/QRectF are not
> meant for applications needing "polygons" in general. Maybe one should
> consider adding som
On 15/02/2012 07:45, ext Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars.kn...@nokia.com wrote:
>> Just a small nitpick: You won't end up on the wrong side of the river. The
>> earth has a diameter of around 4km. With 24 bits precision, you end up
>> with a jitt
> From: "lars.kn...@nokia.com"
> On 2/15/12 12:11 PM, "ext Olivier Goffart" wrote:
>> On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote:
>>> On 15/02/2012, at 8:58 PM,
>>>
>> wrote:
>>> > On 2/15/12 10:28 AM, "ext Thiago Macieira"
>
>>> >
>>> > wrote:
>>> >> On quarta-f
On quarta-feira, 15 de fevereiro de 2012 12.33.18, lars.kn...@nokia.com wrote:
> Just a small nitpick: You won't end up on the wrong side of the river. The
> earth has a diameter of around 4km. With 24 bits precision, you end up
> with a jitter of just above 2m. You might get wet feet though ;-
On 02/15/2012 01:17 PM, ext Olivier Goffart wrote:
> On Wednesday 15 February 2012 07:38:44 gunnar.sle...@nokia.com wrote:
>> The only questionable use case is geolocation. We know for a fact that
>> floats have limitations in this area and both Qt3D and QtLocation make use
>> of QVector[2|3|4]D an
On 2/15/12 12:53 PM, "ext andre.poen...@nokia.com"
wrote:
>
>> Sletta Gunnar (Nokia-MP/Oslo) wrote:
>> - Using "double" is pure waste for a lot of use cases. QRectF,
>>QPointF, QPainter, QPolygonF,
>> OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require
>>the precision
>> off
On Wednesday 15 February 2012 07:38:44 gunnar.sle...@nokia.com wrote:
> The only questionable use case is geolocation. We know for a fact that
> floats have limitations in this area and both Qt3D and QtLocation make use
> of QVector[2|3|4]D and QMatrix4x4 which will now be a float. However, this
>
On quarta-feira, 15 de fevereiro de 2012 12.11.27, Olivier Goffart wrote:
> Then I tought about Qt has its own typedef for quintptr and quint64 and what
> not, so we could as well keep qreal.
> (But i'm far from being opposed, but then we can also deprecate all the
> other ones)
Those have other r
> Sletta Gunnar (Nokia-MP/Oslo) wrote:
> - Using "double" is pure waste for a lot of use cases. QRectF, QPointF,
> QPainter, QPolygonF,
> OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require the
> precision
> offered by double precision floating point.
Whether having doub
On 2/15/12 12:11 PM, "ext Olivier Goffart" wrote:
>On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote:
>> On 15/02/2012, at 8:58 PM,
>>
>wrote:
>> > On 2/15/12 10:28 AM, "ext Thiago Macieira"
>> >
>> > wrote:
>> >> On quarta-feira, 15 de fevereiro de 2012 08.49.31,
>>lars.kn...@
On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote:
> On 15/02/2012, at 8:58 PM,
wrote:
> > On 2/15/12 10:28 AM, "ext Thiago Macieira"
> >
> > wrote:
> >> On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars.kn...@nokia.com
> >>
> >> wrote:
> >>> I don't think it'll break to
On 15/02/2012, at 8:58 PM, wrote:
> On 2/15/12 10:28 AM, "ext Thiago Macieira"
> wrote:
>
>> On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars.kn...@nokia.com
>> wrote:
>>> I don't think it'll break too many places though, so I'm not too worried
>>> about the change.
>>
>> It will. Ask
On 2/15/12 10:28 AM, "ext Thiago Macieira"
wrote:
>On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars.kn...@nokia.com
>wrote:
>> I don't think it'll break too many places though, so I'm not too worried
>> about the change.
>
>It will. Ask Ubuntu packagers for how much work they had to put in
On quarta-feira, 15 de fevereiro de 2012 08.49.31, lars.kn...@nokia.com wrote:
> I don't think it'll break too many places though, so I'm not too worried
> about the change.
It will. Ask Ubuntu packagers for how much work they had to put in to fix the
mismatches in KDE. We can assume that work is
On 2/15/12 9:26 AM, "ext Thiago Macieira"
wrote:
>On quarta-feira, 15 de fevereiro de 2012 07.38.44,
>gunnar.sle...@nokia.com
>wrote:
>> Our initial idea was to change "qreal" to "double" to avoid any
>>potential
>> regression but the impact on size combined with the fact that the added
>> precis
On Wednesday 15. February 2012 08.38.44 ext gunnar.sle...@nokia.com wrote:
> For some time we have wanted to unify the behavior of qreal on desktop and
> embedded. Currently, qreal is defined to be double on desktop and to a
> float on embedded.
>
> The reasons for unifying are:
>
> - Using "dou
Den 15. feb. 2012 08:38, skrev ext gunnar.sle...@nokia.com:
> For some time we have wanted to unify the behavior of qreal on desktop and
> embedded. Currently, qreal is defined to be double on desktop and to a float
> on embedded.
>
> The reasons for unifying are:
>
> - Using "double" is pure w
On quarta-feira, 15 de fevereiro de 2012 07.38.44, gunnar.sle...@nokia.com
wrote:
> Our initial idea was to change "qreal" to "double" to avoid any potential
> regression but the impact on size combined with the fact that the added
> precision is almost never needed changed our minds
> (https://bug
For some time we have wanted to unify the behavior of qreal on desktop and
embedded. Currently, qreal is defined to be double on desktop and to a float on
embedded.
The reasons for unifying are:
- Using "double" is pure waste for a lot of use cases. QRectF, QPointF,
QPainter, QPolygonF, Open
76 matches
Mail list logo
