Re: [Development] When is Qt 4.8 in Gerrit? (Was: Qt Commercial 4.8.0 release delta to LGPL version)
On Wed, Jan 11, 2012 at 06:59:34AM +, ext Turunen Tuukka wrote: But we will push these also to Qt 5, of course we want it to contain these fixes as well. We plan to do this after the review is done and we know if the fix is accepted. and how exactly do you plan to ensure that nothing falls through the cracks? and that it is forward-ported *soon*? going for a jira excess, with a subtask for each qt5 forwardport? i'll endorse an exception if you present a credible process. have fun ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
Yes, if you think this is mostly an issue on initial show, (which I also think) then I think such a solution would acceptable. The default should then be AdjustToContentsOnFirstShow, as it is in QComboBox. regards, Jan-Arve From: ext Christoph Schleifenbaum [mailto:christoph.schleifenb...@kdab.com] Sent: 10. januar 2012 17:19 To: Saether Jan-Arve (Nokia-MP/Oslo) Cc: development@qt-project.org Subject: Re: [Development] sizeHint for QAbstractScrollArea, especially item views Hi, thanks for your input. What do you think about adding some sizeHint policy to this? I'm thinking about as it is done for QComboBox, i.e. AdjustToContents vs. AdjustToContentsOnFirstShow. Translated to this use case would be to never return any different sizeHint (and especially never call updateGeometry()) after the scroll area is shown for the first time. 6 jan 2012 kl. 14:20 skrev jan-arve.saet...@nokia.commailto:jan-arve.saet...@nokia.com jan-arve.saet...@nokia.commailto:jan-arve.saet...@nokia.com: Hi, I agree that the current behavior is sometimes not optimal, but I'm not sure if this is such a good idea. With regards to behavior it has some advantages, but I believe it also has some disadvantages. And since in addition it might introduce a performance penalty I'm leaning towards that this is not a good idea. I've made a comment on the patch in gerrit: http://codereview.qt-project.org/#change,11763 Jan-Arve From: development-bounces+jan-arve.saether=nokia@qt-project.orgmailto:development-bounces+jan-arve.saether=nokia@qt-project.org [mailto:development-bounces+jan-arve.saether=nokia@qt-project.orgmailto:nokia@qt-project.org] On Behalf Of ext Christoph Schleifenbaum Sent: 22. desember 2011 18:07 To: development@qt-project.orgmailto:development@qt-project.org Subject: [Development] sizeHint for QAbstractScrollArea, especially item views Hi, currently, item views do return a rather random size hint. Some at KDAB, including me, would love to see a size hint actually being related to the scroll area's content. For this, we thought of a method viewportSizeHint which returns the size of the viewport as if there would be no scroll bars required. The most common use case for this is a list or a table of data in a window: a) The ui designer doesn't need to set a custom size for the view, the size hint will make sure all data are visible b) The amount of data might grow, in that case it might made sense to enlarge the view. Imagine three tree views below each other inside a scroll area. If the tree views would stay at their size, a scroll bar would appear in both the tree view and in the surrounding scroll area. This won't happen with a proper size hint combined with a size policy. I'v attached a patch to the current qtbase.git. It does the described behaviour for QScrollArea and QTableView. Try running the example at examples/itemviews/spreadsheet to see what happens if you e.g. resize the columns in the table view. Thoughts? Cheers, Christoph -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.commailto:christoph.schleifenb...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.commailto:christoph.schleifenb...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
Up? Nobody wants to discuss this? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] When is Qt 4.8 in Gerrit? (Was: Qt Commercial 4.8.0 release delta to LGPL version)
In this particular case most of the contributions coming from Digia are contribs which were in Gitorious before, and them not being accepted put at least handled is our fault. I think for those its only fair that those are handled against 4.8, and then forward ported to 5.0. Once those original patches are handled, I assume Digia will follow the normal workflow by originating the patches in 5.0, and backporting them to 4.7/4.8. -- Sent from my Nokia N9 On 1/11/12 6:03 ext Oswald Buddenhagen wrote: On Wed, Jan 11, 2012 at 06:59:34AM +, ext Turunen Tuukka wrote: But we will push these also to Qt 5, of course we want it to contain these fixes as well. We plan to do this after the review is done and we know if the fix is accepted. and how exactly do you plan to ensure that nothing falls through the cracks? and that it is forward-ported *soon*? going for a jira excess, with a subtask for each qt5 forwardport? i'll endorse an exception if you present a credible process. have fun ... ___ 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] When is Qt 4.8 in Gerrit? (Was: Qt Commercial 4.8.0 release delta to LGPL version)
On Wednesday 11 January 2012 14:13:45 ext marius.storm-ol...@nokia.com wrote: In this particular case most of the contributions coming from Digia are contribs which were in Gitorious before, and them not being accepted put at least handled is our fault. I think for those its only fair that those are handled against 4.8, and then forward ported to 5.0. Once those original patches are handled, I assume Digia will follow the normal workflow by originating the patches in 5.0, and backporting them to 4.7/4.8. I think so, too. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
On Wednesday, 11 de January de 2012 12.49.27, Giuseppe D'Angelo wrote:
Up?
Nobody wants to discuss this?
It's above the bikeshed threshold :-)
First, you'll need to get a Nokian to import the PCRE sources. You cannot
submit them to Gerrit (not even to the commit you made) because that violates
the CLA. You're not the author. Please don't submit the PCRE code again --
just pretend it's there.
As for me, sorry I didn't review. It fell through the cracks of weekend is
coming.
The API looks now a lot more digestible. There are still a few methods that I
will need the documentation for, as I can't guess what they are from their
name (subject is probably an RE term that I don't know). The API around the
captured texts may need a few more rounds of discussion. The name cap
appeared in Qt 3 and if we're not able to keep source compatibility with Qt 4
anyway, maybe it's time to fix it too. The iterating methods, which are the
cool thing about this API, seem to be lost. I don't see how to get the
contents of that match.
Specific questions:
* QRegularExpressionMatch::captureCount returns actually the highest
index of a capturing group that matched something. Ideas?
(lastCapturedIndex?)
It seems that they are the same thing. captureCount looks fine if the other
methods also have capture in the name. Does this return the number of named
captures too? E.g. imagine I have two named captures in my RE and nothing
else. If they match, will that return 2?
If my RE has a capture that is optional and fails to match, how do I find out?
Imagine:
rx = /(foo)?(bar)/
rx =~ bar
In this case, the first capture failed to match anything. How do I know that in
the API?
* What should QRegularExpressionMatch::subjectOffset return when one
advances a match (f.i. by using
QRegularExpressionMatch::operator++)? The offset at which
logically the match is re-attempted (which is the ending position
of the current match + 1) or the one at which it is REALLY
attempted, which could be one or two charaters ahead, if the old
match matched an empty string? (Cf. the discussion in my last mail
about attempting /g matches against patterns that can match an empty
string)
I don't get the question because I don't know what a subject is, so I don't
know what a subject offset is supposed to be. Still, think about the use-case:
would someone need this offset? If so, why do they need it? What do they need
it for? Hopefully, that will help you answer the question.
* Should endPos(n) return the offset AT the end of the n-th capturing
group, thus enforcing the invariant matchedLength(n) = endPos(n) -
startPos(n) + 1 and implying that a capturing group of of length 0
returns endPos(n) = startPos(n) - 1 (which could seem strange on a
first look)? Or do you prefer endPos(n) to return the offset plus
one (i.e. immediately after the end of substring captured by the
n-th group), having then matchedLength(n) = endPos(n) -
startPos(n)? (3rd option: remove endPos(n) entirely)
How is this even a problem? Under which circumstances is the triad start,
length, end not holding?
endPos should be one after the last character matched, so that in all
circumstances
end = start + length
This holds for all containers, like QString, QByteArray, QVector, etc. If this
is difficult to visualise in the API, remove the end methods and keep only
start and length.
Does a string exactly match a pattern?
Version 1
QString str(a string);
bool matches = str.contains(QRegularExpression(\\Aa str\\w+\\z));
// matches == true
A non-initiated like me might write ^a str\\w+$. I'd expect that to work
and, by default, ^ is the beginning of the string and $ the end. Note I did
not set MultilineOption.
for (QRegularExpressionMatch match = re.match(str);
match.hasMatch(); ++match)
substrings match.cap();
This one mixes STL-style methods (operator++) with Java-style ones. Either we
do:
for (match = re.match(); match != re.end(); ++match)
or we do:
match = re.match();
while (match.hasNext()) {
/* whatever */
match.next();
}
--
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] Qftp removal
Can we get an addon module (project in gerrit) for putting standalone implementations of these removed features? I wouldn't expect a huge amount of commits, but the code (and associated examples/tests) needs to be moved there and converted from dll exports to static libraries. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of lars.kn...@nokia.com Sent: Monday, December 26, 2011 10:18 To: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Qftp removal On 12/24/11 12:24 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: I've been using it for a year now, have had no problems on Linux and Windows. I use it to check for application upgrade. Is there a recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp getting into Qt Commercial ? Qt Commercial and Qt Open Source are the same. If it's removed from one, it's removed from both. We can probably place it in a separate module for people who still need it. Yes, the code is there and while we really need to remove it from QtNetwork, we should provide a way for people to use it in their projects. IMO a static lib containing both QHttp and QFtp could be a solution. Cheers, Lars The recommended way is to use QNetworkAccessManager, which does not have API for listing directories. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
Yes, please. We need a name for it. How about qtnetwork4 ? I people are ok with the name, can you add the repo, Sergio? Who'd be willing to import the code and examples into that repo? Shane? Thanks, Lars On 1/11/12 3:26 PM, ext shane.kea...@accenture.com shane.kea...@accenture.com wrote: Can we get an addon module (project in gerrit) for putting standalone implementations of these removed features? I wouldn't expect a huge amount of commits, but the code (and associated examples/tests) needs to be moved there and converted from dll exports to static libraries. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of lars.kn...@nokia.com Sent: Monday, December 26, 2011 10:18 To: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Qftp removal On 12/24/11 12:24 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: I've been using it for a year now, have had no problems on Linux and Windows. I use it to check for application upgrade. Is there a recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp getting into Qt Commercial ? Qt Commercial and Qt Open Source are the same. If it's removed from one, it's removed from both. We can probably place it in a separate module for people who still need it. Yes, the code is there and while we really need to remove it from QtNetwork, we should provide a way for people to use it in their projects. IMO a static lib containing both QHttp and QFtp could be a solution. Cheers, Lars The recommended way is to use QNetworkAccessManager, which does not have API for listing directories. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
On Wednesday, 11 de January de 2012 14.48.55, lars.kn...@nokia.com wrote: Yes, please. We need a name for it. How about qtnetwork4 ? I people are ok with the name, can you add the repo, Sergio? Who'd be willing to import the code and examples into that repo? Shane? I'd say we should keep each independent class in its own static library build. So it would be qftp inside a kitchen sink repository. -- 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] wiki login issues fixed
Hi, I just wanted to inform you that we now run the wiki on the native mediawiki crowd authenticator for single sign logon. This fixes QTWEBSITE-326. The following issues are fixed: - https links require logins - impossible to log out from the wiki - different behavior between http and https links - no indication where to sign up for an account https is now transparently enforced during login and for all processes , so your password is safe. Note however that as with most of the sites that employ that technique, your session cookie can still be stolen. Given that the wiki can be rolled back, that's less of an issue though. Thanks to Robin Burchell for upstreaming the issue and to Sam Reed of MediaWiki fame for resolving our problems. Cheers, Daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
I'd think one project could handle all the removed features we want to support as static libraries e.g. qftp qhttp qsettings qt4support isn't a terrible name, unless it has too bad connotations. qt4removedapis is clear as well I'll take care of moving QHttp and QFtp. In general, the person removing an API from Qt should add it here for future removals. (assuming it's feasible and desirable to provide the API standalone) -Original Message- From: lars.kn...@nokia.com [mailto:lars.kn...@nokia.com] Sent: Wednesday, January 11, 2012 14:49 To: Kearns, Shane; thiago.macie...@intel.com; development@qt-project.org Cc: sergio.ahum...@nokia.com Subject: Re: [Development] Qftp removal Yes, please. We need a name for it. How about qtnetwork4 ? I people are ok with the name, can you add the repo, Sergio? Who'd be willing to import the code and examples into that repo? Shane? Thanks, Lars On 1/11/12 3:26 PM, ext shane.kea...@accenture.com shane.kea...@accenture.com wrote: Can we get an addon module (project in gerrit) for putting standalone implementations of these removed features? I wouldn't expect a huge amount of commits, but the code (and associated examples/tests) needs to be moved there and converted from dll exports to static libraries. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture.com@qt- project.org] On Behalf Of lars.kn...@nokia.com Sent: Monday, December 26, 2011 10:18 To: thiago.macie...@intel.com; development@qt-project.org Subject: Re: [Development] Qftp removal On 12/24/11 12:24 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: I've been using it for a year now, have had no problems on Linux and Windows. I use it to check for application upgrade. Is there a recommended way to do FTP transfers when QFtp is gone. Any chance of QFtp getting into Qt Commercial ? Qt Commercial and Qt Open Source are the same. If it's removed from one, it's removed from both. We can probably place it in a separate module for people who still need it. Yes, the code is there and while we really need to remove it from QtNetwork, we should provide a way for people to use it in their projects. IMO a static lib containing both QHttp and QFtp could be a solution. Cheers, Lars The recommended way is to use QNetworkAccessManager, which does not have API for listing directories. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. ___ ___ www.accenture.com Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
On Wed, Jan 11, 2012 at 5:22 PM, shane.kea...@accenture.com wrote: I'd think one project could handle all the removed features we want to support as static libraries e.g. qftp qhttp qsettings qt4support isn't a terrible name, unless it has too bad connotations. I don't really get what's wrong with that name, even with the stigma of it, because that's exactly what it is. It's a place to put stuff which isn't wanted in mainstream Qt due to deprecation, but which must be kept around to help ensure Qt 5's source compatibility promise of minimal porting effort. Sure, we might not like the fact that we need a 'support' library, but if we want to move this stuff, we have to put it somewhere, or break source compatibility. This is one case where we can't have our cake and eat it too. (+1 from me) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Contributors Summit: when and where
On 01/09/2012 11:42 PM, ext Turunen Tuukka wrote: Hi All, My preference is to definitely have the Contributors Summit before summer in order to focus discussions into what should be in 5.1. So mid-May to mid-June is best, even though 5.0 is still on its way at that time. If we have the event in September, we have very little time until 5.1 (if it is planned to be out before end on 2012). The only days that seem to suit a majority in this semester are during the week of June 18th. We still need to look at the availability of venues in Berlin for those dates. If it's not during these days then we hit the Summer holidays, and after that we start to be close (too?) to Dev Days. An alternative would be to combine both events (also good for optimizing costs). A collateral comment: I see the importance of planning the content of 5.1 and the usefulness of a face to face meeting with that goal. However, a good free software project shouldn't depend of a +200 people event to sort out that efficiently, and an alternative would be to do a much smaller roadmapping-fest limited to e.g. maintainers and special guests. Wider participation could be achieved with the maintainers before the meeting, at a component level. Maintainers should be able to invite extra people at their own criteria if they think they have something to share or push that would benefit the roadmapping meeting. In fact the same model of hackfest can be applied to other hot areas needing face to face sessions. Meetings of about 40 people 2-3 days are *a lot* easier to organize and sponsor than a whole Summit of 200 people. Even teleconferences, hangouts etc can be really productive, easy and inexpensive to setup when it comes to discuss live with the right 10 people (or so). Please let's explore and try out these possibilities. We are doing our best to have a great Qt Contributors Summit at the right time and place, but we can't have the pressure of 'stopping the Qt Project' in our necks. If you know what I mean. -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
2012/1/11 Thiago Macieira thiago.macie...@intel.com: Hi, thanks for the reply. :) First, you'll need to get a Nokian to import the PCRE sources. You cannot submit them to Gerrit (not even to the commit you made) because that violates the CLA. You're not the author. Please don't submit the PCRE code again -- just pretend it's there. No problem at all. We can wait until the 8.30 release and import that. As a future-proofing question: a Nokian is needed to upgrade PCRE as well, right? Btw, I'm pushing more updated stuff on gitorius, including some method documentation (I'm happier to push there since I can push even small bugfixes without causing emails to be sent, sanity checks, etc) https://qt.gitorious.org/~peppe/qt/peppes-qtbase/blobs/pcreregexp/src/corelib/tools/qregularexpression.h https://qt.gitorious.org/~peppe/qt/peppes-qtbase/blobs/pcreregexp/src/corelib/tools/qregularexpression.cpp The API looks now a lot more digestible. There are still a few methods that I will need the documentation for, as I can't guess what they are from their name (subject is probably an RE term that I don't know). Subject simply means the string you're matching your regexp against, so there's no confusion when one talks about strings (there are the pattern string and the subject string). The API around the captured texts may need a few more rounds of discussion. The name cap appeared in Qt 3 and if we're not able to keep source compatibility with Qt 4 anyway, maybe it's time to fix it too. Any suggestion is welcome (a verbose captured(int nth))? I could also rename startPos / endPos to startPosition / endPosition. The iterating methods, which are the cool thing about this API, seem to be lost. I don't see how to get the contents of that match. What do you mean? Specific questions: * QRegularExpressionMatch::captureCount returns actually the highest index of a capturing group that matched something. Ideas? (lastCapturedIndex?) It seems that they are the same thing. captureCount looks fine if the other methods also have capture in the name. Does this return the number of named captures too? E.g. imagine I have two named captures in my RE and nothing else. If they match, will that return 2? Yes, but because you get *three* capturing groups: the implicit group 0 (the whole match) and the two named ones. Therefore, the highest index that captured is 2. If the second didn't capture, then captureCount() would return 1. But if the first didn't capture and the second did, then the returned value is still 2! The idea is that you can use this value know to extract all the captured groups. The long explaination is that, in Perl regexps, a named capturing group has also the ordinary integer number, so you can get the two captures with cap(1) and cap(2) as well as cap(first) and cap(second). This has interesting consequences with the branch operator (|...) and/or with duplicated names. My doubt was a bit more general: a method called captureCount (although on the *match* class) could mislead people into thinking that that's the number of capturing groups in the regular expression itself, and not related about what's the index of the last capturing group that matched. If my RE has a capture that is optional and fails to match, how do I find out? Imagine: rx = /(foo)?(bar)/ rx =~ bar In this case, the first capture failed to match anything. How do I know that in the API? In that case cap(1) will return a null (not an empty!) QString. I can add some convenience for that (hasCaptured()?). How is this even a problem? Under which circumstances is the triad start, length, end not holding? The question was which triad should be holding? endPos should be one after the last character matched, so that in all circumstances end = start + length This holds for all containers, like QString, QByteArray, QVector, etc. If this is difficult to visualise in the API, remove the end methods and keep only start and length. Ok, then I'll do it. My point was that end = start + length implies that the actual ending is one codepoint less than what the end value is. F.i.: abc =~ /abc/ - start = 0 - length = 3 - end = 3 (But the actual ending offset is 2. string.at(3) is even out of bounds) Does a string exactly match a pattern? Version 1 QString str(a string); bool matches = str.contains(QRegularExpression(\\Aa str\\w+\\z)); // matches == true A non-initiated like me might write ^a str\\w+$. I'd expect that to work and, by default, ^ is the beginning of the string and $ the end. Note I did not set MultilineOption. You're right about multiline -- without it, \A and ^ are the same thing. In the general case you would use \A. You still need \z and not $ though, because $ matches even a newline before the ending (that is, a string\n matches ^a str\\w+$). This one mixes STL-style methods (operator++) with Java-style ones. Either
Re: [Development] QRegularExpression -- first round of API review
On Wednesday, 11 de January de 2012 17.53.17, Giuseppe D'Angelo wrote:
2012/1/11 Thiago Macieira thiago.macie...@intel.com:
Hi, thanks for the reply. :)
First, you'll need to get a Nokian to import the PCRE sources. You cannot
submit them to Gerrit (not even to the commit you made) because that
violates the CLA. You're not the author. Please don't submit the PCRE
code again -- just pretend it's there.
No problem at all. We can wait until the 8.30 release and import that.
As a future-proofing question: a Nokian is needed to upgrade PCRE as
well, right?
You cannot submit any changes you have not authored / don't have the copyright
on. The exactly language of the CLA you can find in the CLA :-)
The API looks now a lot more digestible. There are still a few methods
that I will need the documentation for, as I can't guess what they are
from their name (subject is probably an RE term that I don't know).
Subject simply means the string you're matching your regexp
against, so there's no confusion when one talks about strings
(there are the pattern string and the subject string).
Ok. But then see below...
The API around the
captured texts may need a few more rounds of discussion. The name cap
appeared in Qt 3 and if we're not able to keep source compatibility with
Qt 4 anyway, maybe it's time to fix it too.
Any suggestion is welcome (a verbose captured(int nth))? I could also
rename startPos / endPos to startPosition / endPosition.
I'd also add captured somewhere in the names of those too.
The iterating methods, which are the
cool thing about this API, seem to be lost. I don't see how to get the
contents of that match.
What do you mean?
The are at the bottom, seemingly useless. They're lost in the sea of other
methods. I could not find other methods that operated on the iterated
captures. I only found the random-access captures (cap family) and the
global result ones.
Specific questions:
* QRegularExpressionMatch::captureCount returns actually the
highest
index of a capturing group that matched something. Ideas?
(lastCapturedIndex?)
It seems that they are the same thing. captureCount looks fine if the
other
methods also have capture in the name. Does this return the number of
named captures too? E.g. imagine I have two named captures in my RE and
nothing else. If they match, will that return 2?
Yes, but because you get *three* capturing groups: the implicit group
0 (the whole match) and the two named ones. Therefore, the highest
index that captured is 2. If the second didn't capture, then
captureCount() would return 1. But if the first didn't capture and the
second did, then the returned value is still 2! The idea is that you
can use this value know to extract all the captured groups.
Then call it lastCaptureIndex, I guess. The count would have to be 3.
My doubt was a bit more general: a method called captureCount
(although on the *match* class) could mislead people into thinking
that that's the number of capturing groups in the regular expression
itself, and not related about what's the index of the last capturing
group that matched.
Keep the expression class with captureCount, as it's the number of groups in
the expression, not the number of captures succeeded.
In that case cap(1) will return a null (not an empty!) QString. I can
add some convenience for that (hasCaptured()?).
Convenience would be nice. Name TBD.
endPos should be one after the last character matched, so that in all
circumstances
end = start + length
This holds for all containers, like QString, QByteArray, QVector, etc. If
this is difficult to visualise in the API, remove the end methods and
keep only start and length.
Ok, then I'll do it.
My point was that end = start + length implies that the actual ending
is one codepoint less than what the end value is.
F.i.: abc =~ /abc/
- start = 0
- length = 3
- end = 3 (But the actual ending offset is 2. string.at(3) is even
out of bounds)
That is correct. end is one past the last last valid. It's the first that isn't
included.
You're right about multiline -- without it, \A and ^ are the same
thing. In the general case you would use \A. You still need \z and not
$ though, because $ matches even a newline before the ending (that is,
a string\n matches ^a str\\w+$).
But does it match a string\nfoo ?
Right. I'll devise something then. I'm not particulary happy with
either of them, because I can't imagine a good idea of having an
operator== / operator!= on a match result, and hasNext is non
trivial -- it actually requires doing the match. As of now this last
one can be rewritten as
match = re.match();
while (match.hasMatch()) {
/* ... */
match.advanceMatch();
}
which is indeed not consistent with Java iterators naming.
I agree. The result being also iteratable is weird. If it's not too complex,
having a
Re: [Development] QRegularExpression -- first round of API review
On Wednesday, 11 de January de 2012 16.43.11, Thiago Macieira wrote: Subject simply means the string you're matching your regexp against, so there's no confusion when one talks about strings (there are the pattern string and the subject string). Ok. But then see below... It didn't come up. It was about subjectOffset. If the subject is the string being matched against, then there is no offset. -- 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] What's the story for Qt5 on Harmattan?
Hi, Practically, since Qt Project has no plan to support Qt5 in Harmattan, I believe the Harmattan-specific code sits in its own clone repository (same as for QtonPi [1] and ), right? [1] https://qt.gitorious.org/qtonpi Xizhi Zhu (Steven) Software Engineer @ Qt Development Frameworks Nokia Mobile: +358 (0)50 480 1247 From: development-bounces+xizhi.zhu=nokia@qt-project.org [development-bounces+xizhi.zhu=nokia@qt-project.org] on behalf of Gil Quim (Nokia-DXM/SiliconValley) Sent: Tuesday, January 10, 2012 9:51 PM To: development@qt-project.org Subject: Re: [Development] What's the story for Qt5 on Harmattan? Hi, just speaking by myself since at least I have got a N950 in my hands running Qt 5... On 01/10/2012 06:16 AM, ext xizhi@nokia.com wrote: Hi, I would like to get some clarity regarding Qt5 on Harmattan... Based on the Wiki page here (http://developer.qt.nokia.com/wiki/Qt_5.0), Harmattan is not a Tier 1 platform. I also didn't find any Wiki page saying anything regarding Tier 2 and Tier 3 platforms. The only information I can find is from the Qt5-feedback mailing list [1], but I don't know any further plans / actions, except Oswald and Thiago pointed out Qt5 on Harmattan is still relevant [2]. Qt 5 in Harmattan is relevant to the Qt Project because Qt is deeply integrated and the Nokia N9 is publicly available. Needless to say, having platforms to develop and test Qt 5 is very important and Harmattan offers an open platform for handset form factor. Then could someone give some clarity to what scope Qt5 is supposed to be supported for Harmattan? The Qt Project as such has no plans of *supporting* Qt 5 in Harmattan, as the URL above explains. Note that there're certain essential (sub-)modules requiring Harmattan-specific back-end, e.g. bearer, PS, system info. Also, many add-on modules from ex-mobility also require Harmattan-specific back-end. Any one currently maintaining the code for Harmattan? Or at least any volunteers? Any CI support under plan? If there's nobody doing this, and no plan available, how can we keep Qt5 working on Harmattan? There are some initiatives going on and it would be great if a decent adaptation could come out of that. Some links: http://trac.webkit.org/wiki/BuildingQt5OnHarmattan http://qt.gitorious.org/~jturcotte/qt/qt5-harmattan http://labs.qt.nokia.com/2011/11/21/testing-qtquick-2-on-your-n9n950/ Qt 5 running in the Nokia N950 http://www.youtube.com/watch?v=ARpK4V3Jr40 -- Quim ___ 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
