[Development] About HTML5 file system api
Dear All: I have compiled qt5 for wayland and qtwebkit module success! And had a demo browser running as a wayland client, So I wonder if some HTML5 function such as fileapi can be supported in qtwebkit as well, but ,sadly when I add --file-system option, it failed to compile. Can someone tell me about the progress of qt5 webkit development status of HTML5. thanks in advance!___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-20886: Remove QSettings from QtCore
On quarta-feira, 22 de fevereiro de 2012 17.23.53, lars.kn...@nokia.com wrote: > Hi, > > also here it looks extremely challenging to disentangle all the code, as > QSettings is still used in many places. > > So my proposal is that we don't do this change and instead simply > deprecate QSettings as soon as we have a proper replacement. > > Comments? I think we'll need to bite the bullet here because we failed to add a QWindowsRegistry class to read the registry. QtCore is mostly clean of QSettings and the cleanup should continue anyway. That also applies to QtNetwork (I have no clue why it's used there) and QtGui. Some of the uses that remain in QtGui must definitely be gone because they try to use Trolltech.conf. The rest are documentation that need to be cleaned up and removed. -- 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 quarta-feira, 22 de fevereiro de 2012 17.51.07, Giuseppe D'Angelo wrote: > The only points where the API isn't a replecement is where the other > non-Perl QRegExp matchings are used (f.i. wildcard matching; but I saw > that QRegExp has a nice wc2rx internal method to convert wildcards to > a Perl-like regex, that could potentially even be exposed as part of > QRegularExpression API, and that can help the conversion...). That's a missing functionality we'll need to add to QRegularExpression. QRegExp is today used for globbing in QDir, QDirIterator and QSslSocket. -- 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] QTBUG-23489: Implement the new regular expression classes using PCRE
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 - rcc: one single use, very easy to rewrite without regexes - uic: #includes are unnecessary; remove immediately - QtCore API: * QString non-const QRegExp&: use templates to support QRegExp in inline code (find a way), or simply stop supporting this * QMetaType & QVariant: let RegExp point to the new class * everywhere else (including QStringList): replace with the new class - QtCore internal uses: use the new class or rewrite (if possible, I recommend a non-regex globbing in QDir and QDirIterator). If the class is used in bootstrap, then the function in question must be opted out or the code rewritten, like qdatetime.cpp and this comment in qxmlutils.cpp: /* Right, we here have a dependency on QRegExp. Writing a manual parser to * replace that regexp is probably a 70 lines so I prioritize this to when * the dependency is considered alarming, or when the rest of the bugs * are fixed. */ - QtXml: used in bootstrap, so must rewrite without regex. Or refactor rcc to use QXmlStreamReader instead of QDom, then remove - QtGui API: * QTextDocument: replace with the new class * QRegExpValidator: move alongside QRegExp, but add a new class to QtGui - QtNetwork API: * QSslSocket (globbing functions for certificates): replace with new enums - QtScript API: replace with new class (same goes for QJSEngine) Maybe since QtScript is done, we leave it as is. But QJSEngine should use the new class. - document gallery: I don't know Everywhere else it's either internal use or doesn't have QRegExp in the API. Then we move QRegExp and QRegExpValidator to a new library, like QtConcurrent. We also modify QRegExp to add: QRegExp(const QRegularExpression &); // implicit operator QRegularExpression() const; > So I'd propose that we now bite the bullet and leave it in QtCore. Let's > simply mark it as deprecated since 5.0, and live with the additional 100k > in QtCore. That's another option, unless someone manages to pull off what I said above. I'd still recommend we clean up the API more or less along the lines of what I said above. -- 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] QTBUG-23489: Implement the new regular expression classes using PCRE
On 22 February 2012 17:11, 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? The "final" reviews (API, code, tests, docs) are missing, as well as the big rename to QRegex (or whatever). I think the code is more or less OK, apart the usual cleanups, but I defer to your judgement :) > 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. It doesn't break BC or SC in any classes, it's a pure API addition. The proposed rename to QRegex of course will break stuff, but as of now noone is using those methods because they're not available -- the patches are not merged ;-) Or did you mean something else? The bigger issue was related to (re)moving QRegExp: make QString::indexOf/replace/etc. templated (on the regexp class). I can't estimate the breakage that would do. > 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. There are certain places where QRegExp in which the maintainer doesn't want to depend on PCRE; for instance, qmake. In most of other places, the replacement is simply a s/QRegExp/QRegularExpression/. The only points where the API isn't a replecement is where the other non-Perl QRegExp matchings are used (f.i. wildcard matching; but I saw that QRegExp has a nice wc2rx internal method to convert wildcards to a Perl-like regex, that could potentially even be exposed as part of QRegularExpression API, and that can help the conversion...). > So I'd propose that we now bite the bullet and leave it in QtCore. Let's > simply mark it as deprecated since 5.0, and live with the additional 100k > in QtCore. Can it eventually become private in 5.0, accessible only through a public interface in the "qt4support" repository (or whatever is called the place where QHttp, QFtp etc. will go), and then get (re)moved from QtCore later without anyone noticing? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-23737: Move QtQuick 1 to its own module
This is mostly done. What remains is the renaming of the classes from QDeclarative to QQuick/QQml. This is ok for me to go into api_changes (you might need to create that branch in qtdeclarative) with the compat hacks we have (in moc and qtdeclarative). Please add Jira tasks for the compat hacks so we can remove them once all of Qt is using the new naming. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-24128/24129/24130: finish up platform specific code
These need to get done for 5.0. Most of this is about feature regressions against 4.x, so the deadline end of next week doesn't apply. Nevertheless it would be good if you can try to follow the guidelines as much as possible: * If you need changes in the QPA interfaces, please synchronize between the maintainers of all backends. * If the changes are more intrusive and might break downstream projects do them in api-changes. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-23634: Fix QMap implementation
This is my own bug. Same rules as for containers branch applies here. Can go into api_changes as long as it's fully SC. Deadline is end of next week. Just to mention the current status: I have the new QMap implementation working (and passing the tests) with the exception of insertMulti(). I have good hopes that I'll get it done until end of next week. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-23589: Merge QArrayData feature [containers branch] to master
Another one of the remaining features for 5.0 I'm ok for this to go into api_changes as long as it's fully source compatible with what we have in Qt right now. Deadline is end of next week. I think most of the work is done, so it should be possible to get it in by then. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-20886: Remove QSettings from QtCore
Hi, also here it looks extremely challenging to disentangle all the code, as QSettings is still used in many places. So my proposal is that we don't do this change and instead simply deprecate QSettings as soon as we have a proper replacement. Comments? Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTBUG-23489: Implement the new regular expression classes using PCRE
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. 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. So I'd propose that we now bite the bullet and leave it in QtCore. Let's simply mark it as deprecated since 5.0, and live with the additional 100k in QtCore. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why there is no Change-Id when I commit in qt4.8?
On Wednesday 22 February 2012 22:22:34 liang jian wrote: > Hi, everyone, > Recently I pushed two changes to Qt project for Qt5, I want them > also be pushed to Qt4.8, so I change the code in my qt4 repository > (cloned from gitorious.org), and try to commit it, To my surprise, the > commit message doesn't contain the Change-Id (I have copy the > commit-msg to .git/hooks). Do I forget something about setup my > development environment? > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Does the hook have execute permissions? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why there is no Change-Id when I commit in qt4.8?
Hi, everyone, Recently I pushed two changes to Qt project for Qt5, I want them also be pushed to Qt4.8, so I change the code in my qt4 repository (cloned from gitorious.org), and try to commit it, To my surprise, the commit message doesn't contain the Change-Id (I have copy the commit-msg to .git/hooks). Do I forget something about setup my development environment? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Important: Qt 5 freeze
Hi everybody, it's been now a little over two weeks since we announced the feature freeze. But I am still seeing lots of discussions about refactoring of code, API additions and other things that I'd count mostly as feature development. All of these changes are nice in principle, but they do not bring us closer to a releasable Qt. Quite to the opposite, many of these changes are actually bringing us further away from having something releasable. So let's be clear here: We need to stop with these now and focus on stability and bug fixing if we are to ship Qt 5.0 as planned. At this stage, we need to make sure we can all focus on bug fixing and for that we need to be more conservative in what kind of changes we do. Every source incompatible change is disruptive for people working in downstream repositories (declarative, etc.). Even binary incompatible changes cause us to loose a lot of time. Every time someone breaks binary compatibility in qtbase, people are forced to recompile all of their libs. This easily takes an hour. Multiply this with the number of developers working on the different Qt modules and we're talking several man weeks of lost time. To avoid these problems, let's now change our process slightly. We will use a new branch of qtbase in gerrit called api_changes for anything that is more than a bugfix. This branch is also CI controlled, and I'll merge from master into the branch regularly. At well defined times we'll them merge api_changes back to master. Other repositories such as declarative can create a similar branch if needed. Here's some guidelines about where changes should go: 1. Bug fixes that are source and binary compatible --> master 2. Small API additions that fill a gap, are SC and BC and have no side effects - e.g. C++11 additions --> master 3. BIC, but SC changes - Please think a couple of times whether this is really needed --> api_changes 4. SIC changes of new functionality - Aim to provide the old API as QT_DEPRECATED methods to avoid disrupting downstream - #ifdef them with QT_5_0_COMPAT. We can add this macro to global.h for now, remove again before we ship 5.0 --> api_changes 5. SIC changes of Qt 4.x functionality --> Sorry, won't go in Let's be very strict about the above policies, otherwise we'll have a very difficult time to get 5.0 out. We have a couple of exceptions listed in QTBUG-20885 to the above rules. These are: * new regexp classes * remove QSettings * container branch * new QMap * codecForCStrings/codecForTr removal * Finish platform specific parts and gain feature parity with 4.x * QUrl rewrite * QDeclarative -> QQml name change * qreal decision Deadline for finishing these features is end of next week. Stuff that's not done by then will not make it into 5.0. All of these features should go into the api_changes branch; I'll write emails about them all separately so we don't have large discussions about them in this thread. Please don't even think about other features before we're going towards 5.1. Instead, there's lots of work that we need to do that is just as important but doesn't affect the APIs as much. We need to fix lots of bugs. Let's look at memory consumption of Qt apps and optimize that. Let's work on improving performance. And let's work on fixing the remaining gaps we have against Qt 4.x Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
On quarta-feira, 22 de fevereiro de 2012 02.37.48, wolfgang.b...@nokia.com wrote: > 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*? void QLog::loadConfig(QIODevice *device); It's your option 2 above, except generalised to any 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
Re: [Development] QLog ( Work on qDebug and friends)
> -Original Message- > > 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. True, my fault. Kai ___ 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: Beck Wolfgang (Nokia-MP/Brisbane)
> Sent: Wednesday, February 22, 2012 1:38 AM
> To: Koehne Kai (Nokia-MP/Berlin); ext David Faure
> Cc: development@qt-project.org
> Subject: RE: [Development] QLog ( Work on qDebug and friends)
>
> Why you want to use the categories somewhere else then QLog?
As I said, there are two possible reasons to have categories
* filtering. This is what apparently QLog is about
* As an additional information to quickly see where messages 'belong to'. E.g.
a hypothetical log file might read
...
[warning] MyApp QtCore: QBuffer::setBuffer: Buffer is open
[warning] MyApp QtCreator.HelpManager: Error registering namespace 'Qt'
...
'QtCore', 'QtCreator.HelpManager' would quickly tell me where the messages
belong to. (We're of course somewhat providing this info for the Qt Libraries
already by encoding some context in the message itself ('QBuffer::setBuffer').
But other applications don't necessarily do this).
In understand that this is exactly what the 'area' in KDE/kdebug is about.
(Honestly speaking, we can of course live without this feature. But if we do it
like in KDE, you'd provide a 'default' context by a compiler define, so the
source code itself wouldn't get any uglier + the overhead wouldn't be that big.
And since we already have a free-text 'category' field for qLog, why not allow
it to be also put into the log file?).
> You want to reinvent a mechanism to filter the categories then?
I wouldn't provide one in Qt. But adding the category to the log message itself
would allow to do filtering by system tools like grep, or rsyslog. That is,
_after_ running the application.
> 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
