Re: [Development] Schedule for Qt 4.8.1
Tirsdag 14. februar 2012 06.28.00 skrev ext Turunen Tuukka: On 13.2.2012 18.32, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 13 de fevereiro de 2012 12.28.06, Turunen Tuukka wrote: snip I think good timing for the 4.8 patch releases would the roughly: 4.8.1 in mid-March 4.8.2 in end-May 4.8.3 in end-September 4.8.3 in mid-January 2013 Which leads to about 3 month intervals, that should be suitable for increasing the stability of this already mature base. May doesn't add up with three months. That said, I personally like two month cycles, but maybe three is more realistic. Cheers Frederik As said, we need to also see what makes sense content wise, and be prepared for a quick release if something urgent comes up. I am very happy to hear your feedback and thoughts on this. After the discussion it would be good to update the wiki with jointly agreed release plan for 4.8. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Schedule for Qt 4.8.1
On terça-feira, 14 de fevereiro de 2012 10.47.45, Frederik Gladhorn wrote: Tirsdag 14. februar 2012 06.28.00 skrev ext Turunen Tuukka: On 13.2.2012 18.32, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 13 de fevereiro de 2012 12.28.06, Turunen Tuukka wrote: snip I think good timing for the 4.8 patch releases would the roughly: 4.8.1 in mid-March 4.8.2 in end-May 4.8.3 in end-September 4.8.3 in mid-January 2013 Which leads to about 3 month intervals, that should be suitable for increasing the stability of this already mature base. May doesn't add up with three months. That said, I personally like two month cycles, but maybe three is more realistic. Indeed. During the Qt 4.3 and 4.4 times, we used to release one patch release every 4-8 weeks, which was only interrupted by having a release from a different branch. The current rate in Qt 4.8 was 186 commits in one month (Jan 11 to Feb 11). So I'd like to suggest that we release after no more than 2 months or 200 commits, and we can release earlier if necessary (as Tuukka suggests). In reality, I don't know if we have the manpower to do that, nor do I have access to the binary build farms, so I can't do any more than suggest. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
-- Kai Koehne Senior Software Engineer Nokia, Mobile Phones Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Ramsay Lincoln (Nokia-MP/Brisbane) Sent: Monday, February 13, 2012 1:33 AM To: development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) On 02/11/2012 01:44 AM, ext kai.koe...@nokia.com wrote: However, adding yet another 'keyword' to the framework has a price, especially since the difference between 'qDebug(QMessageLogContext(MyCategory))' and a 'qLog(MyCategory) ' is subtle. We tried that but while this difference is subtle to the eye, it's a huge difference to the implementation. qDebug is currently an argument-less macro that expands to the name of a function. Before message logging it was just a plain old function. Overloading means that qDebug(message) and qDebug() message both work. Since we can't have a macro func with 0, 1 or many arguments, we can only add a new overload for qDebug(category) message but if we do this, there is nowhere to put the do nothing quickly logic. Just wanted to point out that there are variadic macros: http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html #define qCategoryDebug(category, ...) if (isLogEnabled(category)) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug(__VA_ARGS__) Seems to work with at least gcc4.2.1 and Visual studio 2010. But that doesn't help with the fact that we can't differentiate between 'qDebug()', 'qDebug(Hello world)', and 'qDebug(MyCategory)' on the macro level. Expanding to this is always going to be slow: func(category) args expensive(); We need to expand to this to be fast: if (do_nothing) /*NOP*/; else func(category) args expensive(); Thus we cannot overload qDebug. qLog is just a name. It's the name this code had when it was in Qtopia but it's hardly important if it keeps this name. It would be nice to focus on the implementation of the feature to make sure it is sound before we worry overly much about what to call it :) Sure, but names still matter for a public API . Here's another idea: // in qlogging.h void qMessageLogEnabled(const char *area) #define QMessageArea(area) if (qMessageLogEnabled(area)) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO, area) Usage would be e.g. QMessageArea(MyArea).debug() expensiveFunc(); QMessageArea(MyArea).warning(%s, expensiveFunc()); Regards Kai -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] kdelibs partially ported to Qt5
Torsdag 2. februar 2012 22.30.52 skrev ext Stephen Kelly: Hi there, I ported some of kdelibs to Qt5 (just the easy stuff). Awesome :) There are also some accessibility enums that have been removed, and I don't know how to port away from (or what to port to). They didn't make sense and should simply be dropped. All references I could find in the KDE codebase were genereated code for bindings. (QEvent::AccessibilityPrepare, Help and Description) Please let me know if you found some other place where they were used in a sensible fashion. I would be really surprised though. Cheers Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JIRA bug management: users can't close their 'assigned' bugs.
On Tuesday 14 February 2012 11:13:41 Frederik Gladhorn wrote: I think this mail raises a good point. We are very protective of our bugs, maybe it's the time to reconsier jira rights now that we have the Qt Project in full swing :) I think it would be great if we could get a group of bug triagers started, for KDE for example that leads to fewer stale bugs and new contributors that discover they can fix bugs while triaging them. In order to enable that we would actually have to start giving jira rights to people. I don't think there is much reason to expect people would be mis-using these. We just want to protect simple users that just want to raise the priority of the bug they report. I think permissions should be given to anyone who requests them with intentions to contribute. And any approver should be able to give easily permissions to another user. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JIRA bug management: users can't close their 'assigned' bugs.
On Tue, Feb 14, 2012 at 7:13 AM, Frederik Gladhorn frederik.gladh...@nokia.com wrote: I think this mail raises a good point. We are very protective of our bugs, maybe it's the time to reconsier jira rights now that we have the Qt Project in full swing :) I think it would be great if we could get a group of bug triagers started, for KDE for example that leads to fewer stale bugs and new contributors that discover they can fix bugs while triaging them. In order to enable that we would actually have to start giving jira rights to people. I don't think there is much reason to expect people would be mis-using these. And those who are doing it can get their rights revoked (but the account being still active). Cheers Frederik Mandag 6. februar 2012 01.04.55 skrev ext Rick Stockton: Hi everyone, I have a number of stale bugs which need to be closed. When bugs are Assigned, even to Earth Domain, the original reporter is unable to close them. SO, for the purpose of removing bad data from our DB, I'm requesting help with the following bugs. I'm the reporter/creator of in all cases: https://bugreports.qt-project.org/browse/QTBUG-19793 (some work on mouse buttons in 4.x, which we put into 5.0 instead. Change to CLOSED/REJECTED) https://bugreports.qt-project.org/browse/QTBUG-22642 (Qt5 mouse buttons in XLIB and XCB, Resolved. Fixed in Qt 5.0.0) https://bugreports.qt-project.org/browse/QTBUG-22642 (bad idea, should be CLOSED/REJECTED. Note: Current assignee is Oliver Goffart, but the bad idea was mine ;) https://bugreports.qt-project.org/browse/QTBUG-22338 (change to CLOSED/REJECTED). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JIRA bug management: users can't close their 'assigned' bugs.
On 14/02/2012 04:13, ext Frederik Gladhorn wrote: I think this mail raises a good point. We are very protective of our bugs, maybe it's the time to reconsier jira rights now that we have the Qt Project in full swing :) I think it would be great if we could get a group of bug triagers started, for KDE for example that leads to fewer stale bugs and new contributors that discover they can fix bugs while triaging them. In order to enable that we would actually have to start giving jira rights to people. I don't think there is much reason to expect people would be mis-using these. Please have a look at the Changes to the Jira roles and workflow thread, which was started on 08.02.2012. I guess many have missed that email, because discussions are much slower than I expected. But that mail discusses recommended changes to Jira. If you have opinions on that matter, please discuss it on that thread. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Schedule for Qt 4.8.1
On 2/14/12 12:45 PM, ext Olivier Goffart oliv...@woboq.com wrote: 2) Will there be a release branch, like there was with previous version of Qt? (Which let a bit of time to stabilize the actual release by cherry-picking only showstopper) There was none with Qt 4.8.0, why? Can't comment to the future of the release branch, but it didn't exist with 4.8.0, while the plan was to get 4.8 in such shape that it would be always releasable. By achieving that the patch release would have been only a snapshot form master (like the 4.8.0 actually was). And I dare to say that even if we would have the release branch with 4.8.0 it wouldn't have been out any time sooner than it actually was. Simo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] kdelibs partially ported to Qt5
On Tuesday, February 14, 2012 11:23:19 Frederik Gladhorn wrote: Torsdag 2. februar 2012 22.30.52 skrev ext Stephen Kelly: Hi there, I ported some of kdelibs to Qt5 (just the easy stuff). Awesome :) There are also some accessibility enums that have been removed, and I don't know how to port away from (or what to port to). They didn't make sense and should simply be dropped. All references I could find in the KDE codebase were genereated code for bindings. (QEvent::AccessibilityPrepare, Help and Description) Please let me know if you found some other place where they were used in a sensible fashion. I would be really surprised though. See 10ba1368d649e6e60f5580127ec0faa217b47cc8 in kdelibs. The ones I ifdefed out were in kjsembed.I don't know if that's what you meant when you said 'genereated code for bindings'? I didn't find any others while porting the rest of kdelibs or kdepimlibs so far. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QT_NO_CAST_FROM_ASCII for platformsupport
Hi, what is the reason for DEFINES += QT_NO_CAST_FROM_ASCII in the platformsupport.pro file? I just hit that and would like to understand why we have this inconvenience here. Cheers, Johannes ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
- Original Message -
From: kai.koe...@nokia.com kai.koe...@nokia.com
-Original Message-
From: development-bounces+kai.koehne=nokia@qt-project.org
[mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
Behalf Of Ramsay Lincoln (Nokia-MP/Brisbane)
Sent: Monday, February 13, 2012 1:33 AM
To: development@qt-project.org
Subject: Re: [Development] QLog ( Work on qDebug and friends)
On 02/11/2012 01:44 AM, ext kai.koe...@nokia.com wrote:
However, adding yet another 'keyword' to the framework has a
price,
especially since the difference between
'qDebug(QMessageLogContext(MyCategory))'
and a
'qLog(MyCategory) ' is subtle.
We tried that but while this difference is subtle to the eye, it's a
huge difference to the implementation.
qDebug is currently an argument-less macro that expands to the name of a
function. Before message logging it was just a plain old function.
Overloading means that qDebug(message) and qDebug()
message
both
work.
Since we can't have a macro func with 0, 1 or many arguments, we can
only add a new overload for qDebug(category) message
but if we do
this, there is nowhere to put the do nothing quickly logic.
Just wanted to point out that there are variadic macros:
http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
#define qCategoryDebug(category, ...) if (isLogEnabled(category))
QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO).debug(__VA_ARGS__)
Seems to work with at least gcc4.2.1 and Visual studio 2010.
But that doesn't help with the fact that we can't differentiate between
'qDebug()', 'qDebug(Hello world)', and
'qDebug(MyCategory)' on the macro level.
That depends on implementation. It does allow you take all those args and pass
them over to other function easily.
And if all categories have to be registered, then you can add a check against
the registration for it:
..
qLogRegisterCategory(my category);
...
qDebug(my category,...);
...
qDebug(...);
...
#define qDebug(category,...) \
if (qLogIsCategory(category)) \
if (qIsLogEnabled(category)) \
QMessageLogger(__FILE,__LINE__, Q_FUNC_INFO,
category).debug(__VAR__ARGS__) \
else {} \
else QMessageLogger(__FILE,__LINE__,
Q_FUNC_INFO).debug(category,##__VAR__ARGS__)
Ben
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT_NO_CAST_FROM_ASCII for platformsupport
On terça-feira, 14 de fevereiro de 2012 15.03.34, Olivier Goffart wrote: On Tuesday 14 February 2012 13:50:06 Johannes Zellner wrote: Hi, what is the reason for DEFINES += QT_NO_CAST_FROM_ASCII in the platformsupport.pro file? I just hit that and would like to understand why we have this inconvenience here. Ok, i don't know the specific on why it is there in platform support. The rest of Qt just has QT_ASCII_CAST_WARNINGS Actually, there are many parts of Qt with QT_NO_CAST_FROM_ASCII: $ git grep QT_NO_CAST_FROM_ASCII -- mkspecs src/\*.pr? | cat src/platformsupport/platformsupport.pro:DEFINES += QT_NO_CAST_FROM_ASCII src/plugins/platforms/windows/windows.pro:DEFINES *= QT_NO_CAST_FROM_ASCII src/plugins/sqldrivers/qsqldriverbase.pri:DEFINES += QT_NO_CAST_TO_ASCII QT_NO_CAST_FROM_ASCII src/sql/sql.pro:DEFINES += QT_NO_CAST_FROM_ASCII src/testlib/testlib.pro:QT_NO_CAST_FROM_ASCII \ src/tools/bootstrap/bootstrap.pri:QT_NO_CAST_FROM_ASCII \ src/tools/bootstrap/bootstrap.pro:QT_NO_CAST_FROM_ASCII \ Having it enabled is a good reason because: Anyway, casting from char* to QString must be avoided on library code. the reason: if you have QString foo = file.readAll(); This compile fine, and even look right, but might be wrong. because a char* do not say anything about the encoding. Is it latin1, utf8, other? So Qt provide QTextCodec::codecForCString. Not for long :-) http://codereview.qt-project.org/14626 There is also QTextCodec::codecForLocale used by QString::fromLocal8Bit. For example, in a french programing team, you would have label-setText(Résultats Erronés); And this will probably be in latin1, because the file is saved as such on the disc. (and latin1 is faster than utf8). And they'll have to recode their sources to UTF-8 with Qt 5, or add the wrapping QLatin1String. So if in your library you do QString foo = file.readAll(); The result will depends on the application. With Qt 5, it will not. It will be decoded using UTF-8, which is good and bad: Good: because it's well-defined and you know what will happen. Bad: because if you have binary data, UTF-8 cannot decode it. ISO-8859 can decode anything to Unicode, so it's idempotent in a round-trip. UTF-8 isn't, so if you mix QString and QByteArray by mistake, you might cause data corruption. So the rule is: - Always be explicit about which encoding you import the string from. - If it is a literal, use QStringLiteral in 95% of the case, and QLatin1String in most of th e other cases. We need to document when to use either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
-Original Message-
From: development-bounces+kai.koehne=nokia@qt-project.org
[mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
Behalf Of ext BRM
Sent: Tuesday, February 14, 2012 3:00 PM
To: development@qt-project.org
Subject: Re: [Development] QLog ( Work on qDebug and friends)
- Original Message -
From: kai.koe...@nokia.com kai.koe...@nokia.com
-Original Message-
From: development-bounces+kai.koehne=nokia@qt-project.org
[mailto:development-bounces+kai.koehne=nokia@qt-project.org]
On
Behalf Of Ramsay Lincoln (Nokia-MP/Brisbane)
Sent: Monday, February 13, 2012 1:33 AM
To: development@qt-project.org
Subject: Re: [Development] QLog ( Work on qDebug and friends)
On 02/11/2012 01:44 AM, ext kai.koe...@nokia.com wrote:
However, adding yet another 'keyword' to the framework has a
price,
especially since the difference between
'qDebug(QMessageLogContext(MyCategory))'
and a
'qLog(MyCategory) ' is subtle.
We tried that but while this difference is subtle to the eye, it's a
huge difference to the implementation.
qDebug is currently an argument-less macro that expands to the name
of a function. Before message logging it was just a plain old function.
Overloading means that qDebug(message) and qDebug()
message
both
work.
Since we can't have a macro func with 0, 1 or many arguments, we can
only add a new overload for qDebug(category) message
but if we do
this, there is nowhere to put the do nothing quickly logic.
Just wanted to point out that there are variadic macros:
http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
#define qCategoryDebug(category, ...) if (isLogEnabled(category))
QMessageLogger(__FILE__, __LINE__,
Q_FUNC_INFO).debug(__VA_ARGS__)
Seems to work with at least gcc4.2.1 and Visual studio 2010.
But that doesn't help with the fact that we can't differentiate
between 'qDebug()', 'qDebug(Hello world)', and 'qDebug(MyCategory)'
on the macro level.
That depends on implementation. It does allow you take all those args and
pass them over to other function easily.
And if all categories have to be registered, then you can add a check against
the registration for it:
..
qLogRegisterCategory(my category);
...
qDebug(my category,...);
...
qDebug(...);
...
#define qDebug(category,...) \
if (qLogIsCategory(category)) \
if (qIsLogEnabled(category)) \
QMessageLogger(__FILE,__LINE__, Q_FUNC_INFO,
category).debug(__VAR__ARGS__) \
else {} \
else QMessageLogger(__FILE,__LINE__,
Q_FUNC_INFO).debug(category,##__VAR__ARGS__)
Nice, though it'll break with
qDebug() Hi there;
too few arguments to function bool qLogIsCategory(const char*)
Also this won't work:
qDebug(category) HI there;
expected primary expression before the '' token.
:(
Regards
Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Something is wrong in QFontEngineFT::loadGlyph
Hi Mark, On Feb 14, 2012, at 12:03 AM, ext Mark wrote: While using Qt's elidedText function http://developer.qt.nokia.com/doc/qt-4.8/qfontmetricsf.html#elidedText i noticed the function was dog slow. For just 1000 entries (each 250 chars) eliding them to 200px took about 190ms on windows and 100ms on linux. Using that for drawing is noticeable slow. I haven't actually tried that, but i certainly would notice that and in the longer run that is my intention. So, i started playing with it in an attempt to get it blazing fast. And i got there. On windows i have a speedup of 39x (same job only takes 5ms) and on Linux i got a speedup of 10x (same job takes 10ms, side effect is that linux while 10x faster is now slower then windows.. odd), Those speedups are nice but it tasted like more so i went on to profilling. I already knew the QFontMetricsF::width was the function dragging everything down and a kcachegrind seems to indicate the same. Note for the speedups, i got them mostly by cashing the width of the used character thus avoiding the width function as much as possible. This is the path that width() takes till the point of calling the freetype functions: QFontEngineFT::stringToCMap QFontEngineFT::recalcAdvances QFontEngineFT::loadGlyph loadGlyph is where i think something odd is going on. http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line812 Note the last parameter: fetchMetricsOnly ... The path it took had fetchMetricsOnly set to true : http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line1611. That leads me to think that this function is only going to fetch the metrics of the glyph, not render it! The opposite is the case. It's rendering it and that is the part that takes long. So, am i right here? Is this function doing to much? Remember, we come from the width() function. All we actually need is the width of the glyph, that's it. Actually, if you look in that function for the fetchMetricsOnly occurrence you'll see that it's only used in one place and there it doesn't seem to do a lot with metrics. It kinda looks like the original implementer of this has some idea, but never finished implementing it. Or am i wrong here? Your guess is mostly correct. This fetchMetricsOnly flag was added a while ago (Nov 5, 2008) to suppress a warning message but it's actually useful to avoid doing rendering in that case. I think we should change (set-outline_drawing fetchMetricsOnly) to (set-outline_drawing || fetchMetricsOnly) if not regression is caused. How is that working for you? - Jiang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Sporadic QFileSystemWatcher autotest fails on Windows (was: https://bugreports.qt-project.org/browse/QTBUG-24029 unstable)
Hi, (CCing the list so there's a record of this in future) On Tue, Feb 14, 2012 at 4:08 PM, Friedemann Kleint friedemann.kle...@nokia.com wrote: Hi, we are currently looking at the autotests on Windows and noticed that the file watcher autotest has become unstable. In the test removeFileAndUnWatch(): QVERIFY(watcher.addPath(filename)); QFile::remove(filename); QVERIFY(watcher.removePath(filename)); the removing fails non-deterministically. The reason is apparently that after the file deletion, the notification thread kicks in and removes the deleted file path from the handle map. This could be a consequence of the thread change? Ah, of course, I didn't anticipate that. I think it would have always happened, but previously, return values for add/removePath didn't exist though, so they weren't checked of course. I think it's probably safe enough to just stop checking removePath's return value in QVERIFY there (plus a comment, noting this issue). I'd expect the behaviour, I just didn't think of it when adding checking of add/removepath calls... Anyways, I am wondering if the behaviour is to be expected, or, what is the test supposed to test? [In addition, I created http://codereview.qt-project.org/#change,16313 to rule out all other influences]. Thanks for that, commented on it already before I saw this mail :] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
From: kai.koe...@nokia.com kai.koe...@nokia.com
To: bm_witn...@yahoo.com; development@qt-project.org
Cc:
Sent: Tuesday, February 14, 2012 9:31 AM
Subject: RE: [Development] QLog ( Work on qDebug and friends)
-Original Message-
From: development-bounces+kai.koehne=nokia@qt-project.org
[mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
Behalf Of ext BRM
Sent: Tuesday, February 14, 2012 3:00 PM
To: development@qt-project.org
Subject: Re: [Development] QLog ( Work on qDebug and friends)
- Original Message -
From: kai.koe...@nokia.com kai.koe...@nokia.com
-Original Message-
From: development-bounces+kai.koehne=nokia@qt-project.org
[mailto:development-bounces+kai.koehne=nokia@qt-project.org]
On
Behalf Of Ramsay Lincoln (Nokia-MP/Brisbane)
Sent: Monday, February 13, 2012 1:33 AM
To: development@qt-project.org
Subject: Re: [Development] QLog ( Work on qDebug and friends)
On 02/11/2012 01:44 AM, ext kai.koe...@nokia.com wrote:
However, adding yet another 'keyword' to the
framework has a
price,
especially since the difference between
'qDebug(QMessageLogContext(MyCategory))'
and a
'qLog(MyCategory) ' is subtle.
We tried that but while this difference is subtle to the eye,
it's a
huge difference to the implementation.
qDebug is currently an argument-less macro that expands to the
name
of a function. Before message logging it was just a plain old
function.
Overloading means that qDebug(message) and qDebug()
message
both
work.
Since we can't have a macro func with 0, 1 or many arguments,
we can
only add a new overload for qDebug(category)
message
but if we do
this, there is nowhere to put the do nothing quickly
logic.
Just wanted to point out that there are variadic macros:
http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
#define qCategoryDebug(category, ...) if (isLogEnabled(category))
QMessageLogger(__FILE__, __LINE__,
Q_FUNC_INFO).debug(__VA_ARGS__)
Seems to work with at least gcc4.2.1 and Visual studio 2010.
But that doesn't help with the fact that we can't
differentiate
between 'qDebug()', 'qDebug(Hello world)',
and 'qDebug(MyCategory)'
on the macro level.
That depends on implementation. It does allow you take all those args and
pass them over to other function easily.
And if all categories have to be registered, then you can add a check
against
the registration for it:
..
qLogRegisterCategory(my category);
...
qDebug(my category,...);
...
qDebug(...);
...
#define qDebug(category,...) \
if (qLogIsCategory(category)) \
if (qIsLogEnabled(category)) \
QMessageLogger(__FILE,__LINE__, Q_FUNC_INFO,
category).debug(__VAR__ARGS__) \
else {} \
else QMessageLogger(__FILE,__LINE__,
Q_FUNC_INFO).debug(category,##__VAR__ARGS__)
Nice, though it'll break with
qDebug() Hi there;
too few arguments to function bool qLogIsCategory(const char*)
Except the Hi there will be the 'category' part, so it'll be passed to
qLogIsCategory(), which should return false and then cause the last else to be
followed.
Also this won't work:
qDebug(category) HI there;
expected primary expression before the '' token.
Personally, I'd advocate against that any how. I'd much rather see a Category
object being pushed via operator() instead so that it can be detected and
allow things like:
// assume QMessageLoggerCategory(category) is a class
qDebug() QMessageLoggerCategory(category1) message for category1
QMessageLoggerCategory(category2) message for category2;
But that's me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
-Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Thiago Macieira Sent: 13 February 2012 19:27 To: development@qt-project.org Subject: Re: [Development] Default enabling inbound flow control on sockets As you said yourself, there's a huge potential for regressions here, especially with a limit as low as 64k. So I am unsure whether we should do this at all. We could apply a high buffer size, like 1 MB. That's probably enough to contain most data files being downloaded and yet avoid exploding by OOM. On a modern embedded system, an application would need to be downloading 50 items in parallel (which means from at least 9 different servers) before it started to get into trouble. I'm also not convinced we should do this yet, but some more thoughts on the subject. When using the high level (QNetworkReply) API, you are dealing with objects. Intuitively, downloading a 100MB file will allocate 100MB of memory unless you take steps to prevent this. You might get more or less data than you were expecting, if the object on the server has changed. Regressions are likely, because downloading a complete object and then processing it would be a common usage. When using the low level (QTcpSocket) API, you are dealing with a stream. Intuitively, you would expect the stream applies flow control and rate limiting by itself. If using native apis (either synchronous or asynchronous) on all platforms, this is what happens. The exact amount of buffering in the OS level varies between platforms. With QTcpSocket, this does not happen, because Qt reads all available data from the OS into its own buffers each time the event loop runs socket notifiers. Regressions are less likely, because socket using code is normally processing the stream as it arrives. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Something is wrong in QFontEngineFT::loadGlyph
On Tue, Feb 14, 2012 at 4:03 PM, jiang.ji...@nokia.com wrote: Hi Mark, On Feb 14, 2012, at 12:03 AM, ext Mark wrote: While using Qt's elidedText function http://developer.qt.nokia.com/doc/qt-4.8/qfontmetricsf.html#elidedText i noticed the function was dog slow. For just 1000 entries (each 250 chars) eliding them to 200px took about 190ms on windows and 100ms on linux. Using that for drawing is noticeable slow. I haven't actually tried that, but i certainly would notice that and in the longer run that is my intention. So, i started playing with it in an attempt to get it blazing fast. And i got there. On windows i have a speedup of 39x (same job only takes 5ms) and on Linux i got a speedup of 10x (same job takes 10ms, side effect is that linux while 10x faster is now slower then windows.. odd), Those speedups are nice but it tasted like more so i went on to profilling. I already knew the QFontMetricsF::width was the function dragging everything down and a kcachegrind seems to indicate the same. Note for the speedups, i got them mostly by cashing the width of the used character thus avoiding the width function as much as possible. This is the path that width() takes till the point of calling the freetype functions: QFontEngineFT::stringToCMap QFontEngineFT::recalcAdvances QFontEngineFT::loadGlyph loadGlyph is where i think something odd is going on. http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line812 Note the last parameter: fetchMetricsOnly ... The path it took had fetchMetricsOnly set to true : http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line1611. That leads me to think that this function is only going to fetch the metrics of the glyph, not render it! The opposite is the case. It's rendering it and that is the part that takes long. So, am i right here? Is this function doing to much? Remember, we come from the width() function. All we actually need is the width of the glyph, that's it. Actually, if you look in that function for the fetchMetricsOnly occurrence you'll see that it's only used in one place and there it doesn't seem to do a lot with metrics. It kinda looks like the original implementer of this has some idea, but never finished implementing it. Or am i wrong here? Your guess is mostly correct. This fetchMetricsOnly flag was added a while ago (Nov 5, 2008) to suppress a warning message but it's actually useful to avoid doing rendering in that case. I think we should change (set-outline_drawing fetchMetricsOnly) to (set-outline_drawing || fetchMetricsOnly) if not regression is caused. How is that working for you? - Jiang Right, tested it now. fixing this seems to make the loadGlyph function about 4x faster! My test app gets twice as fast with it. It now does the test as described in my first post in just a mere 5ms. Could someone please patch this in Qt (4.8.x as well?).. I don't have an account for review/commit stuff. Feel free to commit :) Just to be sure, change: if (set-outline_drawing fetchMetricsOnly) to if (set-outline_drawing || fetchMetricsOnly) That's it. Kind regards, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Something is wrong in QFontEngineFT::loadGlyph
On Tue, Feb 14, 2012 at 7:44 PM, Robin Burchell robin...@viroteck.netwrote: Hi Mark, 2012/2/14 Mark mark...@gmail.com: Could someone please patch this in Qt (4.8.x as well?).. I don't have an account for review/commit stuff. Feel free to commit :) I'd strongly suggest you just set yourself up to do it. Then you get all of the credit (and all of the blame...) and you're ready to submit any future changes you want to make too. http://wiki.qt-project.org/Code_Reviews provides a list of steps to walk you through getting set up. On a seperate topic, I don't think this would meet the criteria for 4.8 - especially with 4.8.1 getting closer. Though I note that http://wiki.qt-project.org/Submit_Policies doesn't really mention what state 4.8 is in. :) Thank you for the info. I kinda try to avoid to go to Qt 5 git since Qt5 is so extremely different (in technical terms) compared to Qt4 .. I can't just do a test compile for that, i have to set it up, get my test project working, re-confirm the issue is still there.. It's really easier if an existing Qt5 dev could take this one liner and push it. When Qt5 is out and mainstream things like this will be far easier. And by that time i will go through the official channels to submit a patch, however this time i have to leave it to anyone on the list willing to pick it up. Regards, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
On terça-feira, 14 de fevereiro de 2012 17.51.33, shane.kea...@accenture.com
wrote:
When using the low level (QTcpSocket) API, you are dealing with a stream.
Intuitively, you would expect the stream applies flow control and rate
limiting by itself. If using native apis (either synchronous or
asynchronous) on all platforms, this is what happens. The exact amount of
buffering in the OS level varies between platforms. With QTcpSocket, this
does not happen, because Qt reads all available data from the OS into its
own buffers each time the event loop runs socket notifiers. Regressions are
less likely, because socket using code is normally processing the stream as
it arrives.
Agreed. I think this applies more to QTcpSocket than to QNetworkReply.
But I'd still use a higher value for the buffer size. The kernel buffer size on
Windows is 48k and on Linux it can reach 128k. Also note the very common way
that people use QDataStream over QTcpSocket, which is:
void Class::readyReadSlot()
{
QDataStream stream(this);
if (size == -1 bytesAvailable() = sizeof(size))
stream buffer;
if (size bytesAvailable())
return;
// read using stream here
}
So the question is: what type is most recommended for the size variable?
What's the average size of the datastream packet?
To be honest, I'd also like to replace QDataStream with stream that did that
understood incomplete data (like QXmlStreamReader does).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Variadic Macros in Qt? - Re: QLog ( Work on qDebug and friends)
On 02/14/2012 08:22 PM, Koehne Kai (Nokia-MP/Berlin) wrote: Just wanted to point out that there are variadic macros I'm aware of this but last time I checked, they weren't in the C++ standard. It seems they're new to C99 and C++11. Grepping over the Qt 5 sources reveals no variadic macros in Qt, though a few exist in third party bundled code. I'm not in a position to say we can use variadic macros in QtCore which is why I didn't actually try to do that. If someone who knows about supported platforms and variadic macro support in compilers can clarify that we can use variadic macros in Qt, then we can see if we can actually use variadic macros to differentiate between: qDebug(message); qDebug() message; qDebug(CAT) message; Where the last one expands to if (do_nothing); else debug() -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On 02/15/2012 01:47 AM, ext BRM wrote: I'd much rather see a Category object being pushed via operator() instead so that it can be detected and allow things like: // assume QMessageLoggerCategory(category) is a class qDebug() QMessageLoggerCategory(category1) message for category1 QMessageLoggerCategory(category2) message for category2; This fails the do nothing quickly test so the cost of leaving such statements in shipping code is high, even when the categories are disabled. This works fine though. qLog(category1) message for category1; qLog(category2) message for category2; -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On 02/14/2012 08:22 PM, Koehne Kai (Nokia-MP/Berlin) wrote: Here's another idea: // in qlogging.h void qMessageLogEnabled(const char *area) #define QMessageArea(area) if (qMessageLogEnabled(area)) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO, area) Usage would be e.g. QMessageArea(MyArea).debug() expensiveFunc(); QMessageArea(MyArea).warning(%s, expensiveFunc()); Supporting both debug and warning statements tied to a category isn't useful. Warnings have always been unconditional and will remain so. Removing that from your example gives almost the same syntax as qLog but with a different name and I think I've covered that already :) -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Changing qreal to a float
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, OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require the precision offered by double precision floating point. - Predictable behavior on across desktop and device. In the past we have had a few cases where things fell apart when run on embedded because the reduced precision. These were fixed, but they would have been immediately caught during development if they were the same. - For specific use cases were higher precision floats are required, double can still be used. Both inside and outside the Qt libraries. 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://bugreports.qt-project.org/browse/QTBUG-23758) 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 is no worse (for device) than it already is, so any use case that fails and needs work will now be found early in the development cycle as opposed to during device testing. Unless there are any objections that I have not yet covered, I will go ahead with this change. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Schedule for Qt 4.8.1
On 14.2.2012 12.45, Olivier Goffart oliv...@woboq.com wrote: On Monday 13 February 2012 12:28:06 Turunen Tuukka wrote: Hi All, We would like to release next version of Qt Commercial 4.8 around mid-March. It would be really great if we can again sync the LGPL and Commercial releases both in timing and content to the extent possible. If we agree that mid-March is a good target time for the next patch release, we should have as much as possible all the fixes in by end of February. Naturally a patch release will not have any new features, but there are some fixes that we are very much targeting to be in 4.8.1 such as ones needed for publishing apps in the Mac App Store. Since 4.8 was moved to gerrit, we have been actively redoing our merge requests, and quite much has already been merged into the 4.8 branch. Yours, Hi, not really related, but here are some question that I have regarding 4.8.x I think this discussion is better to continue in the releasing mailing list, but here are some answers from me. 1) What are the planed differences between the open source and the comercial in 4.8.1? There are no specifically planned differences in the essential functionality. We have been contributing the pending items via new system, and many are already in. My assumption is that there will be less items than in 4.8.0, depending which of our changes are accepted into LGPL version. Most likely the delta will be biggest on RTOS platforms, as well as some fixes for desktop that are important for our customers, but not necessarily such that the module maintainers want to have in the open source version. 2) Will there be a release branch, like there was with previous version of Qt? (Which let a bit of time to stabilize the actual release by cherry-picking only showstopper) There was none with Qt 4.8.0, why? If there is one, when? My opinion is that a branch is needed somewhere to do the work, but after the release is done, that branch is not needed any more. But this item specifically should be decided by those who do the work. 3) Usually, since a lot of bugs are found in a x.y.0 release, the x.y.1 comes quickly after (less than 2 months). Mid march is 4 months after 4.8.0 (Yes, that's more a fact than a qustion) 4.8.0 was actually quite a good release, at least from our viewpoint. Not perfect, nothing is, but quite well received on average. 4) Who is the responsible for the Qt 4.8.x releases? I do not think the Qt Project has yet decided on who is responsible for what, and how releases are done. We are glad to help, as we are anyway making the releases for commercial licensees. 5) Was there a post mortem after 4.8.0 release? (What went good, what went bad?) How is the feedback after the release? How stable is that minor release compared to other ones? I have not seen one done on Qt Project level. Naturally different parties have done their own testing. At least for 5.0 such a post mortem would be good to have. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
