Re: [Development] Qt 4.8 and possibly 5: QVGPaintEngine implement a cache manager for vgpaths.
> I am interested in implementing a cache manager for VGPath(s) for the > openvg sybsystem, and I am thinking after a bit of reading the proper > way to do that,is by creating an LRU (in similar fashion as with > QVGImagePool). > > Since paths are more prone to alterations (to my understanding at > least) am looking a way to quickly destroy the vgpath associated, and > the only viable way is by adding some extra logic in the > QVectorPath and QPainterPath to handle the invalidations (ideally it > would be just check if a pointer is non-null and then free). QVectorPath already has this logic built in, so no hacking required. The OpenGL 2 paint engine uses this mechanism to store triangulated polygons. In practice we found that it doesn't help as often as we like because users very rarely store their QPainterPath's between one paintEvent() and the next and creating a cache based on the content of the data-array is too high a price to pay. You should also know that there is no longer any QVGPaintEngine in Qt 5. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
On 02/24/2012 02:32 AM, Koehne Kai (Nokia-MP/Berlin) wrote:
> It's probably the easiest to just default to have an empty string as 'legacy'
> category. This preserves the output of qDebug(), even if %{category} is
> printed by default
> as suggested below.
Disclaimer: I'm making up the format string identifiers (so they may not
match what's in there now).
The reason I hesitated with this is that (as far as I know) nothing else
in the format string can be empty. So a format string like
"%{file}:${line} %{func} %{message}" works.
foo.c:23 main() the message
However, a format string of say, "%{category}: %{file}:${line} %{func}
%{message}" would look odd when the category is empty.
mycat: foo.c:23 main() qCDebug
: foo.c:23 main() qDebug
I took the easy way of declaring a category for qDebug so I wouldn't
have to figure out how to do conditional formatting :)
But then if category strings end up long like "com.nokia.qt.plugins" it
might be a bit of a problem to print them out by default anyway. I guess
having the category printed is most useful in a "print out lots of
debugs then grep for one you want" case...
> Just wanted to point out that the current environment variable for configuring
> the output is called QT_MESSAGE_PATTERN. So it should be either
> QT_MESSAGE_CONFIG,
> or we should quickly rename QT_LOGGING_PATTERN ...
I guess QT_MESSAGE_CONFIG would be better.
--
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] (long) thoughts on categorized logging (qLog)
On 02/23/2012 09:48 PM, ext David Faure wrote:
>> 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. [...]
>
> Very good. Please don't deprecate it though (you're already calling it
> "legacy") ;)
>
> I consider qDebug("foo") and qDebug()<< "foo" to be the very useful "throw-
> away" debugging, so indeed it should be on by default, and it should not be
> considered deprecated/legacy.
I wasn't intending for them it to be removed but certainly, I'd expect
uses of plain qDebug/qWarning in Qt to migrate to the categorized versions.
>> # write output to a file (in the user's home directory)
>> logging.output.file = file.txt
>
> I suppose Windows users would expect relative paths to be "in the CWD, which
> is usually the executable's directory"? Not sure.
That doesn't work when an unprivileged user runs an installed app
because they don't have permission to write to Program Files.
If a relative path is going to cause problems then I'm happy to require
absolute paths :)
--
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] Mirror of Qt on github?
> > [1] > > http://qt-jenkins.moiji-mobile.com/jenkins/job/QtBase/label=FreeBSD_amd64,releasetype=debug/174/console Actually, as a normal ADSL user (not business connection, no gamer connection) I cannot clone the Qt repository as most of the time this is what I see from my point. Traffic shaping is a bitch. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing the return type of QMetaMethod::signature()
On Thursday 23 February 2012 18:36:22 Marc Mutz wrote: > On Wednesday February 15 2012, Kent Hansen wrote: > > However, if some code does do > > > > const char *sig = myMethod.signature(); > > // do something with sig (call strlen et al) ... > > ...it will generate a deprecated warning under > http://codereview.qt-project.org/17343, or fail to compile under > QT_NO_DEPRECATED/QT_NO_CAST_FROM_BYTEARRAY, so I don't see a big problem > with changing the return type. What we eventualy decided to do is to change the name of the method to QMetaMethod::methodSignature(). This name is consistant with the other function in that class. ---> http://codereview.qt-project.org/#change,17347 (Notice the nice error you get on code that used signature()) -- Olivier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing the return type of QMetaMethod::signature()
On Wednesday February 15 2012, Kent Hansen wrote: > However, if some code does do > > const char *sig = myMethod.signature(); > // do something with sig (call strlen et al) ... ...it will generate a deprecated warning under http://codereview.qt-project.org/17343, or fail to compile under QT_NO_DEPRECATED/QT_NO_CAST_FROM_BYTEARRAY, so I don't see a big problem with changing the return type. 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
[Development] Qt 4.8 and possibly 5: QVGPaintEngine implement a cache manager for vgpaths.
Hi list, I am interested in implementing a cache manager for VGPath(s) for the openvg sybsystem, and I am thinking after a bit of reading the proper way to do that,is by creating an LRU (in similar fashion as with QVGImagePool). Since paths are more prone to alterations (to my understanding at least) am looking a way to quickly destroy the vgpath associated, and the only viable way is by adding some extra logic in the QVectorPath and QPainterPath to handle the invalidations (ideally it would be just check if a pointer is non-null and then free). Alternatively, without altering the QVectorPath and QPainterPath I would create a copy of the actual path object inside a "structure" together with some unique identifiable info (ie a pointer to the original object), together with the vgpath file handle) and each time I access to access the path I do some checks if the local cached copy is identical to the original, which is more costly in terms of computation. (given the first approach, hacking QVectorPath and QPainterPath) If that code is wrapped in ifdefs, and enabled only in some scenario, do you consider this to be the right way to go ? Am I missing something? BR, N. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
> -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: Wednesday, February 22, 2012 7:37 AM
> To: qt-development
> Subject: [Development] (long) thoughts on categorized logging (qLog)
>
> Hi all,
Hi Lincoln,
> 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.
Thank you for describing in such a clear way where this is heading.
I personally like both the mission as well as the ideas for implementation :)
> 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.
It's probably the easiest to just default to have an empty string as 'legacy'
category. This preserves the output of qDebug(), even if %{category} is printed
by default
as suggested below.
> 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 override
Re: [Development] QTBUG-23489: Implement the new regular expression classes using PCRE
On quinta-feira, 23 de fevereiro de 2012 13.25.30, Shaw Andy wrote: > >The uses of QRegExp in qtbase and my proposals would be: > > - qmake: lots of use, keep it by copying qregexp.cpp into qmake > > Since I understand that the code would still be available in a separate > library anyway, then there is no need to copy the file, qmake pulls in the > files it needs directly from the current location so it could just > continue to do the same without having to copy the qregexp.cpp > specifically. I think my typing didn't follow the speed of my thoughts. So let me elaborate a bit: Step 1: qregexp in QtCore, where it is today We do the cleanups of the APIs as I suggested Step 2: qregexp.cpp moves to a separate lib, still inside qtbase We verify the non-qtbase modules that require QRegExp and we decide whether they'll use QRegExp or they'll move to PCRE. One example of not moving is QtScript. Step 3: qregexp.cpp moves out of qtbase We need to keep a copy inside qmake -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 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] (long) thoughts on categorized logging (qLog)
On quarta-feira, 22 de fevereiro de 2012 16.37.20, Lincoln Ramsay wrote: > 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. Probably easier to stat the file every Nth output. This avoids the thundering herd effect of all applications watching it suddenly deciding to re-parse it. -- 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] QTBUG-23489: Implement the new regular expression classes using PCRE
On 2/22/12 9:48 PM, "Thiago Macieira" wrote: >On quarta-feira, 22 de fevereiro de 2012 17.11.17, lars.kn...@nokia.com >wrote: >> Hi, >> >> this is the first mail where I'd like to go through the remaining >>features >> for Qt 5.0. >> >> I know that this bug is blocked by not having PCRE in 3rdparty/. But how >> is the status apart from this? Thiago, simply tell me if you feel >> comfortable with the code and I'll do final review and approval. If it >> doesn't break BC and is standalone from other code in qtcore, it can go >> into master, otherwise I'd prefer it to go into api_changes. > >I'm comfortable with the code as-is. Peppe has already submitted a couple >of >changes on top, which fix issues he's already found. Arguably, they could >be >squashed together, but I don't think that matters. > >The one remaining issue is the use of mutex-protected data. But I think >we've >got the proper fix in already. We'll only know more once people start >using it. > >> There's another related issue to this bug: What do we do with the old >> QRegExp? I've gripped through our code and removing it is a larger >> surgical operation. > >Indeed. I really have no clue how hard this would be. > >The uses of QRegExp in qtbase and my proposals would be: > > - qmake: lots of use, keep it by copying qregexp.cpp into qmake Since I understand that the code would still be available in a separate library anyway, then there is no need to copy the file, qmake pulls in the files it needs directly from the current location so it could just continue to do the same without having to copy the qregexp.cpp specifically. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
Hi Lincoln,
Thanks for this updated vision for logging. I like this very much.
On Wednesday 22 February 2012 16:37:20 Lincoln Ramsay wrote:
> PART 1: The logging statements.
> qCDebug(PLUGIN) << "Scanning for plugins in" << paths;
> qCWarning(PLUGIN) << "Could not load plugin" << loader->errorString();
Perfect!
> 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. [...]
Very good. Please don't deprecate it though (you're already calling it
"legacy") ;)
I consider qDebug("foo") and qDebug() << "foo" to be the very useful "throw-
away" debugging, so indeed it should be on by default, and it should not be
considered deprecated/legacy.
> PART 3: Turning statements on/off.
> 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.
Sounds good, except that I would want something more global than "one file per
application". When working on a framework or an entire desktop environment,
one needs to be able to toggle a debug area across all apps. But the
environment variable could be used for that, so that's a solution.
> PART 4: Formatting.
>
> There's a %{category} entry that can appear in the format string. This
> will be in the default format string.
+1
> 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
I suppose Windows users would expect relative paths to be "in the CWD, which
is usually the executable's directory"? Not sure.
Looks good.
--
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
