[Development] (long) thoughts on categorized logging (qLog)
Hi all,
There seems to be some confusion over what qLog is and is not. I suspect
that the direction was perhaps mis-aligned slightly. Please allow me to
try to summarize things. This is more of a vision thing and in writing
this, parts of the implementation have been identified that should be
updated. Writing this led to much discussion here, this represents
something we are happy with and I'm hoping it matches the expectations
of others too. Note that some different names are being proposed here,
the changes to functionality suggested the names but as before, they're
not set in stone yet.
First a mission statement:
The categorized logging feature is intended as a replacement for qDebug
and qWarning. With logging statements in an app/library, a developer can
turn on the statements they care about and turn off the ones they don't.
They can do all this without re-compiling the app and in some cases,
without restarting the app. The categorized logging feature is intended
to have as small an impact as possible until it has been explicitly enabled.
The categorized logging feature is made up of several parts.
PART 1: The logging statements.
To keep the code compact (and for performance reasons), categories are
identified locally by a short (locally-unique) token. The short tokens
are mapped onto longer, (globally-unique) identifiers. Categories must
be declared before use.
QT_LOG_CATEGORY(PLUGIN, "com.nokia.qt.plugins")
For a library, I'd expect to see a header that declares the categories
used by that library but it's also possible to just drop the macro in
the top of .cpp files as required. (impl detail: might need a "declare"
and a "implement" macro for libs to avoid duplicate symbols)
The actual logging statements use the category token.
qCDebug(PLUGIN) << "Scanning for plugins in" << paths;
qCWarning(PLUGIN) << "Could not load plugin" << loader->errorString();
As can be seen, we're differentiating between debug (defualt off) and
warning (default on) statements. To identify these when turning
categories on/off there is a .debug or .warning suffix added to the
identifier (more on this later).
It's important to note that logging statements should not have side
effects because they may not be called.
PART 2: Compatibility with qDebug/qWarning
qDebug() and qWarning() will be re-implemented as categorized logging
statements. Both will use the same, hard-coded category.
qDebug() << "debug";
qWarning() << "warning";
Is almost equivalent to:
QT_LOG_CATEGORY(LEGACY, "legacy")
qCDebug(LEGACY) << "debug";
qCWarning(LEGACY) << "warning";
I say "almost equivalent" because qDebug() defaults on (while
categorized debugs default off).
The older qDebug("debug") and qWarning("warning") syntax will also work
and will be treated the same way.
For display purposes, qFatal will also have a category but it won't be
influenced by the logging configuration.
PART 3: Turning statements on/off.
As mentioned, debug statements (except for qDebug) default off and
warning statements default on. Logging statements can be enabled or
disabled using rules. Rules specify a category identifier, optionally
using a global-style * to match multiple categories.
eg.
# Turn on Qt plugin debug
com.nokia.qt.plugins.debug = true
# Turn off network warnings
com.nokia.qt.network.warning = false
# Turn on all webkit debug
org.webkit.*.debug = true
# Turn off all legacy qDebug/qWarning
legacy.* = false
For apps that want to provide a UI for logging and for future expansion
possibilities (eg. add-ons that allow turning logging on/off via some
novel means), there will be a C++ API to set the rules.
qSetCategoryRules(const QByteArray &rules);
However, since there are likley to be many apps that don't care about
logging (or may not expose a way to turn on logging in a third party
library) there will also be a text-based config file that the user can
create. Where should this file be located? Either the app sets the
location of this file by calling qSetLoggingConfigFile() or the user
sets the QT_LOGGING_CONFIG environment variable (which overrides the
app's default). If the config file exists, the C++ API has no effect.
QFileWatcher will be used to monitor the config file so that categories
can be turned on/off while the program is running by updating the file.
PART 4: Formatting.
There's a %{category} entry that can appear in the format string. This
will be in the default format string.
PART 5: Saving logs to a file.
As a special case, the user can direct enabled messages to a file. This
is done from the config file.
# write output to a file (in the user's home directory)
logging.output.file = file.txt
# write output to a specific file
logging.output.file = /path/to/file.txt
# write output.file to a specific file on Windows
logging.output.file = c:\log.txt
# this is the default (output goes to message handler or file, not both)
logging.output.both = false
# write to both the file and
Re: [Development] QLog ( Work on qDebug and friends)
OK, So we've now 2 options to set the config file. 1. QLOG_CONFIG_FILE environment variable 2. setDefaultConfigFile function. What do you mean with: ... and to supplying a QIODevice*? 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: Tuesday, February 21, 2012 6:30 PM To: development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) On terça-feira, 21 de fevereiro de 2012 07.15.48, wolfgang.b...@nokia.com wrote: > 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. I don't want this. Application names and organisation names change every now and then. The applications may know about their own settings and migrate those, but if we have hardcoded paths coming from inside QtCore, those will get lost in the move. Please restrict this to an environment variable and to supplying a QIODevice*. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
We had this discussion before in the ML to add cool stuff like Log into local socked, syslog or whatever. This can be done later in an AddOn for example. Cheers, 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: Tuesday, February 21, 2012 8:13 PM To: development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) On terça-feira, 21 de fevereiro de 2012 10.02.23, kai.koe...@nokia.com wrote: > So how about adding another QtMsgType called QLogMsg, that qLog() > uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would > not be processed by default, unless the configuration file (or an > environment > variable) says so ... That's almost a necessity. An informative message is not debugging. >From sys/syslog.h: #define LOG_EMERG 0 /* system is unusable */ #define LOG_ALERT 1 /* action must be taken immediately */ #define LOG_CRIT2 /* critical conditions */ #define LOG_ERR 3 /* error conditions */ #define LOG_WARNING 4 /* warning conditions */ #define LOG_NOTICE 5 /* normal but significant condition */ #define LOG_INFO6 /* informational */ #define LOG_DEBUG 7 /* debug-level messages */ We don't have EMERG and ALERT because Qt applications (often) aren't system applications and can't cause those conditions. And we don't have NOTICE or INFO because our message output was designed only for developer usage (from developers to other developers). That also reminds me: some systems would benefit from having our message output go to syslog. MeeGo had a patch that I wrote a long time ago that sent all messages to syslog. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
Why you want to use the categories somewhere else then QLog? You want to reinvent a mechanism to filter the categories then? If you don't filter what sense makes having the categories? I mean you still have qDebug and you can write whatever you like. Cheers, WB -Original Message- From: Koehne Kai (Nokia-MP/Berlin) Sent: Tuesday, February 21, 2012 8:20 PM To: ext David Faure Cc: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org Subject: RE: [Development] QLog ( Work on qDebug and friends) > -Original Message- > From: ext David Faure [mailto:david.fa...@kdab.com] > Sent: Tuesday, February 21, 2012 11:08 AM > To: Koehne Kai (Nokia-MP/Berlin) > Cc: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > On Tuesday 21 February 2012 10:02:23 kai.koe...@nokia.com wrote: > > I agree with that: On the desktop it's quite handy to see also > > detailed output on stderr/the shell (which one can redirect to a > > file if > needed). > > But I also think that qLog() messages shouldn't show up by default > > for normal users, that is, unless the category has been explicitly enabled. > > True. > > > So how about adding another QtMsgType called QLogMsg, that qLog() > > uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages > would > > not be processed by default, unless the configuration file (or an > > environment > > variable) says so ... > > Isn't the same information given by "a category is present in the > QMessageLogContext"? All qLog calls are forced to get a category, right? Right, but that would mean we can't use categories for anything except qLog. If we use categories solely for the purpose of filtering that's probably fine, but I personally also see some value in having them available as free text in the log, for all log QtMsgType's ... Regards Kai > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 > 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - > Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
Yes David, Absolutely right. B.R. WB -Original Message- From: ext David Faure [mailto:david.fa...@kdab.com] Sent: Tuesday, February 21, 2012 8:08 PM To: Koehne Kai (Nokia-MP/Berlin) Cc: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) On Tuesday 21 February 2012 10:02:23 kai.koe...@nokia.com wrote: > I agree with that: On the desktop it's quite handy to see also > detailed output on stderr/the shell (which one can redirect to a file if > needed). > But I also think that qLog() messages shouldn't show up by default for > normal users, that is, unless the category has been explicitly enabled. True. > So how about adding another QtMsgType called QLogMsg, that qLog() > uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would > not be processed by default, unless the configuration file (or an > environment > variable) says so ... Isn't the same information given by "a category is present in the QMessageLogContext"? All qLog calls are forced to get a category, right? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
> So how about adding another QtMsgType called QLogMsg, that qLog() uses? In > contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be processed > by default, unless the configuration file (or an environment variable) says > so ... There is no need for this Kai. The macro will not even create a QMessageLogger if the category is not enabled. Have a look in the qMessageFormatString of the QLog patch how I detect if I need to add a category or not. B.R. WB -Original Message- From: Koehne Kai (Nokia-MP/Berlin) Sent: Tuesday, February 21, 2012 8:02 PM To: ext David Faure; Beck Wolfgang (Nokia-MP/Brisbane) Cc: development@qt-project.org 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 David Faure > Sent: Tuesday, February 21, 2012 10:36 AM > To: Beck Wolfgang (Nokia-MP/Brisbane) > Cc: development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > > 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 still having the feature that you > > can activate it without recompiling the code. > > Why? IMHO things should go to stderr by default. So it makes perfect > sense to see the output, even if one didn't configure output files in a > config file. I agree with that: On the desktop it's quite handy to see also detailed output on stderr/the shell (which one can redirect to a file if needed). But I also think that qLog() messages shouldn't show up by default for normal users, that is, unless the category has been explicitly enabled. So how about adding another QtMsgType called QLogMsg, that qLog() uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be processed by default, unless the configuration file (or an environment variable) says so ... Kai > I guess this is a mobile platform vs desktop platform discussion. On a > mobile platform the logs are only useful if they go to a file, while > on the desktop the logs are useful also if they go to stderr, to get > them in a terminal or in the session log file. > > > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 > 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - > Platform-independent software solutions > > ___ > 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] QLog ( Work on qDebug and friends)
QLOG ENABLED I guess you misunderstood me. QLog is enabled ONLY if a config file was found. We have 3 ways to define the config file: 1. Default using application name configuration default path and organization name for the path 2. Application developer can call the QLog function "setDefaultConfigFile 3. Config file is defined in the environmane variable "QLOG_CONFIG_FILE". This logic was discussed in the mailing list. Please have a look at http://codereview.qt-project.org/#change,13226 QLogPrivate constructor in qlog.cpp. To be crystal clear: QLog | QLog Enabeld | Config File -- NO | no file defined NO | no file found YES | file found QLOG WIRTES INTO OUTPUT FILE OR STDERR If you don't specify "OutputFile" in the QLog config file or the environment variable "QLOG_CONFIG_FILE" the output will be stderr (default). ONLY if you specify the "OutputFile" key file or the environment variable "QLOG_CONFIG_FILE" QLog will write into that file. We assume for the next table that QLog is enabled. QLog | QLog| QLog Config | Writes Into output file | Writes into stderr | OutputFile defined | - No| Yes | No | Yes | No | Yes | Hope that makes it clear now. Seems that QLog code is a little hard to read so I will add a lots of commends in there :). Cheers, WB -Original Message- From: ext David Faure [mailto:david.fa...@kdab.com] Sent: Tuesday, February 21, 2012 7:36 PM To: Beck Wolfgang (Nokia-MP/Brisbane) Cc: development@qt-project.org Subject: Re: [Development] QLog ( Work on qDebug and friends) On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > 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 still having the feature that you can activate it > without recompiling the code. Why? IMHO things should go to stderr by default. So it makes perfect sense to see the output, even if one didn't configure output files in a config file. I guess this is a mobile platform vs desktop platform discussion. On a mobile platform the logs are only useful if they go to a file, while on the desktop the logs are useful also if they go to stderr, to get them in a terminal or in the session log file. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mirror of Qt on github?
Holger Hans Peter Freyther said: > Hi, > > my jenkins build server is having a lot of build issues due of gitorious.org > not being able to serve via the git protocol (git-daemon). One of the latest > failures can be seen here[1]. Should we try to have Gerrit replicate to > github.com or any other more reliable git hosting provider? > It may be a good idea to set up your own local (polling) git mirror and point your jenkins towards that. In our experience from when v8 was hosted on github.com, that service also has reliability problems occasionally. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Mirror of Qt on github?
Hi, my jenkins build server is having a lot of build issues due of gitorious.org not being able to serve via the git protocol (git-daemon). One of the latest failures can be seen here[1]. Should we try to have Gerrit replicate to github.com or any other more reliable git hosting provider? holger [1] http://qt-jenkins.moiji-mobile.com/jenkins/job/QtBase/label=FreeBSD_amd64,releasetype=debug/174/console ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
> From: Olivier Goffart
> On Tuesday 21 February 2012 14:03:26 Marc Mutz wrote:
>> On Tuesday February 21 2012, Marc Mutz wrote:
>> > On Tuesday February 21 2012, Marc Mutz wrote:
>> > > Hi,
>> > >
>> > > The QString header contains a ### about removing sprintf() in
> 5.0, but
>> > > it's still there. I'd like to deprecate them.
>> > >
>> > > I have a long-standing hate of the fact that QString::sprintf()
> is not
>> > > static, so my preferred solution would be to make it static, but
> that
>> > > silently breaks existing usage other than the idiomatic
>> > > QString().sprintf().
>> > >
>> > > Unless there's a clever technique by which we can at
> compile-time catch
>> > > non-static uses of sprintf(), I'd propose to just deprecate
> it.
>> >
>> > Actually, I just found GNU's asprintf() extension
> ("allocated-string
>> > printf"), arguably a better name for QString::sprintf() anyway.
> So I'll
>> > upload a patch to Gerrit that will:
>> >
>> > 1. Deprecate QString{v,}sprintf()
>> > 2. Add static QString::{v,}asprintf()
>>
>> https://codereview.qt-project.org/#change,17062
>>
>> The patch also nicely highlights how and where QString().sprintf() is used
>> in Qt itself, because it adjusts all callers.
>>
>> Before vetoing the patch on the grounds of C-style API, please remember
> that
>> this functionality is required for qDebug() and that we want to keep SiC as
>> much as possible for 5.0. A C++11-style framework is a lot more work, and
>> not something I'd expect to land in 5.0.
>>
>> My main drive is the embarrassment of having sprintf not static.
>
> Is that so much of a problem of it non being static?
> Why not just keeping it as it is?
Doesn't matter to me.
> (else, you could also deprecate it from the public API, but keep it in the
> private API for qDebug)
I know of someone who (while not a Qt programmer) do like to have that kind of
stuff built-in to string functionality.
He even made an argument for not using std::string (or std::wstring) simply on
those grounds; and we ended up
with a lot of MFC CString cruft because of it.
Having something that does the work of {v,s,sn,a}prinf() is very useful to have.
The tr().arg() functionality while useful, does not satisfy quite all needs -
its much easier to format using {v,s,sn,a}prinf()
than tr().arg() (or QString().arg()).
$0.02
Ben
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On Tuesday 21 February 2012 14:03:26 Marc Mutz wrote:
> On Tuesday February 21 2012, Marc Mutz wrote:
> > On Tuesday February 21 2012, Marc Mutz wrote:
> > > Hi,
> > >
> > > The QString header contains a ### about removing sprintf() in 5.0, but
> > > it's still there. I'd like to deprecate them.
> > >
> > > I have a long-standing hate of the fact that QString::sprintf() is not
> > > static, so my preferred solution would be to make it static, but that
> > > silently breaks existing usage other than the idiomatic
> > > QString().sprintf().
> > >
> > > Unless there's a clever technique by which we can at compile-time catch
> > > non-static uses of sprintf(), I'd propose to just deprecate it.
> >
> > Actually, I just found GNU's asprintf() extension ("allocated-string
> > printf"), arguably a better name for QString::sprintf() anyway. So I'll
> > upload a patch to Gerrit that will:
> >
> > 1. Deprecate QString{v,}sprintf()
> > 2. Add static QString::{v,}asprintf()
>
> https://codereview.qt-project.org/#change,17062
>
> The patch also nicely highlights how and where QString().sprintf() is used
> in Qt itself, because it adjusts all callers.
>
> Before vetoing the patch on the grounds of C-style API, please remember that
> this functionality is required for qDebug() and that we want to keep SiC as
> much as possible for 5.0. A C++11-style framework is a lot more work, and
> not something I'd expect to land in 5.0.
>
> My main drive is the embarrassment of having sprintf not static.
Is that so much of a problem of it non being static?
Why not just keeping it as it is?
(else, you could also deprecate it from the public API, but keep it in the
private API for qDebug)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On terça-feira, 21 de fevereiro de 2012 18.28.44, Marc Mutz wrote:
> It does use QLocale methods for formatting, and it supports the l modifier
> to %s. For a port to QByteArray, we'd need to define what encoding to
> assume (QString expects utf-8 on input, and we'd keep that, but we need to
> decide which encoding to _output_).
Do you mean for the following code?
QString().sprintf("%ls", otherqstring.utf16())
I didn't know that was possible until you mentioned it. I doubt many people
are using it. Note that it's also different from the real printf's %ls, which
expects wchar_t*, not ushort*.
Changing to QByteArray would mean assuming an encoding *if* we keep our own
code. I'd much rather this used vasprintf and let the system deal with it. (In
that case, wide strings would be converted using an equivalent of
toLocal8Bit()).
This is a source of subtle bugs, so I'm going to drop the proposal. Just make
the functions static and we'll work on a proper C++11 replacement later.
--
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] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, Marc Mutz wrote: > On Tuesday February 21 2012, you wrote: > > On Tue, Feb 21, 2012 at 3:20 PM, wrote: > > > Is there any reason why we cannot move QString::asprintf() to > > > QByteArray::asprintf() instead? > > > > If your data is already in a QString, you're going to pay a rather > > large penalty to copy it all to a byte array just to use that, and > > then convert it back. > > That's exactly what QString::sprintf does right now - it only works on 8bit > strings, even though it stores the result in a QString. It does use QLocale methods for formatting, and it supports the l modifier to %s. For a port to QByteArray, we'd need to define what encoding to assume (QString expects utf-8 on input, and we'd keep that, but we need to decide which encoding to _output_). Thanks, Marc -- Marc Mutz | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, you wrote: > On Tue, Feb 21, 2012 at 3:20 PM, wrote: > > Is there any reason why we cannot move QString::asprintf() to > > QByteArray::asprintf() instead? > > If your data is already in a QString, you're going to pay a rather > large penalty to copy it all to a byte array just to use that, and > then convert it back. That's exactly what QString::sprintf does right now - it only works on 8bit strings, even though it stores the result in a QString. Thanks, Marc -- Marc Mutz | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On terça-feira, 21 de fevereiro de 2012 15.58.25, jan-arve.saet...@nokia.com wrote: > I'm not sure why qmake needs to work with QStrings though.. Because qmake was a port into C++ of the previous Perl-based build system called tmake[1]. Qt 2.3.1 [2] still used it, as you can see from the tools/Makefile.in[3] file that is generated from tools/tools.pro[4]. [1] http://tmake.sourceforge.net/ [2] http://websvn.kde.org/trunk/qt-copy/?pathrev9842 [3] http://websvn.kde.org/trunk/qt- copy/tools/tools.pro?view=markup&pathrev9842 [4] http://websvn.kde.org/trunk/qt- copy/tools/Makefile.in?view=markup&pathrev9842 -- 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] Changing qreal to a float
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't think you thought your proposal through before sending... There are simply no common methods between the classes. They may look the same and execute similar operations, but since they operate on different data types, they are not the same. -- 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] Changing qreal to a float
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 or QRectI, > but I'm not utterly convinced... We could deprecate QRect and QRectF, and introduce a proper QRectangle. It should be doable by means of an implicit QRect(const QRectangle &) constructor and an operator QRectangle() const. If that doesn't work, it would unfortunately mean deprecating all of the API that uses QRect and QRectF and add new API. But by the same token that Andreas has of subtle bugs, this change would introduce subtle bugs in Qt code that relies on the quirky QRect behaviour. -- 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] Deprecating QString::{v,}sprintf()
Sorry for top-posting again... I'm not sure I understand. The code that Marc fixed mostly needed to pay the penalty of converting the QString to a QByteArray. For the majority of the other cases, the code should have used tr().arg(). The code in qmake was however an exception, since it works with QStrings instead of byte arrays. That could serve as a counter argument... I'm not sure why qmake needs to work with QStrings though.. Jan-Arve 21.02.12 16:39 skrev ext Robin Burchell: On Tue, Feb 21, 2012 at 3:20 PM, wrote: > Is there any reason why we cannot move QString::asprintf() to > QByteArray::asprintf() instead? If your data is already in a QString, you're going to pay a rather large penalty to copy it all to a byte array just to use that, and then convert it back. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 Aardal Hanssen: 2012/2/21 Thiago Macieira mailto:thiago.macie...@intel.com>> 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 class with slightly different semantics, I'll leave up to the implementor. QRect's silly semantics are one huge reason why it can make sense to obsolete it and its friends, and make new QRectangle classes that all behave the same. I've run into numerous issues that are due to the fact that some rectangle variable's right() value is different depending on whether it's QRect or QRectF. QRect was kept this way for compatibility with Qt 3. Qt 5 should have no more such crap. There never was any QPoly (gon), QEll (ipse), why should there be a QRect. M'just sayin'. (sorry if this arrives twice to the list btw) -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On Tue, Feb 21, 2012 at 3:20 PM, wrote: > Is there any reason why we cannot move QString::asprintf() to > QByteArray::asprintf() instead? If your data is already in a QString, you're going to pay a rather large penalty to copy it all to a byte array just to use that, and then convert it back. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
2012/2/21
> return QString::asprintf("%d bytes", int(number));
> should be:
> return tr("%n bytes", 0, number);
>
> Same here:
> const QString num = QString::asprintf("%.1f KB/s", bytesPerSecond /
> 1024.0);
> should be:
> const QString num = tr("%1 KB/s").arg(bytesPerSecond/1024.0, 0, 'f', 1);
>
> ...And the list goes on (I stopped at qmap.cpp)
>
I don't know if this is really the right comparison, both are slower and
harder to understand.
sprintf() is great for formatted output, much better than chaining .args().
It also has the potential for being a lot faster.
It sounds like a step in the wrong direction to remove QString::sprintf()
and friends without adding something better.
The purpose of the function is, after all, to allow construction of
formatted output without concatenating substrings.
--
Andreas Aardal Hanssen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, jan-arve.saet...@nokia.com wrote: > This leads me to my question: > Is there any reason why we cannot move QString::asprintf() to > QByteArray::asprintf() instead? I'd be fine with that. -- Marc Mutz | Senior 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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
> 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 to CRect semantics (not >> 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 class with slightly different semantics, I'll leave up to > the implementor. > > I'd rather it were part of the template. That means whoever is implementing > this template needs to add some magic for the logic for integers to be > different from the logic from FP. Perhaps a template is not the best option? Perhaps an abstract/virtual class that is derived from for the various classes would be better? Each class could then have its own internal data instead. Yes, it would mean a little more duplication in the code; but it would allow for the specialization of each class to its type. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 class with slightly different semantics, I'll leave up > to > the implementor. > QRect's silly semantics are one huge reason why it can make sense to obsolete it and its friends, and make new QRectangle classes that all behave the same. I've run into numerous issues that are due to the fact that some rectangle variable's right() value is different depending on whether it's QRect or QRectF. QRect was kept this way for compatibility with Qt 3. Qt 5 should have no more such crap. There never was any QPoly (gon), QEll (ipse), why should there be a QRect. M'just sayin'. (sorry if this arrives twice to the list btw) -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
ext Marc Mutz wrote on 2012-02-21:
>
> https://codereview.qt-project.org/#change,17062
>
> The patch also nicely highlights how and where QString().sprintf() is
> used in Qt itself, because it adjusts all callers.
>
This caught my interest, so I checked some of the callers to see how
sprintf was used.
It's interesting to see how lots of the callers does not need
QString::sprintf().
For instance:
For instance:
return QString::asprintf("%d bytes", int(number));
should be:
return tr("%n bytes", 0, number);
Same here:
const QString num = QString::asprintf("%.1f KB/s", bytesPerSecond / 1024.0);
should be:
const QString num = tr("%1 KB/s").arg(bytesPerSecond/1024.0, 0, 'f', 1);
...And the list goes on (I stopped at qmap.cpp)
And lots of the callers that don't need localized strings, could have been
replaced
with QByteArray::sprintf() instead (well, if the function existed).
This leads me to my question:
Is there any reason why we cannot move QString::asprintf() to
QByteArray::asprintf() instead?
cheers,
Jan-Arve
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On terça-feira, 21 de fevereiro de 2012 12.12.52, Marc Mutz wrote: > QString::arg() can't deal with va_lists. Are you proposing to disable > qDebug() for non-C++11-compilers? No, but I also fail to see why we need QString::sprintf for qDebug. qDebug should operate on char, not on UTF-16, and thus it can use (va)sprintf. -- 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] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, Marc Mutz wrote:
> On Tuesday February 21 2012, Marc Mutz wrote:
> > Hi,
> >
> > The QString header contains a ### about removing sprintf() in 5.0, but
> > it's still there. I'd like to deprecate them.
> >
> > I have a long-standing hate of the fact that QString::sprintf() is not
> > static, so my preferred solution would be to make it static, but that
> > silently breaks existing usage other than the idiomatic
> > QString().sprintf().
> >
> > Unless there's a clever technique by which we can at compile-time catch
> > non-static uses of sprintf(), I'd propose to just deprecate it.
>
> Actually, I just found GNU's asprintf() extension ("allocated-string
> printf"), arguably a better name for QString::sprintf() anyway. So I'll
> upload a patch to Gerrit that will:
>
> 1. Deprecate QString{v,}sprintf()
> 2. Add static QString::{v,}asprintf()
https://codereview.qt-project.org/#change,17062
The patch also nicely highlights how and where QString().sprintf() is used in
Qt itself, because it adjusts all callers.
Before vetoing the patch on the grounds of C-style API, please remember that
this functionality is required for qDebug() and that we want to keep SiC as
much as possible for 5.0. A C++11-style framework is a lot more work, and not
something I'd expect to land in 5.0.
My main drive is the embarrassment of having sprintf not static.
Thanks,
Marc
--
Marc Mutz | Senior 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
smime.p7s
Description: S/MIME cryptographic signature
___
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 Thiago Macieira > Sent: Tuesday, February 21, 2012 11:13 AM > To: development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > On terça-feira, 21 de fevereiro de 2012 10.02.23, kai.koe...@nokia.com > wrote: > > So how about adding another QtMsgType called QLogMsg, that qLog() > > uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages > would > > not be processed by default, unless the configuration file (or an > > environment > > variable) says so ... > > That's almost a necessity. An informative message is not debugging. > > >From sys/syslog.h: > #define LOG_EMERG 0 /* system is unusable */ > #define LOG_ALERT 1 /* action must be taken immediately */ > #define LOG_CRIT2 /* critical conditions */ > #define LOG_ERR 3 /* error conditions */ > #define LOG_WARNING 4 /* warning conditions */ > #define LOG_NOTICE 5 /* normal but significant condition */ > #define LOG_INFO6 /* informational */ > #define LOG_DEBUG 7 /* debug-level messages */ > > We don't have EMERG and ALERT because Qt applications (often) aren't > system applications and can't cause those conditions. And we don't have > NOTICE or INFO because our message output was designed only for > developer usage (from developers to other developers). Actually I'd also like to get a qInfo/QtInfoMsg level at one point, if only to better match the log levels of JavaScript / console object: console.log() console.debug() console.info() in QML right now all result in a qDebug() call. The other use case I ran into in the past is this message: "Qml debugging is enabled. Only use this in a safe environment!" Which is printed on startup for applications configured with Qt+=declarative_debug . Right now it's a qWarning(), but I got numerous complains that it is making QT_FATAL_WARNINGS useless ... Anyhow, this is something we probably could still do in 5.x. Regards Kai > That also reminds me: some systems would benefit from having our message > output go to syslog. MeeGo had a patch that I wrote a long time ago that > sent all messages to syslog. > > -- > 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 ___ 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 Potter Lorn (Nokia-MP/Brisbane) > Sent: Tuesday, February 21, 2012 11:47 AM > To: david.fa...@kdab.com > Cc: development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > > On 21/02/2012, at 8:28 PM, ext David Faure wrote: > > > On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: > >> On 21/02/2012, at 7:36 PM, ext David Faure wrote: > >>> On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > 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 still having the feature that > you can activate it without recompiling the code. > >>> > >>> Why? IMHO things should go to stderr by default. So it makes perfect > >>> sense to see the output, even if one didn't configure output files > >>> in a config file. > >> The whole idea is to have noop by default. Nothing. Ziltch. Not even > >> std err. Use qWarning if you want or need that. That's what it's for. > >> If you need this, only when you do a magical incantation, such as a > >> config file or env var, will it produce any output. > > > > I agree. > > However my point was: once turned on, it could just go to stderr, and > > not require configuration of an output file. > > Not all systems even have easy stderr output *cough windows*. It has the debugger buffer. Admittedly it has its problems, but it's the standard for IDE's to get output. If you just log to a file, you'll never see your qLog statements in your IDE (unless you hack special support for it to catch the log file or something similar). > How are > you going to retrieve that from an app installed in a sandbox on a clients > system, when there is no access to a terminal ouput? You can always specify a file in this case. Logging to a file is sometimes needed, the question is whether it should be the only way to get the data. > If you want stderr, use > qDebug or friends. So I've to tell the customer to get me the qLog file (for qLog warnings), and in addition the console output (for qWarning, qFatal etc)? And then try to match between those to understand what's going on? Or make sure that every qWarning in addition has a qLog ? Doesn't sound appealing to me either ... > How are you going to configure what categories are being transmitted > without a config file? A string list in an env var? Why not? export QT_LOG_CATEGORY="QtCore.IO" isn't that scary, is it? And even if it is more elaborous, you could still have the config file, but not specifying a log file ... Regards Kai > > > > >>> I guess this is a mobile platform vs desktop platform discussion. On > >>> a mobile platform the logs are only useful if they go to a file, > >>> while on the desktop the logs are useful also if they go to stderr, > >>> to get them in a terminal or in the session log file. > >> > >> Not really. It's more of not wanting to have any performance hits in > >> shipping code. Even on embedded systems, developers want and need > >> console output, and support services might need detailed log file at > >> times. qlog makes this possible. Nothing stopping anyone from doing a > >> tail -f my.log > > > > But there won't be a "my.log" configured by default, so the user needs > > to set that up first. > > > I'm aiming at something that is simple to use for the simple case. > > When a user comes on IRC with a bug and we want to see the output, it > > should be simple for him/her to get that output. Finding the right > > config file and editing it by hand isn't exactly simple. Well, OK, a > > GUI tool can fix that; maybe we can even make that part of qtconfig. That > would fix the issue nicely, in fact. > > Who said anything about editing by hand? Simply have them install a > preconfigured config file you give them. > Heck you can even do that at first install, so there is a log file, just in > case. > > :) > > > > > OK, so objections withdrawn. > > > > -- > > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > > KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 > > 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - > > Platform-independent software solutions > > > > Lorn Potter > Senior Software Engineer, Core Enablers/QtSensors > > > > > > ___ > 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] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, Thiago Macieira wrote: > On terça-feira, 21 de fevereiro de 2012 10.56.41, Marc Mutz wrote: > > Bottomline: until we can expect variadic template support for Qt, I think > > we need to keep it. Many people have over the years tried to eradicate > > printf, but it's syntax is just too compact. > > Add a C++11 proper function and let people who don't have C++11 use > QString::arg. QString::arg() can't deal with va_lists. Are you proposing to disable qDebug() for non-C++11-compilers? :) > I'm ok with adding C++11-only options (provided a C++98-built Qt can still > provide them). Thanks, Marc -- Marc Mutz | Senior 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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSystemAlignedTimer to QtCore
On 02/20/2012 02:36 PM, ext Thiago Macieira wrote: > 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: alignedtimers >> description: The AlignedTimer is a service for applications to synchronize >> their activity. AlignedTimer is a fuzzy timer that allows applications that >> must do periodic activity like after being in sleep mode a certain period, >> to synchronize their activities in the same window of time. For example >> send network "alive" messages at the same time (i.e. turn the wireless >> radio on at the same time). The service is not only for network-aware >> applications, it is for use by any applications that need to periodic >> wake-ups. > > Supported. > Hi, The playground project has been created. # git clone ssh://codereview.qt-project.org:29418/playground/alignedtimers.git Cheers, -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:47:18 lorn.pot...@nokia.com wrote: > On 21/02/2012, at 8:28 PM, ext David Faure wrote: > > On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: > >> On 21/02/2012, at 7:36 PM, ext David Faure wrote: > >>> On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > 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 > still having the feature that you can activate it without recompiling > the > code. > >>> > >>> Why? IMHO things should go to stderr by default. So it makes perfect > >>> sense > >>> to see the output, even if one didn't configure output files in a config > >>> file. > >> > >> The whole idea is to have noop by default. Nothing. Ziltch. Not even std > >> err. Use qWarning if you want or need that. That's what it's for. If you > >> need this, only when you do a magical incantation, such as a config file > >> or > >> env var, will it produce any output. > > > > I agree. > > However my point was: once turned on, it could just go to stderr, and not > > require configuration of an output file. > > Not all systems even have easy stderr output *cough windows*. How are you > going to retrieve that from an app installed in a sandbox on a clients > system, when there is no access to a terminal ouput? If you want stderr, > use qDebug or friends. You keep assuming that the developer is working on ONE application, and has full control over everything. This isn't how it works, in particular in KDE and other opensource Qt apps. The developer uses qDebug or qLog because that suits him/her, the user ends up on a completely different OS, with different needs If there is no access to terminal output (well there's always DebugView.exe too...), then the user can set up files, this doesn't change anything compared to your initial idea. > How are you going to configure what categories are > being transmitted without a config file? A string list in an env var? Some logging frameworks actually do that, I think. (libACE, iirc?) But OK, I'm withdrawing the whole point - a GUI will do the job just fine, as long as the qLog config file *does* allow the output for a given to go to stderr, not only to files. > Who said anything about editing by hand? Simply have them install a > preconfigured config file you give them. Which still requires finding out where the config file must go, on the user's system. But OK, no better solution anyway, and the GUI app can find out automatically. > Heck you can even do that at first > install, so there is a log file, just in case. Again, with "first install" you assume pre-built binaries and an installer. Not the case when you download the sources for a random Qt application from sourceforge, or when you "apt-get install" or equivalent. I keep seeing this mindset of "one big commercial application" on this list, but Qt developers have to realize that there's also the opensource application use case, as well as the "Qt-based framework" use case (where changing the defaults for logging, or installing config files, is definitely not wanted). -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On 21/02/2012, at 8:28 PM, ext David Faure wrote: > On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: >> On 21/02/2012, at 7:36 PM, ext David Faure wrote: >>> On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: 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 still having the feature that you can activate it without recompiling the code. >>> >>> Why? IMHO things should go to stderr by default. So it makes perfect sense >>> to see the output, even if one didn't configure output files in a config >>> file. >> The whole idea is to have noop by default. Nothing. Ziltch. Not even std >> err. Use qWarning if you want or need that. That's what it's for. If you >> need this, only when you do a magical incantation, such as a config file or >> env var, will it produce any output. > > I agree. > However my point was: once turned on, it could just go to stderr, and not > require configuration of an output file. Not all systems even have easy stderr output *cough windows*. How are you going to retrieve that from an app installed in a sandbox on a clients system, when there is no access to a terminal ouput? If you want stderr, use qDebug or friends. How are you going to configure what categories are being transmitted without a config file? A string list in an env var? > >>> I guess this is a mobile platform vs desktop platform discussion. On a >>> mobile platform the logs are only useful if they go to a file, while on >>> the desktop the logs are useful also if they go to stderr, to get them in >>> a terminal or in the session log file. >> >> Not really. It's more of not wanting to have any performance hits in >> shipping code. Even on embedded systems, developers want and need console >> output, and support services might need detailed log file at times. qlog >> makes this possible. Nothing stopping anyone from doing a tail -f my.log > > But there won't be a "my.log" configured by default, so the user needs to set > that up first. > I'm aiming at something that is simple to use for the simple case. When a > user > comes on IRC with a bug and we want to see the output, it should be simple > for > him/her to get that output. Finding the right config file and editing it by > hand > isn't exactly simple. Well, OK, a GUI tool can fix that; maybe we can even > make > that part of qtconfig. That would fix the issue nicely, in fact. Who said anything about editing by hand? Simply have them install a preconfigured config file you give them. Heck you can even do that at first install, so there is a log file, just in case. :) > > OK, so objections withdrawn. > > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > Lorn Potter Senior Software Engineer, Core Enablers/QtSensors ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:19:49 kai.koe...@nokia.com wrote: > > -Original Message- > > From: ext David Faure [mailto:david.fa...@kdab.com] > > > > Isn't the same information given by "a category is present in the > > QMessageLogContext"? All qLog calls are forced to get a category, right? > > Right, but that would mean we can't use categories for anything except qLog. > If we use categories solely for the purpose of filtering that's probably > fine, but I personally also see some value in having them available as free > text in the log, for all log QtMsgType's ... I would agree (after all we've been doing the same in KDE, it helps to understand where a warning or error comes from). But for this to be possible, we're back at the discussion of how to specify a category when calling qDebug or qWarning, and I thought the conclusion was "no"... In other words I like your idea, but there's no API to actually make it possible... -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: > On 21/02/2012, at 7:36 PM, ext David Faure wrote: > > On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > >> 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 > >> still having the feature that you can activate it without recompiling the > >> code. > > > > Why? IMHO things should go to stderr by default. So it makes perfect sense > > to see the output, even if one didn't configure output files in a config > > file. > The whole idea is to have noop by default. Nothing. Ziltch. Not even std > err. Use qWarning if you want or need that. That's what it's for. If you > need this, only when you do a magical incantation, such as a config file or > env var, will it produce any output. I agree. However my point was: once turned on, it could just go to stderr, and not require configuration of an output file. > > I guess this is a mobile platform vs desktop platform discussion. On a > > mobile platform the logs are only useful if they go to a file, while on > > the desktop the logs are useful also if they go to stderr, to get them in > > a terminal or in the session log file. > > Not really. It's more of not wanting to have any performance hits in > shipping code. Even on embedded systems, developers want and need console > output, and support services might need detailed log file at times. qlog > makes this possible. Nothing stopping anyone from doing a tail -f my.log But there won't be a "my.log" configured by default, so the user needs to set that up first. I'm aiming at something that is simple to use for the simple case. When a user comes on IRC with a bug and we want to see the output, it should be simple for him/her to get that output. Finding the right config file and editing it by hand isn't exactly simple. Well, OK, a GUI tool can fix that; maybe we can even make that part of qtconfig. That would fix the issue nicely, in fact. OK, so objections withdrawn. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On 21/02/2012, at 7:36 PM, ext David Faure wrote: > On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: >> 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 >> still having the feature that you can activate it without recompiling the >> code. > > Why? IMHO things should go to stderr by default. So it makes perfect sense to > see the output, even if one didn't configure output files in a config file. > The whole idea is to have noop by default. Nothing. Ziltch. Not even std err. Use qWarning if you want or need that. That's what it's for. If you need this, only when you do a magical incantation, such as a config file or env var, will it produce any output. > I guess this is a mobile platform vs desktop platform discussion. On a mobile > platform the logs are only useful if they go to a file, while on the desktop > the logs are useful also if they go to stderr, to get them in a terminal or > in > the session log file. > Not really. It's more of not wanting to have any performance hits in shipping code. Even on embedded systems, developers want and need console output, and support services might need detailed log file at times. qlog makes this possible. Nothing stopping anyone from doing a tail -f my.log > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Lorn Potter Senior Software Engineer, Core Enablers/QtSensors ___ 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: ext David Faure [mailto:david.fa...@kdab.com] > Sent: Tuesday, February 21, 2012 11:08 AM > To: Koehne Kai (Nokia-MP/Berlin) > Cc: Beck Wolfgang (Nokia-MP/Brisbane); development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > On Tuesday 21 February 2012 10:02:23 kai.koe...@nokia.com wrote: > > I agree with that: On the desktop it's quite handy to see also > > detailed output on stderr/the shell (which one can redirect to a file if > needed). > > But I also think that qLog() messages shouldn't show up by default for > > normal users, that is, unless the category has been explicitly enabled. > > True. > > > So how about adding another QtMsgType called QLogMsg, that qLog() > > uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages > would > > not be processed by default, unless the configuration file (or an > > environment > > variable) says so ... > > Isn't the same information given by "a category is present in the > QMessageLogContext"? All qLog calls are forced to get a category, right? Right, but that would mean we can't use categories for anything except qLog. If we use categories solely for the purpose of filtering that's probably fine, but I personally also see some value in having them available as free text in the log, for all log QtMsgType's ... Regards Kai > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 > 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent > software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On terça-feira, 21 de fevereiro de 2012 10.02.23, kai.koe...@nokia.com wrote: > So how about adding another QtMsgType called QLogMsg, that qLog() uses? In > contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be > processed by default, unless the configuration file (or an environment > variable) says so ... That's almost a necessity. An informative message is not debugging. >From sys/syslog.h: #define LOG_EMERG 0 /* system is unusable */ #define LOG_ALERT 1 /* action must be taken immediately */ #define LOG_CRIT2 /* critical conditions */ #define LOG_ERR 3 /* error conditions */ #define LOG_WARNING 4 /* warning conditions */ #define LOG_NOTICE 5 /* normal but significant condition */ #define LOG_INFO6 /* informational */ #define LOG_DEBUG 7 /* debug-level messages */ We don't have EMERG and ALERT because Qt applications (often) aren't system applications and can't cause those conditions. And we don't have NOTICE or INFO because our message output was designed only for developer usage (from developers to other developers). That also reminds me: some systems would benefit from having our message output go to syslog. MeeGo had a patch that I wrote a long time ago that sent all messages to syslog. -- 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)
On Tuesday 21 February 2012 10:02:23 kai.koe...@nokia.com wrote: > I agree with that: On the desktop it's quite handy to see also detailed > output on stderr/the shell (which one can redirect to a file if needed). > But I also think that qLog() messages shouldn't show up by default for > normal users, that is, unless the category has been explicitly enabled. True. > So how about adding another QtMsgType called QLogMsg, that qLog() uses? In > contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be > processed by default, unless the configuration file (or an environment > variable) says so ... Isn't the same information given by "a category is present in the QMessageLogContext"? All qLog calls are forced to get a category, right? -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On terça-feira, 21 de fevereiro de 2012 10.56.41, Marc Mutz wrote: > Bottomline: until we can expect variadic template support for Qt, I think > we need to keep it. Many people have over the years tried to eradicate > printf, but it's syntax is just too compact. Add a C++11 proper function and let people who don't have C++11 use QString::arg. I'm ok with adding C++11-only options (provided a C++98-built Qt can still provide them). -- 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 David Faure > Sent: Tuesday, February 21, 2012 10:36 AM > To: Beck Wolfgang (Nokia-MP/Brisbane) > Cc: development@qt-project.org > Subject: Re: [Development] QLog ( Work on qDebug and friends) > > On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > > 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 still having the feature that you can activate it > > without recompiling the code. > > Why? IMHO things should go to stderr by default. So it makes perfect sense > to see the output, even if one didn't configure output files in a config file. I agree with that: On the desktop it's quite handy to see also detailed output on stderr/the shell (which one can redirect to a file if needed). But I also think that qLog() messages shouldn't show up by default for normal users, that is, unless the category has been explicitly enabled. So how about adding another QtMsgType called QLogMsg, that qLog() uses? In contrast to qDebug/QtDebugMsg, qLog/QtLogMsg messages would not be processed by default, unless the configuration file (or an environment variable) says so ... Kai > I guess this is a mobile platform vs desktop platform discussion. On a mobile > platform the logs are only useful if they go to a file, while on the desktop > the > logs are useful also if they go to stderr, to get them in a terminal or in the > session log file. > > > -- > David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 > 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent > software solutions > > ___ > 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] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, Thiago Macieira wrote:
> On terça-feira, 21 de fevereiro de 2012 10.33.12, Marc Mutz wrote:
> > 2. Add static QString::{v,}asprintf()
>
> Do we need them? You can't pass non-POD via ellipsis, so it's not very easy
> to use. I'd much rather you invested time in a C++-style formatting.
>
> We already have QString::arg().
qlogging.cpp would be quite a bit more complicated without it...
I also need some function to back up sprintf() so QT_NO_DEPRECATED builds
remain BiC.
On a more general line: QString::sprintf() is the only implementation of a
printf-style formatter in Qt that allocates its target string, and therefore
doesn't suffer from the problems of all other functions (except asprintf)
about buffer lengths.
Look at http://linux.die.net/man/3/vsnprintf, make_message Example, to see how
horrendous correct implementation of an arbitrary-length version of printf()
otherwise is.
Bottomline: until we can expect variadic template support for Qt, I think we
need to keep it. Many people have over the years tried to eradicate printf,
but it's syntax is just too compact.
Thanks,
Marc
--
Marc Mutz | Senior 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
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QString::{v,}sprintf()
On terça-feira, 21 de fevereiro de 2012 10.33.12, Marc Mutz wrote:
> 2. Add static QString::{v,}asprintf()
Do we need them? You can't pass non-POD via ellipsis, so it's not very easy to
use. I'd much rather you invested time in a C++-style formatting.
We already have QString::arg().
--
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] Deprecating QString::{v,}sprintf()
On Tuesday February 21 2012, Marc Mutz wrote:
> Hi,
>
> The QString header contains a ### about removing sprintf() in 5.0, but it's
> still there. I'd like to deprecate them.
>
> I have a long-standing hate of the fact that QString::sprintf() is not
> static, so my preferred solution would be to make it static, but that
> silently breaks existing usage other than the idiomatic
> QString().sprintf().
>
> Unless there's a clever technique by which we can at compile-time catch
> non-static uses of sprintf(), I'd propose to just deprecate it.
Actually, I just found GNU's asprintf() extension ("allocated-string printf"),
arguably a better name for QString::sprintf() anyway. So I'll upload a patch
to Gerrit that will:
1. Deprecate QString{v,}sprintf()
2. Add static QString::{v,}asprintf()
Thanks,
Marc
--
Marc Mutz | Senior 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
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On Tuesday 21 February 2012 06:28:38 wolfgang.b...@nokia.com wrote: > 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 > still having the feature that you can activate it without recompiling the > code. Why? IMHO things should go to stderr by default. So it makes perfect sense to see the output, even if one didn't configure output files in a config file. I guess this is a mobile platform vs desktop platform discussion. On a mobile platform the logs are only useful if they go to a file, while on the desktop the logs are useful also if they go to stderr, to get them in a terminal or in the session log file. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 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 class with slightly different semantics, I'll leave up to the implementor. I'd rather it were part of the template. That means whoever is implementing this template needs to add some magic for the logic for integers to be different from the logic from FP. In time, it's usually a good idea to have a range of [start, end) -- that is, inclusive of the start and exclusive of the end. It's a matter of choosing the operators right when doing comparisons. But that implies on integer quantities that "end" is "the successor of the last valid element". That's an invariant that the STL iterators already match. -- 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] Changing qreal to a float
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: > who cares? :) C++98 costs more, I'm with you :-) -- 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] Changing qreal to a float
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 proposed above, or does > >> it require having "QRectD QRectD::toRectD() const" as well? > > > > With some template magic it can be done. > > > > If you write: > > template class QBasicRect; > > typedef QBasicRect QRectF; > > typedef QBasicRect QRectD; > > > > Then you can't specialise QBasicRect anymore. You can > > only use the default expansion or partial specialisations that are yet to > > be written. That means it's easier to add an "constexpr inline QRectD > > toRectD() const;" to all classes than to just the float and integer ones. > > > > But someone really motivated can add more magic using QEnableIf. > > 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 these classes? 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: who cares? :) Thanks, Marc -- Marc Mutz | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 "QRectD QRectD::toRectD() const" as well? > > With some template magic it can be done. That simply being full template specialisation? That'd duplicate quite some code, though, yes. > If you write: > template class QBasicRect; > typedef QBasicRect QRectF; > typedef QBasicRect QRectD; > > Then you can't specialise QBasicRect anymore. You can only > use the default expansion or partial specialisations that are yet to be > written. That means it's easier to add an "constexpr inline QRectD > toRectD() const;" to all classes than to just the float and integer ones. > > But someone really motivated can add more magic using QEnableIf. Specialising toRectD() to not appear in QRectD would force the same specialisation on generic code. So my feeling is that if there's a QBasicRect<>, then it should contain QBasicRect toBasicRect() const and convenience functions for all the existing typedefs. 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 like that), then keeping QRect and using QRectI = QBasicRect could do the trick. Thanks, Marc -- Marc Mutz | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 these classes? I don't think it would be noticeable, not more so than the existing code anyway. Complete guess. -- 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] Deprecating QString::{v,}sprintf()
Hi, The QString header contains a ### about removing sprintf() in 5.0, but it's still there. I'd like to deprecate them. I have a long-standing hate of the fact that QString::sprintf() is not static, so my preferred solution would be to make it static, but that silently breaks existing usage other than the idiomatic QString().sprintf(). Unless there's a clever technique by which we can at compile-time catch non-static uses of sprintf(), I'd propose to just deprecate it. What do you think? Thanks, Marc -- Marc Mutz | Senior 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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 QRectD::toRectD() const" as well? > With some template magic it can be done. > > If you write: > template class QBasicRect; > typedef QBasicRect QRectF; > typedef QBasicRect QRectD; > > Then you can't specialise QBasicRect anymore. You can only > use > the default expansion or partial specialisations that are yet to be written. > That means it's easier to add an "constexpr inline QRectD toRectD() const;" to > all classes than to just the float and integer ones. > > But someone really motivated can add more magic using QEnableIf. > 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 these classes? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
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 magic it can be done. If you write: template class QBasicRect; typedef QBasicRect QRectF; typedef QBasicRect QRectD; Then you can't specialise QBasicRect anymore. You can only use the default expansion or partial specialisations that are yet to be written. That means it's easier to add an "constexpr inline QRectD toRectD() const;" to all classes than to just the float and integer ones. But someone really motivated can add more magic using QEnableIf. -- 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] Proposing Sergey Dubitskiy for Approver Status
On terça-feira, 21 de fevereiro de 2012 02.20.59, daniel.p...@nokia.com wrote: > I support this nomination. That means we'll hear objections to Sergey Dubitskiy becoming an Approver until March 20. -- 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)
On terça-feira, 21 de fevereiro de 2012 07.15.48, wolfgang.b...@nokia.com wrote: > 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. I don't want this. Application names and organisation names change every now and then. The applications may know about their own settings and migrate those, but if we have hardcoded paths coming from inside QtCore, those will get lost in the move. Please restrict this to an environment variable and to supplying a QIODevice*. -- 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
