[Development] Schedule for Qt 4.8.1
Hi All, We would like to release next version of Qt Commercial 4.8 around mid-March. It would be really great if we can again sync the LGPL and Commercial releases both in timing and content to the extent possible. If we agree that mid-March is a good target time for the next patch release, we should have as much as possible all the fixes in by end of February. Naturally a patch release will not have any new features, but there are some fixes that we are very much targeting to be in 4.8.1 such as ones needed for publishing apps in the Mac App Store. Since 4.8 was moved to gerrit, we have been actively redoing our merge requests, and quite much has already been merged into the 4.8 branch. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.comapplewebdata://7FB7E1CD-55A7-4FAD-B1A5-7721230C2E29/www.digia.com or qt.digia.comhttp://qt.digia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] new QtNetwork maintainer
Hi everybody, as some of you might know, our current maintainer for QtNetwork, Peter Hartmann, has left Nokia to start in a different job. Unfortunately that new job doesn't leave him with enough time to continue as the maintainer of QtNetwork, so he stepped down as the maintainer of QtNetwork. Shane Kearns has however stepped up and is willing to take over the position. I'm really happy that Shane is willing to take this job. He has a lot of experience with QtNetwork, and has been heavily involved with Qt development (actively working on the Symbian port) for quite a few years. So I'd like to nominate Shane for the position as the new maintainer of QtNetwork. According to the rules, he will need support from at least one other Maintainer. I'd also like to thank Peter for all the work he did on the module during his time at Nokia. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
You've correctly understood the problem, but the scale is less bad (takes a couple of minutes to exhaust 2GB limit of a 32 bit process using a loopback connection) Changing the default would mean behavior is the same as if you called setReadBufferSize(65536) in the application. Currently the default is setReadBufferSize(0), where 0 has the special meaning of unlimited. Performance tests should not break, because they are reading as fast as possible. There may be a degradation on one side if the writer is faster than the reader. UDP sockets losing data if buffering is exceeded is acceptable (it's supposed to be an unreliable service) I hadn't thought too much about UDP at this point, just TCP. The readAll issue is with QNetworkReply rather than QTcpSocket. There are two programming models in use for this: Simple model: 1. send request 2. wait for the finished signal from the reply 3. call readAll to get the data Good model: 1. send request 2. each time the reply emits bytesAvailable 2a. call readAll to get the currently buffered data 2b. save / process currently buffered data 3. when finished signal is received, call readAll a final time to get the tail The simple model tends to be used where the expected data is small. The good model tends to be used where the data size is unknown (e.g. browsers, download managers) We could give a much larger buffer size for QNetworkReply (e.g. 1MB) to catch reasonable small downloads, but this might be harder for developers (as they only see the buffer limit rarely) Yes, QIODevice allows partial writes, but Q*Socket always accepts all the data in the current implementation. I actually think this side is less of a problem, because the developer knows what kind of data they will be sending. Therefore they are in the best position to decide if they need write flow control or not -Original Message- From: andrew.stanley-jo...@nokia.com [mailto:andrew.stanley-jo...@nokia.com] Sent: 11 February 2012 11:36 To: Kearns, Shane Subject: Re: [Development] Default enabling inbound flow control on sockets Ok, let me verify I understand the problem: 1. If a Qt app is not processing the data, Sockets continue reading no mater what. 2. This results in no flow control, and on a 10gigE connection results in the Qt app potentially receiving ~1 gigabyte/sec stream of data. (assuming the HW/SW etc can handle it) 3. Qt app exhausts all memory within a couple of seconds. This seems like relatively brain dead behaviour. On large systems it's a problem, and on smaller devices outright dangerous. What will changing the default buffer size do? I assume you mean set a reasonable default to QAbstractSocket::readBufferSize(). This seems sensible, it will stop the stream and use appropriate flow control, if available with that protocol. 1. Break performance tests. 2. datagram (UDP) sockets will lose data. 3. As you said, readAll() may have problems, but it's also incompatible with sane network programming. How can I trust the other side is only going to send 50 bytes and not 4 gigs? There's no requirement for write buffering as well. Under Unix's can you can write data to a socket and have it not block and/or have it write less data than available. QIODevice accounts for this and write can return 0 bytes written. You can easily argue most programs don't handle this well. But at some point network links can't handle traffic at any arbitrary rate and flow control must kick in. Buffering is a short term solution. I think it's a good idea to have a build in limit. I think it avoids easily made mistake by developers. -Andrew On 10/02/2012, at 8:25 PM, ext shane.kea...@accenture.com wrote: The current default behaviour of Qt sockets is that they allocate an unbounded amount of memory if the application is not reading all data from the socket but the event loop is running. In the worst case, this causes memory allocation failure resulting in a crash or app exit due to bad_alloc exception We could change the default read buffer size from 0 (unbounded) to a sensible default value e.g. 64k (to be benchmarked) Applications wanting the old behaviour could explicitly call setReadBufferSize(0) Applications that already set a read buffer size will be unchanged The same change would be required at the QNetworkAccessManager level, as there is no point applying flow control at the socket and having unbounded memory allocations in the QNetworkReply. This is a behavioural change that would certainly cause regressions. e.g. any application that waits for the QNetworkReply::finished() signal and then calls readAll() would break if the size of the object being downloaded is larger than the buffer size. On the other hand, we can't enable default outbound flow control in sockets (we don't want write to block). Applications need to use the bytesWritten signal. QNetworkAccessManager already implements outbound flow
Re: [Development] new QtNetwork maintainer
On segunda-feira, 13 de fevereiro de 2012 14.05.36, marius.storm- ol...@nokia.com wrote: On 02/13/2012 07:17 AM, ext lars.kn...@nokia.com wrote: Shane Kearns has however stepped up and is willing to take over the position. I'm really happy that Shane is willing to take this job. He has a lot of experience with QtNetwork, and has been heavily involved with Qt development (actively working on the Symbian port) for quite a few years. So I'd like to nominate Shane for the position as the new maintainer of QtNetwork. According to the rules, he will need support from at least one other Maintainer. I'm not a maintainer, so cannot satisfy the OG requirement, but want to voice my +1. He's got my support. Shane has been working on Qt for years now, so I trust he'll do a good job. -- 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] Schedule for Qt 4.8.1
Hi Turunen Tuukka, could there please be an official VS 2010 64-bit binary release for Microsoft Windows for Qt 4.8.1 onwards? Thanks a lot kind regards, Wolfgang Baron ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Schedule for Qt 4.8.1
On segunda-feira, 13 de fevereiro de 2012 12.28.06, Turunen Tuukka wrote: Hi All, We would like to release next version of Qt Commercial 4.8 around mid-March. It would be really great if we can again sync the LGPL and Commercial releases both in timing and content to the extent possible. If we agree that mid-March is a good target time for the next patch release, we should have as much as possible all the fixes in by end of February. Naturally a patch release will not have any new features, but there are some fixes that we are very much targeting to be in 4.8.1 such as ones needed for publishing apps in the Mac App Store. Since 4.8 was moved to gerrit, we have been actively redoing our merge requests, and quite much has already been merged into the 4.8 branch. I think that it's a worthy goal. Let's try to have that release in March then. After that, I'd like to see 4.8 move into a periodic release mode, either in time or in number of changes. -- 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] Separation of QtQuick 1 from QtDeclarative repo
On Friday, February 03, 2012 12:17:35 lars.kn...@nokia.com wrote: Hi, It seems like this change broke qt/qttools, can you confirm this please ? I'd assume qttools doesn't include the qtquick1 repo as a dependency. It needs declarative in Qt4 because lupdate uses it to extract translations. This raises the question of whether lupdate will also need to use the Qt5 declarative module to extract QML2 translations, or will the language and features remain static so that the qtquick features will also be sufficient. On Monday, February 06, 2012 07:58:04 martin.jo...@nokia.com wrote: Yes, we are working on renaming the classes in the declarative module to either Qml... or QQuick... depending on case. There will be a period where using QtQuick 1 and 2 together is not possible, but we will sort this out as quickly as we can, hopefully without causing big disruptions to users of either library. This raises the question of whether the Qt5/declarative module will be renamed (if all classes in it are renamed Qml*) and if the module includes will be moved. The followup question is whether the qtqtuick1 module can be renamed QtDeclarative so that there is less source incompatibility (of the buildsystem and module includes). Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: The Future of QDoc
On Monday, February 13, 2012 09:04:22 casper.vandonde...@nokia.com wrote: Whatever is chosen (updating qdoc, or changing to Doxygen): The task is not small, and therefore it would be nice if there would be more contributors than just me and Martin Smith. Maybe it would be a good idea to have a sit-down at the Contributors Summit (if people are interested). Have you actually been in contact with Dmitri about merging the features and effort into doxygen? I looked at the mailing list and saw nothing. It would be a good start, and a good idea to bring him to the summit to if that turns out to be a good or welcome idea. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
On 02/13/2012 08:10 AM, ext shane.kea...@accenture.com wrote: Not sure. Is it a big problem? Or is it better to just continue as is, and let the applications that do have a problem set it to something reasonable to them instead? I'd probably suggest that we instead improve the output on that worst case failure to help devs fix the problems in their programs. $0.02 Ben qWarning allocates memory, so once the worst case happens, we can't give any output (unless we first handle the exceptions inside Q*Socket) It would be possible to print a warning when buffering exceeds some threshold we consider to be unreasonably large. We can also improve the documentation (it's not bad, but doesn't mention flow control explicitly) https://bugreports.qt-project.org/browse/QTBUG-14464 seems to be explained by missing flow control causing out of memory errors under load. Qt is not known for handling OOM cases, and we actually argue for the OS to handle it, and that the application (and its libraries) shouldn't have to think about memory not being available. (Too many error conditions and OOM handling all over the place to bring any real benefit for it anyways.) Here you are suggesting a behavior change to handle an OOM case, where the behavior will most likely cause valid applications to stop working, since they don't handle a (new and artificial) 64k in-buffer limit? Maybe we should rather allocate a buffer for qWarning output, allowing us to properly report an error condition before the application aborts? ^shrug^ but I rather not have applications start failing at random due to a failure to have a new limit. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
On Monday 13 February 2012 18:33:51 marius.storm-ol...@nokia.com wrote: On 02/13/2012 08:10 AM, ext shane.kea...@accenture.com wrote: Not sure. Is it a big problem? Or is it better to just continue as is, and let the applications that do have a problem set it to something reasonable to them instead? I'd probably suggest that we instead improve the output on that worst case failure to help devs fix the problems in their programs. $0.02 Ben qWarning allocates memory, so once the worst case happens, we can't give any output (unless we first handle the exceptions inside Q*Socket) It would be possible to print a warning when buffering exceeds some threshold we consider to be unreasonably large. We can also improve the documentation (it's not bad, but doesn't mention flow control explicitly) https://bugreports.qt-project.org/browse/QTBUG-14464 seems to be explained by missing flow control causing out of memory errors under load. Qt is not known for handling OOM cases, and we actually argue for the OS to handle it, and that the application (and its libraries) shouldn't have to think about memory not being available. (Too many error conditions and OOM handling all over the place to bring any real benefit for it anyways.) Here you are suggesting a behavior change to handle an OOM case, where the behavior will most likely cause valid applications to stop working, since they don't handle a (new and artificial) 64k in-buffer limit? Maybe we should rather allocate a buffer for qWarning output, allowing us to properly report an error condition before the application aborts? ^shrug^ but I rather not have applications start failing at random due to a failure to have a new limit. Here the problem is not really OOM, but bad putting way too much data structure into memory. QByteArray is not designed to contain huge data (2GiB is really the maximum, only because we use int for indexes) and stuff like readAll() will crash if that is hapenning. The second problem seems to be that QTCPSocket buffers everything, it does not matters if the program does anything with it or just let the event loop spin. If QTCPSocket did not buffer, the OS would buffer a bit, then drop the packet, so sender's TCP algorithms would reduce the rate of sending letting the time for the application to process. This is my naïve interpretation of the problem and I might be wrong here. But I think, indeed, the network and IO stack should do something against that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
On 02/13/2012 12:33 PM, ext marius.storm-ol...@nokia.com wrote: ^shrug^ but I rather not have applications start failing at random due to a failure to have a new limit. ..handle a new limit. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
On sexta-feira, 10 de fevereiro de 2012 19.25.04, shane.kea...@accenture.com wrote: We could change the default read buffer size from 0 (unbounded) to a sensible default value e.g. 64k (to be benchmarked) Applications wanting the old behaviour could explicitly call setReadBufferSize(0) Applications that already set a read buffer size will be unchanged [snip] This is a behavioural change that would certainly cause regressions. e.g. any application that waits for the QNetworkReply::finished() signal and then calls readAll() would break if the size of the object being downloaded is larger than the buffer size. As you said yourself, there's a huge potential for regressions here, especially with a limit as low as 64k. So I am unsure whether we should do this at all. We could apply a high buffer size, like 1 MB. That's probably enough to contain most data files being downloaded and yet avoid exploding by OOM. On a modern embedded system, an application would need to be downloading 50 items in parallel (which means from at least 9 different servers) before it started to get into trouble. -- 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] Changes to the Jira roles and workflow
Maybe you're looking at a triage role, if the role is prioritizing and assigning of tasks among a team that is mostly funded by one company. Another role we need in JIRA is contributor. This is somebody who is not a reviewer, but can still be assigned tasks transition their assigned tasks through the normal workflow. Ideally, anyone who has had a patch accepted should be given this level of access if they want it.* For example, to work on bugs related to code they previously submitted. Also, this covers most Nokia (or other organization) engineers who are not approvers. I'm hoping abuse of JIRA privileges is rare, but it should also be easy to revoke them if needed. *Some people will contribute a patch for a bug they found in their project that uses Qt, and we don't want to discourage this by giving unwanted responsibility. -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Alan Alpert Sent: 09 February 2012 22:26 To: development@qt-project.org Cc: j...@qt-project.org Subject: Re: [Development] Changes to the Jira roles and workflow On Thu, 9 Feb 2012 12:58:40 ext marius.storm-ol...@nokia.com wrote: Hi, ... There is some discussion over if we should burden maintainers with Release Management work. There is a suggestion of a new workflow Nokia Engineer - no privileges in Gerrit only in Jira. That role might be useful, but please don't call it Nokia Engineer. Even if we don't expect anyone to ever volunteer to do task management roles, Qt as an open project could grow to other companies. Calling it Task Manager or Issue Secretary (or something along those lines that's not a joke ;) ) will mitigate the risk of having to change the name again later. ... Default Assignee There is call for discussion around default assignee - is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer? The theory I was taught was that you don't use your 'tasks assigned to me' list as your list of your in-progress bugs. You use your 'tasks assigned to me and listed as in-progress' for that list. So assignment merely means If someone's going to look at this bug, it'll probably be this guy first. If you're working on a bug and don't want people to take it away, you mark it as in-progress. Then the tasks which are up for grabs are the ones assigned to the maintainer (or anyone, actually) which are not marked as 'in- progress'. On the 'unassigned' suggestion, I think that could only work if there's an easy way to find the correct maintainer for a component. Currently the table in qt-project contains some data, which is nice, but it's just not convenient enough or obvious enough to work with JIRA. Default assignee has basically been the way people find maintainers for bug reporting (at least), if you take that away then something else is needed. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks ___ 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] Changes to the Jira roles and workflow
On 02/13/2012 01:27 PM, ext shane.kea...@accenture.commailto:shane.kea...@accenture.com wrote: Maybe you're looking at a triage role, if the role is prioritizing and assigning of tasks among a team that is mostly funded by one company. Another role we need in JIRA is contributor. This is somebody who is not a reviewer, but can still be assigned tasks transition their assigned tasks through the normal workflow. Ideally, anyone who has had a patch accepted should be given this level of access if they want it.* For example, to work on bugs related to code they previously submitted. Also, this covers most Nokia (or other organization) engineers who are not approvers. The contributor role in Jira was part of the original recommendation: Map old roles over to OG roles The current suggestion is: Reports - User Developer - Contributor Assignee - Contributor QA - Approvers RM - Maintainers - note, discussion over this Note the Developer + Assignee - Contributor transition in the roles, meaning that the Contributor role can be assigned tasks. -- .marius I'm hoping abuse of JIRA privileges is rare, but it should also be easy to revoke them if needed. *Some people will contribute a patch for a bug they found in their project that uses Qt, and we don't want to discourage this by giving unwanted responsibility. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new QtNetwork maintainer
On 2/13/12 4:17 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 13 de fevereiro de 2012 14.05.36, marius.storm- ol...@nokia.com wrote: On 02/13/2012 07:17 AM, ext lars.kn...@nokia.com wrote: Shane Kearns has however stepped up and is willing to take over the position. I'm really happy that Shane is willing to take this job. He has a lot of experience with QtNetwork, and has been heavily involved with Qt development (actively working on the Symbian port) for quite a few years. So I'd like to nominate Shane for the position as the new maintainer of QtNetwork. According to the rules, he will need support from at least one other Maintainer. I'm not a maintainer, so cannot satisfy the OG requirement, but want to voice my +1. He's got my support. Shane has been working on Qt for years now, so I trust he'll do a good job. Full support from my side as well. We need somebody like Shane to take care of our QtNetwork module, and I am more than sure he'll do a great job there :) Cheers, -Cristiano -- 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
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ruwrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it offloads much of the resource requirements from the Qt-Project infrastructure. What then will be a public repo address on Gitorious for get/clone other people a code libraries? It's up to you really. If you don't want to mirror it to Gitorious on a regular basis, you can just use the Gerrit repo as the primary
[Development] Something is wrong in QFontEngineFT::loadGlyph
Hi, While using Qt's elidedText function http://developer.qt.nokia.com/doc/qt-4.8/qfontmetricsf.html#elidedText i noticed the function was dog slow. For just 1000 entries (each 250 chars) eliding them to 200px took about 190ms on windows and 100ms on linux. Using that for drawing is noticeable slow. I haven't actually tried that, but i certainly would notice that and in the longer run that is my intention. So, i started playing with it in an attempt to get it blazing fast. And i got there. On windows i have a speedup of 39x (same job only takes 5ms) and on Linux i got a speedup of 10x (same job takes 10ms, side effect is that linux while 10x faster is now slower then windows.. odd), Those speedups are nice but it tasted like more so i went on to profilling. I already knew the QFontMetricsF::width was the function dragging everything down and a kcachegrind seems to indicate the same. Note for the speedups, i got them mostly by cashing the width of the used character thus avoiding the width function as much as possible. This is the path that width() takes till the point of calling the freetype functions: QFontEngineFT::stringToCMap QFontEngineFT::recalcAdvances QFontEngineFT::loadGlyph loadGlyph is where i think something odd is going on. http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line812 Note the last parameter: fetchMetricsOnly ... The path it took had fetchMetricsOnly set to true : http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/text/qfontengine_ft.cpp#line1611. That leads me to think that this function is only going to fetch the metrics of the glyph, not render it! The opposite is the case. It's rendering it and that is the part that takes long. So, am i right here? Is this function doing to much? Remember, we come from the width() function. All we actually need is the width of the glyph, that's it. Actually, if you look in that function for the fetchMetricsOnly occurrence you'll see that it's only used in one place and there it doesn't seem to do a lot with metrics. It kinda looks like the original implementer of this has some idea, but never finished implementing it. Or am i wrong here? Kind regards, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Given that the QSerialDevice developers have accepted the CLA for the project effective from start of the project, the project is now open for licencing both under LGPL and commercial license; just like any other module in Qt. AFAIK, though IANAL. -- Sent from my Nokia N9 On 2/13/12 16:56 ext Angel Perles wrote: Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ruwrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious location. And we prefer most people to use those as the primary clone location, since it
Re: [Development] Schedule for Qt 4.8.1
On 13.2.2012 18.32, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 13 de fevereiro de 2012 12.28.06, Turunen Tuukka wrote: Hi All, We would like to release next version of Qt Commercial 4.8 around mid-March. It would be really great if we can again sync the LGPL and Commercial releases both in timing and content to the extent possible. If we agree that mid-March is a good target time for the next patch release, we should have as much as possible all the fixes in by end of February. Naturally a patch release will not have any new features, but there are some fixes that we are very much targeting to be in 4.8.1 such as ones needed for publishing apps in the Mac App Store. Since 4.8 was moved to gerrit, we have been actively redoing our merge requests, and quite much has already been merged into the 4.8 branch. I think that it's a worthy goal. Let's try to have that release in March then. Excellent. As it is a patch release, I think it will be just fine that everybody knows the timing, and can handle the fixes accordingly. After that, I'd like to see 4.8 move into a periodic release mode, either in time or in number of changes. For the patch releases there always needs to be the capability to issue one quickly in case something urgent comes up (like a serious security issue). Having the patch releases strictly tied into some intervals, or amount of fixes does not work well in my opinion. But I do agree that some criteria should be agreed upon, so that it is easy to know when the time is right for a release. Then it should also be noted that 4.8 is a bit of a special case as the last of the Qt 4 series. It needs a more patch releases than I think will be needed for Qt 5 (with regular 6 months for the minor releases it should be very easy to migrate between these). I think good timing for the 4.8 patch releases would the roughly: 4.8.1 in mid-March 4.8.2 in end-May 4.8.3 in end-September 4.8.3 in mid-January 2013 Which leads to about 3 month intervals, that should be suitable for increasing the stability of this already mature base. As said, we need to also see what makes sense content wise, and be prepared for a quick release if something urgent comes up. I am very happy to hear your feedback and thoughts on this. After the discussion it would be good to update the wiki with jointly agreed release plan for 4.8. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi all. Yes, most likely LGPL + commercial. So, there is no reason to worry. Best regards, Denis 14.02.2012, 04:08, marius.storm-ol...@nokia.com: Given that the QSerialDevice developers have accepted the CLA for the project effective from start of the project, the project is now open for licencing both under LGPL and commercial license; just like any other module in Qt. AFAIK, though IANAL. -- Sent from my Nokia N9 On 2/13/12 16:56 ext Angel Perles wrote: Hi Denis, I have a question about the license for QSerialDevice. In gitorious it appears as GPLv3. I think it could be interesting to have a more permisive licensing option such as LGPL or BSD. This will allow to push forward this library compared with others such as QextSerialPort with not established license. Others guys and me (users of QextSerialPort) are seeking for an appropiate library for collaborating. Best regards, Àngel El 11/02/12 18:28, Denis Shienkov escribió: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a
Re: [Development] Importing sahumada: Can you import http://gitorious.org/qserialdevice/qserialdevice (the 2.0 branch) into playground/QtSerialPort
Hi all. Well, what with the Code Review? Who controls it? I prepared the first review here: http://codereview.qt-project.org/16042 1) Interested in the question about the type of macro QT_BEGIN_NAMESPACE_XXX, QT_END_NAMESPACE_XXX, etc. What a way to more correct: leave these macros (as in the examples of projects from the playground Gerrit), or replace them with standard type QT_BEGIN_NAMESPACE, etc. (for example, the module QtSensors, etc.)? 2) Used somewhere in the build scripts, etc. variables and PUBLIC_HEADERS PRIVATE_HEADERS in *. pro files of certain modules? That is, These names are reserved specifically for the generation and integration of modules, or just this names and they are not used anywhere else except *.pro: .. HEADERS += $$PUBLIC_HEADERS $$PRIVATE_HEADERS .. ?? Best regards, Denis 11.02.2012, 21:28, Denis Shienkov scap...@yandex.ru: Hi all. I prepared for the first QtSerialPort review. But then I do not know what to do: Who will review my changes? Who will do the audit? Someone, please check the code, because I still have not figured much in the features by: http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt Best regards, Denis 09.02.2012, 23:46, marius.storm-ol...@nokia.com: On 09/02/2012 13:26, ext Denis Shienkov wrote: Hi Marius. I have a few more questions (or offers): 1) Perhaps, instead of: ... and start pushing to refs/for/2.0 to the Gerrit repo. ... done refs/for/master? Because for the main branch is gerrit master, and not 2.0 (or am I misunderstanding something?). Sure, whatever you prefer. Gitorious' 2.0 branch was pushed to both 2.0 and master, since Gerrit requires a 'master' branch. We didn't import the Gitorious master branch, since I think you only rebased the 2.0 branch to avoid the commits without CLA signoff. How you proceed, with commits in the master or 2.0 branch is up to you as the maintainer. 2) It may be worth in the current repository QSerialDevice Gitorious marked as deprecated (well, or something like that), and instead it create a new one with a new name (ex. QtSerialPort), etc. The reason is that QSerialDevice will not reflect the inner essence, after integration, and will mislead the majority of public users. Sure, I agree it's probably cleaner to do that. (Our internal sync script also infact requires the repositories to be named the same in Gerrit and in Gitorious.) 3) Let us define - what the class name give, with prefix Qt, Q or no prefix? I looked at some of the projects Gerrit without CI (eg qtprocessmanager, qtjsonstream) and found that a all class names without the prefix. I also stick to this style? See http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#Using_the_module_name_in_application_code_and_documentation For Qt Add-On Modules, a C++ namespace is required to avoid class naming clashes with other modules in the public API. For the Qt Foo module the namespace would be QtFoo. Exception: in order to keep source compatibility with Qt 4, no namespace is required for former Qt 4 modules. When naming classes, the best practice is use simple non-prefixed class names within the C++ name space. Naming classes of add-ons like QMyClass is also OK. 4) In the header of each source file, keep a reference to the original authors, like me, or mention only Nokia? Nokia did not develop the code, and must not be referenced as the author. Copyright remains with the author. 5) How to make an example of the structure of the project is the addon for QtSerialPort (in order to make the image and likeness), from any Addon-project? Or maybe there is a specific example of a good where to get the project structure for addon? http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt#The_structure_of_a_new_module_repository -- .marius 08.02.2012, 22:08, marius.storm-ol...@nokia.com: On 2/8/12 11:59 AM, ext Denis Shienkovscap...@yandex.ru wrote: Hi Marius. I do not understand this bit: -- -- For the other Qt repos we treat the Gitorious repo as public repo, so most people will clone from there. Then we regularly push from Gerrit to Gitorious to keep them in sync. However, we disable Merge Requests in Gitorious, since we want to force all contributions through the Gerrit system. -- -- ie I and other special/selected developers will commits/push to Gerrit, and then tested and approved by the pieces of code will be sent to Gitorious? Well, not more special than having a Jira/Gerrit account with an accepted CLA agreement :) For the Qt Essential modules we have a script which automatically pushes the latest changes to the Gitorious
