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
Well we have 3 different ways and priorities to set the config file.
One of the possibilities is:
We have a default config file which uses a hardcoded filename but the path to
this file is created with the default config file path + organization name +
application name.
For detailed information
One of the requirements was to activate the category log without recompiling
the code.
Of course you can design QLog in that way that it can overwrite the category
flags out from the QLog config file but then we have two different ways to
activate or deactivate categories and each QLog enable ch
Yes I know and I've changed it.
No QSetting is used anymore.
B.R.
WB
-Original Message-
From: development-bounces+wolfgang.beck=nokia@qt-project.org
[mailto:development-bounces+wolfgang.beck=nokia@qt-project.org] On Behalf
Of ext Thiago Macieira
Sent: Monday, February 20, 2012
I'm preferring having QLog active only if a config file is there.
It doesn't make sense to me at all having an environment variable that can
activate QLog but not config file to activate the categories.
As long there is no config file QLog is disable and uses less performance as
possible but stil
Hi
Qt3D is now the name of our Qt Module, our repositories, our "product" in
documentation, and our packages; as well as the project and team.
There's a bit more detail on the bug for the change:
https://bugreports.qt-project.org/browse/QTBUG-22962
For most the only thing to note would be tha
I support this nomination.
Danny.
From: development-bounces+daniel.pope=nokia@qt-project.org
[development-bounces+daniel.pope=nokia@qt-project.org] on behalf of Smith
Sarah.J (Nokia-MP/Brisbane)
Sent: 10 February 2012 11:30
To: development@qt-project.org
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
On segunda-feira, 20 de fevereiro de 2012 16.42.00, David Faure wrote:
> > Clearly you haven't read http://codereview.qt-project.org/#change,13226
> >
> >
> >
> > > We've removed all traces of
> > > QSettings support so QSettings could be moved away.
>
> QFile is all that's needed to implement a ba
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
[oops, mail sent too early]
On Monday 20 February 2012 16:38:50 David Faure wrote:
> On Monday 20 February 2012 14:33:26 Thiago Macieira wrote:
> > On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote:
> > > > Do you imagine something in the qLog config file? An environment
> > >
On Monday 20 February 2012 14:33:26 Thiago Macieira wrote:
> On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote:
> > > Do you imagine something in the qLog config file? An environment
> > > variable? A C++ API?
> >
> > I think "something in the qLog config file" is the best opti
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
- Original Message -
> From: Thiago Macieira
> On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote:
>> > Do you imagine something in the qLog config file? An environment
>> > variable? A C++ API?
>>
>> I think "something in the qLog config file" is the best option.
On segunda-feira, 20 de fevereiro de 2012 12.40.33, kranthi.kumar-
kunt...@nokia.com wrote:
> Hi,
>
> Ok, due to the fact that features have been freezed for Qt5.0 am proposing
> this to be an addon module.
>
> so am sending a request for a new Playground project
>
> name of the project: alignedtim
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.
>
On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote:
> > Do you imagine something in the qLog config file? An environment
> > variable? A C++ API?
>
> I think "something in the qLog config file" is the best option. It allows
> to provide a GUI tool that toggles the configuration,
Hi,
Ok, due to the fact that features have been freezed for Qt5.0 am proposing this
to be an addon module.
so am sending a request for a new Playground project
name of the project: alignedtimers
description: The AlignedTimer is a service for applications to synchronize
their activity.
Ali
On Monday 20 February 2012 12:25:07 Lincoln Ramsay wrote:
> On 02/17/2012 06:23 PM, ext David Faure wrote:
> > Yes, end users don't like debug statements polluting their terminals and
> > session log file. With the above reasoning, we could just keep saying "do
> > not use qDebug in committed code"
> 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
Hi Sean.
We would be very happy with help from visually impaired people, in terms of
code contribution, bug reports or just general feedback.
Both Qt4 and Qt5 codebases needs help, but the Qt 4 codebase works only for
widgets, while the Qt 5 codebase should work for both widgets and QML items.
On segunda-feira, 20 de fevereiro de 2012 12.25.07, Lincoln Ramsay wrote:
> You can of course always drop these messages from the message handler. I
> know working on Qtopia we did exactly that so that qDebugs were never
> seen in "release" builds even if they were accidentally checked into the
> r
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
42 matches
Mail list logo
