On Thursday 29 March 2012 10:02:59 Lincoln Ramsay wrote:
> On 03/29/2012 09:54 AM, ext Olivier Goffart wrote:
> > That would be possible with runtime backtrace (#include
> > backtrace(), on Linux)
> > So one could add some tokens in QT_MESSAGE_PATTERN to get the backtrace.
> > The problem is that r
Hi guys,
I'm following the steps on
http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt
To get a playground project created for qlogger in place.
qlogger should be the previous discussed category logging mechanism on the
developer ML.
(see http://codereview.qt-project.org/#change,13
On 03/29/2012 09:54 AM, ext Olivier Goffart wrote:
> That would be possible with runtime backtrace (#include
> backtrace(), on Linux)
> So one could add some tokens in QT_MESSAGE_PATTERN to get the backtrace.
> The problem is that runtime backtrace is often not really accurate.
Getting a whole bac
On Thursday 29 March 2012 09:43:53 Lincoln Ramsay wrote:
> On 03/29/2012 09:41 AM, ext Lincoln Ramsay wrote:
> > Why can't Creator just set the QT_MESSAGE_PATTERN environment variable
> > then and leave the default alone? Creator would not need to show the
> > filename and line number, just use the
On 03/29/2012 09:41 AM, ext Lincoln Ramsay wrote:
> Why can't Creator just set the QT_MESSAGE_PATTERN environment variable
> then and leave the default alone? Creator would not need to show the
> filename and line number, just use them for when you click on the warnings.
And related to this...
If
On 03/29/2012 12:39 AM, ext kai.koe...@nokia.com wrote:
> PS: From an IDE perspective including the file + line would help so
> that you could just 'jump' to the source of a warning by clicking on
> it. However, the file string can get quite long (think about shadow
> builds) ...
Why can't Creator
On quarta-feira, 28 de março de 2012 19.08.04, lars.kn...@nokia.com wrote:
> I'll try to go through them tonight.
Thanks for the effort. I've gone over all the recommendations and made the
modifications. We're pending further work on:
1) QUrlTwoFlags - a helper class like QFlags but that takes tw
On Wednesday 28 March 2012 14:06:46 Thiago Macieira wrote:
> The only thing I ask is that we keep Q_PRIMITIVE_TYPE for *real* primitive
> types
Why?
Why would we need that.
If a type behaves like a POD, then it can be used as a POD.
Some types have default constructor to initialize to some defa
I'll try to go through them tonight.
Lars
On 3/28/12 8:02 PM, "ext Thiago Macieira"
wrote:
>The new QUrl has been up for review for several days now. Lots of people
>have
>commented on the basic enablers and I have taken into account a lot of
>feedback.
>
>But as the principle of bikeshed goes
On 3/28/12 7:06 PM, "ext Thiago Macieira"
wrote:
>On quarta-feira, 28 de março de 2012 15.37.46, Marc Mutz wrote:
>> So I'd like to propose to extend the scope of Q_PRIMITIVE_TYPE to cover
>>such
>> non-POD classes that are nevertheless close enough to PODs.
>>
>> That means:
>> 1a. memset(0, &t
The new QUrl has been up for review for several days now. Lots of people have
commented on the basic enablers and I have taken into account a lot of
feedback.
But as the principle of bikeshed goes, no one has reviewed yet the bulk of the
change, which are:
- the URL recoder
- the QUrlQuery class
On quarta-feira, 28 de março de 2012 15.37.46, Marc Mutz wrote:
> So I'd like to propose to extend the scope of Q_PRIMITIVE_TYPE to cover such
> non-POD classes that are nevertheless close enough to PODs.
>
> That means:
> 1a. memset(0, &t, sizeof(T)) constructs a valid object, and that object is
>
On Wed, Mar 28, 2012 at 04:17:36PM +, ext shane.kea...@accenture.com wrote:
> If there are other Qt4 classes that would benefit from this approach, we can
> rename the repo later.
>
well, no, we cannot (without major hassle) - gerrit doesn't support renaming.
_
(Thread necromancy)
As there was no consensus on the repo naming, let's use the original suggestion.
I already ported these classes to two static libraries.
If there are other Qt4 classes that would benefit from this approach, we can
rename the repo later.
> -Original Message-
> From: l
Hi there,
In Qt 4 qDebug, qWarning etc just printed whatever was passed in. In Qt 5 we've
been changing this (1) so that you can configure Qt to print additional
information by setting the QT_MESSAGE_PATTERN environment variable. However, we
didn't change the default so far - so without setting
Hi,
Over at http://codereview.qt-project.org/21518, we're discussing whether QUuid
is Q_PRIMITIVE_TYPE or only Q_MOVABLE_TYPE.
The documentation of Q_DECLARE_TYPEINFO says Q_PRIMITIVE_TYPE means the type
is a POD, without constructors or destructors. According to that definition,
QUuid is not
Hi,
tl;dr: Things have to be done, but they have not been done yet.
It is mainly because qtdoc/doc/config/modules/qtdeclarative.qdocconf has not
been split into a qtqml.qdocconf and qtquick.qdocconf. There is also some magic
that has to be applied to qtdoc/doc/config/qt-project.qdocconf and
qt
17 matches
Mail list logo
