Re: [Development] QtSerialPort addon Wiki. Need spelling checking for English.
Hi Davet. 1. QAbstractSocket is etalon, example to follow for class SerialPort. ie most likely this: - SerialPort is inspired by QAbstractSocket / follows the API-conventions defined by QAbstractSocket? 2. QPrinterInfo is etalon, example to follow for class SerialPortInfo. Ie general principles of architecture classes QAbstractSocket and QPrinterInfo adopted to QtSerialPort module (their behavior and implementation). Best regards, Denis. 12.03.2012, 23:22, Davet Jacques davetjacq...@yahoo.fr: Hi, I went over it and fixed most of the text to make it grammatically correct and nicer to read, but I don't understand what the following paragraph is supposed to mean (in the SerialPort section): For the standard implementation of the internal structure and interfaces was adopted class QAbstractSocket, as one of the most suitable in terms of functionality. In this case, the internal structure used by QAbstractSocket, was significantly revised and simplified. standard implementation Are there multiple implementations? Or is it simply supposed to refer to the core / technical foundation of the implementation? internal structure and interfaces was adopted ... internal structure [...] was significantly revised and simplified Does this mean ... - SerialPort is a subclass of QAbstractSocket? or - SerialPort is a fork of QAbstractSocket? or - SerialPort is inspired by QAbstractSocket / follows the API-conventions defined by QAbstractSocket? The same goes for this similar paragraph (in the SerialPortInfo section): For the standard implementation of the internal structure and interfaces was adopted class QPrinterInfo, as one of the most suitable in terms of functionality. Again: What exactly is the relation between the SerialPortInfo and QPrinterInfo classes? Regards, Davet Jacques ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Re : QtSerialPort addon Wiki. Need spelling checking for English.
Hi. Yes, something like this. Best regards, Denis 13.03.2012, 00:47, 1+1=2 dbzhang...@gmail.com: On Mon, Mar 12, 2012 at 12:22 PM, Davet Jacques davetjacq...@yahoo.fr wrote: Hi, I went over it and fixed most of the text to make it grammatically correct and nicer to read, but I don't understand what the following paragraph is supposed to mean (in the SerialPort section): For the standard implementation of the internal structure and interfaces was adopted class QAbstractSocket, as one of the most suitable in terms of functionality. In this case, the internal structure used by QAbstractSocket, was significantly revised and simplified. standard implementation Are there multiple implementations? Or is it simply supposed to refer to the core / technical foundation of the implementation? internal structure and interfaces was adopted ... internal structure [...] was significantly revised and simplified Does this mean ... - SerialPort is a subclass of QAbstractSocket? or - SerialPort is a fork of QAbstractSocket? or - SerialPort is inspired by QAbstractSocket / follows the API-conventions defined by QAbstractSocket? In my opinion, It should be this: SerialPort is inspired by QAbstractSocket, and their implementation have similiar architecture. Best regards, Debao ___ 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] Breaking up QtPlatformSupport
We can talk about making it into a nicer API in a future version of Qt, but for Qt 5, we should keep it as it is. Understood. I'm not against out-of-qtbase plugins. I am against forcing them to use private and changing API like QtPlatformSupport. Ah, now I see. This is where the missmatch is. QPA is by definition private apis that might change. It will stay like that for Qt 5. Maybe for Qt 6 we'r so confident that we might lock it down. Normally I define it like so: There is absolutely no abi, what so ever. You cant expect to take a plugin built with one sha, to be built with another sha... So 5.0 plugins will not work with 5.0.1 plugins. There is also no API guarantee. That means we won't break api just because we like to, but it also means it CAN change. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
Hi All, Although late for 4.8.1 this is a good discussion to have. I think the key question that needs to be answered is: Do we aim to have a model where it is typically ok to take always the latest that exists in the repository? If the answer is yes, agreeing not to branch will support the goal. Drawback is the fact that putting a single fix of top of otherwise working set will not be feasible. For a patch release it should not be a significant drawback. And as all things that go in are bug fixes anyway it should always be ok to have a few more. Certainly for the minor releases we need to have a branch in order not to hurt development of new things while getting into release maturity. But for patch releases it should be feasible to keep release maturity at any time. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.com or qt.digia.com On 12.3.2012 19.45, shane.kea...@accenture.com shane.kea...@accenture.com wrote: On Fri, Mar 09, 2012 at 07:16:24PM +, ext shane.kea...@accenture.com wrote: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix \ fix(rc2)-fix(v4.8.1) this is no option, because it loses the tag from the history. traditionally we have merged back the release branch to the maintenance branch (and thus to master), which means that we have all those cherry-picks twice in the history. try to read *that*. therefore the only clean options are either a) just don't create a branch or b) if you create a branch, then apply any fixes which are supposed to be in it *only* to that branch, so it can be cleanly forward-merged. The full picture including the merge back would look like: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M \ / fix(rc2)-fix(v4.8.1)-. The tag has to be on the branch (if there is a branch), otherwise git checkout v4.8.1 doesn't give the same thing as the release tarball. Tools that show the history including branches (e.g. gitk) would give a picture like what's above, git log will show the cherry picks twice in the history. The history is unreadable for v4.8.0 because of the 7 parallel staging branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane and readable. I believe that git log v4.8.1.. includes the commits which came in with the merge (anything on 4.8 but not on 4.8.1 branch) 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
On Tue, Mar 13, 2012 at 07:16:35AM +, ext Turunen Tuukka wrote: Certainly for the minor releases we need to have a branch in order not to hurt development of new things while getting into release maturity. But for patch releases it should be feasible to keep release maturity at any time. this is fallacious logic. the stable branch is created long before the minor release, so the commits going into the branch are only fixes as well. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt5 build support mips toolchain
On terça-feira, 13 de março de 2012 09.22.21, tang ke wrote: hi all: I want to build the qt5 with cross-toolchain, the target arch is mips, the qt5 build support it? When I last checked the build with Yocto's MIPS toolchain, it worked. -- 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] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 12. mars 2012 23:45, skrev ext Rohan McGovern: Richard Moore said: On 12 March 2012 17:56,kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? Here's the commits which were needed: Thanks for the overview, Rohan. http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded dependencies to QtWidgets and QtOpenGL - I don't think this one resolves any test failures. It does; by switching to using QGuiApplication for those tests, we effectively sidestep a change in QApplication font loading behavior due to http://codereview.qt-project.org/#change,18621, which broke a test on Mac. http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable test as insignificant. - marks tst_qquickpixmapcache as insignificant, doesn't actually resolve the problem, so the real issue may not yet be understood Yep, it's still not understood. I added a comment to the change about the symptom, but I don't know how to reproduce it. http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest. http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit. http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler in QQuickItem. - all of these were failing due to changes in double-click semantics, apparently a bug fix: commit b371f3f943703840d0dfbe30505018bcca06e260 Author: Laszlo Agocslaszlo.p.ag...@nokia.com Date: Tue Mar 6 16:09:09 2012 +0200 Fix double click handling. Yes, the mouse event handling change was the most serious source of failures. In addition, there was a change in QtNetwork last week that I reverted because it caused qtdeclarative autotests to crash. That one is being reapplied again in http://codereview.qt-project.org/#change,19591, hopefully with the crashes gone. http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses deleted QML engine - apparently the test reads invalid memory, but doesn't actually crash on most platforms. It might be that the qtbase changes, due to changing the layout of a few things in memory, caused it to start crashing on at least one platform. It turned out that valgrind was already complaining about this on platforms where it didn't crash. Would be good if there were a CI that ran the tests through valgrind, maybe once a week or so. In the qtbase/api_changes branch, there was a change in QString::mid() (the handling of a negative position argument) that caused tst_qquicktextinput::getText to fail. It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. By doing so we can save a lot of time we otherwise have to spend on failed CI rounds and tracking down changes that broke other modules. Regarding flaky tests: This is a nightmare right now since it makes _any_ integration so darn unpredictable. The CI takes ~1.5 hours to build qtdeclarative and run tests on all platforms. Everything might look green and dandy on the seven first machines, but then the last one gets to 99% before failing some test. Then we need to investigate whether that failure is due to a new change in e.g. qtbase, or whether it's flaky, apply some fix (e.g. mark the test as insignificant), and do a whole new round of CI. So please, be careful when adding new tests that rely on timing/event loop specifics. Due to the very nature of QtQuick (interaction tests, networking), I guess it has a higher likelyhood of having flaky tests than other modules. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Project Server Maintenance - Thursday March 15, 08:00 - 08:30 CET
Hi, Our hosting provider need to do a quick update on some of our servers related to qt-project.org. The affected services are: * Gerrit / Code Review - http://codereview.qt-project.org/ * Mailing lists - http://lists.qt-project.org/ * Wiki - http://wiki.qt-project.org/ The services will be unavailable for some minutes during the maintenance window, and are expected to be running as normal by 08:30 CET. Regards -- Matias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project Server Maintenance - Thursday March 15, 08:00 - 08:30 CET
On 13 March 2012 13:27, Matias Rand matias.r...@nokia.com wrote: Hi, Our hosting provider need to do a quick update on some of our servers related to qt-project.org. The affected services are: * Gerrit / Code Review - http://codereview.qt-project.org/ * Mailing lists - http://lists.qt-project.org/ * Wiki - http://wiki.qt-project.org/ The services will be unavailable for some minutes during the maintenance window, and are expected to be running as normal by 08:30 CET. But... when is the update scheduled for? Tomorrow (14 March) morning? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project Server Maintenance - Thursday March 15, 08:00 - 08:30 CET
On 03/13/2012 02:32 PM, ext Giuseppe D'Angelo wrote: On 13 March 2012 13:27, Matias Randmatias.r...@nokia.com wrote: Hi, Our hosting provider need to do a quick update on some of our servers related to qt-project.org. The affected services are: * Gerrit / Code Review - http://codereview.qt-project.org/ * Mailing lists - http://lists.qt-project.org/ * Wiki - http://wiki.qt-project.org/ The services will be unavailable for some minutes during the maintenance window, and are expected to be running as normal by 08:30 CET. But... when is the update scheduled for? Tomorrow (14 March) morning? It's stated in the subject, but to make it clear, the maintenance window is set to: Thursday March 15 08:00 - 08:30 CET -- Matias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 13. mars 2012 12:08, skrev ext Kent Hansen: It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. Let me add - meta-type/QObject kernel changes to that list. Kent ___ 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
Hi, Some updates on this. After yesterday's discussion it was decided to keep QRegExp in QtCore as a deprecated class. At the same time all QRegExp-related classes or overloads get deprecated as well (although probably not disabled with QT_DEPRECATED_SINCE because very few of them are actually inline). The main reason for keeping QRegExp is the possible silent breakage due to attempting to translate regexps or any other behavioural changes; especially if someone tried to outsmart QRegExp. So unless something changes again QRegExp is going away in Qt 6. 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 Not needed anymore since qregexp stays there - rcc: one single use, very easy to rewrite without regexes Not needed anymore since qregexp stays there - uic: #includes are unnecessary; remove immediately Done - QtCore API: * QString non-const QRegExp: use templates to support QRegExp in inline code (find a way), or simply stop supporting this Not needed anymore since qregexp stays there * QMetaType QVariant: let RegExp point to the new class Done (+2 but not merged yet). I added new methods instead: http://codereview.qt-project.org/19514 * everywhere else (including QStringList): replace with the new class Replace or just add overloads? For now I've just started to add overloads: - QString (+2, not merged yet) http://codereview.qt-project.org/18666 - QObject: http://codereview.qt-project.org/19723 - QStringList: http://codereview.qt-project.org/19765 - QSortFilterProxyModel: it has *four* QRegExp-like setters (!), must find a way to keep the API sane. - QtCore internal uses: use the new class or rewrite (if possible, I recommend a non-regex globbing in QDir and QDirIterator). This is (apparently) opening a Pandora's box, since both QRegExp::Wildcard and WildcardUnix have very strange behaviours w.r.t. to escaping, and I'm not too willing to touch them being so critically tied to pretty much everything. But this could lead to a discussion about the behaviour of an eventual QRegularExpression::fromWildcard. 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. Keep QtXml as-is? Or refactor rcc to use QXmlStreamReader instead of QDom, then remove Done - QtGui API: * QTextDocument: replace with the new class Will probably need help with this since I don't know anything about it. * QRegExpValidator: move alongside QRegExp, but add a new class to QtGui WIP (QRegularExpressionValidator). - QtNetwork API: * QSslSocket (globbing functions for certificates): replace with new enums WIP; this will be a SIC - 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. It's unlikely that I'll touch any of these classes, but they can switch anytime now... We also modify QRegExp to add: QRegExp(const QRegularExpression ); // implicit operator QRegularExpression() const; At this point I might just work to a toRegularExpression() method for the QRegExp-QRegularExpression conversion -- I just need to know what I'm supposed to do with the XSD regexp syntax, i.e. if there's any further interest in keeping it supported or not (since apparently it has never worked properly, see my other mail). Opinions? Comments? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] qdoc3 will be removed from qtdoc (and creating packages for Alpha)
Hi all, I just put the patch in that removes qdoc3 from qtdoc. From then onwards there will only be qdoc in qtbase. It is in Gerrit as http://codereview.qt-project.org/#change,19829 That is one of the changes I think we need for the alpha (to not ship both qdoc3 and qdoc) Another thing we need is a correct documentation footer. I put those in Gerrit as 19825 and 19826. Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Demos, examples, docs etc for Alpha release
(Sorry for top-posting from this web client) Thank you for the list of modules. Can I do the following changes to the wiki? 1. Move the list of modules at http://qt-project.org/wiki/Qt_5.0#66036ddf6d03c9ce1fc742741417f128 to two new pages: - Qt Essential Modules - Qt Add-on Modules Reasoning: the are not roadmap anymore and they are not even 5 exclusive. They are simply Qt modules in trunk. This way it's easier to link to them from other pages (e.g. Alpha release notes) without having to drag the whole Qt 5 Roadmap content. 2. Mark somehow (e.g. different background color) the modules available in the alpha release. Reasoning: to have a clear idea of the status of those modules. 3. Try to improve the names and descriptions of each module. Reasoning: now it's confusing. For instance, is qtjsbackend = V8 JavaScript engine? 4. Link each module to whatever landing page there is available somewhere in the wiki, if available. Reasoning: now only the insiders can bridge that list with whatever info is somewhere else. -- Quim From: Storm-Olsen Marius (Nokia-MP/Austin) Sent: Monday, March 12, 2012 9:05 PM To: Gil Quim (Nokia-DXM/SiliconValley) Cc: development@qt-project.org; Hausmann Simon (Nokia-MP/Oslo) Subject: Re: [Development] Demos, examples, docs etc for Alpha release On 12/03/2012 18:10, ext Quim Gil wrote: Also, a basic question: where can someone find the actual list of Essential and Add-on modules that will be included in the Alpha? A Work-in-progress list is fine, now the only reference I have is a slide from last October-November. The current release script generates a package (890MB tar = 251MB tar.gz), correlated with the categorization of modules at http://qt-project.org/wiki/Qt_5.0 and corrected with some recent discussions between Henry, Lars and Thiago, this list of modules: Qt Essentials: qt3d qtcore qtdeclarative qtgui qtjsbackend qtlocation qtmultimedia qtnetwork qtsql qttestlib qtwebkit Qt Add-ons: qlalr qtactiveqt qtconcurrent qtconnectivity qtdbus qtdoc qtdocgallery qtfeedback qtgraphicaleffects qtimageformats qtjsondb qtphonon qtpim qtplatformsupport qtprintsupport qtqa qtquick1 qtrepotools qtscript qtscripttools qtsensors qtsvg qtsystems qttools qttranslations qtwayland qtwebkit-examples-and-demos qtwidgets qtxml qtxmlpatterns -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Windows: Qt5 does not run the application in release mode.
Hi all. I can not run GUI application built in Release mode. In the console displays the error: No platform plugin argument was specified and the default plugin windows is not available What could it be? PS: Qt5 (qtbase) built in Win7 x32 with Windows SDK 7.1: set QTDIR=c:\Qt\qt5-build\qtbase set PATH=%QTDIR%\bin;%PATH% c:\Qt\qt5-src\configure ^ -developer-build ^ -opensource ^ -nomake examples ^ -nomake demos nmake module-qtbase Best regards, Denis ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Alpha release: modules docs
Hi, here you have the list of essential add-on modules going to the Qt 5 alpha release: http://qt-project.org/wiki/Qt-5-Alpha I have tried to find information about these modules in the wiki and the Qt 5 snapshot docs, with mixed results: - Many modules don't seem to have docs available, at least where I was looking for. Any links are appreciated. You can add them directly to the wiki page or send them to me. - No module seems to have an own wiki page about the development of the module itself? Is this information available somewhere else (e.g. Gerrit) or just assumed? -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Demos, examples, docs etc for Alpha release
Hi, Please read http://qt-project.org/wiki/Spelling_Module_Names_in_Qt_Documentation. That should contain module names for most modules and gives hints on what to use (I am aware that these guidelines are not followed everywhere) So if you have the source and see incorrect use of module names you are free to update the documentation and add me as a reviewer. Casper From: development-bounces+casper.vandonderen=nokia@qt-project.org [development-bounces+casper.vandonderen=nokia@qt-project.org] on behalf of Gil Quim (Nokia-DXM/SiliconValley) Sent: Tuesday, March 13, 2012 10:25 PM To: Knoll Lars (Nokia-MP/Oslo); Storm-Olsen Marius (Nokia-MP/Austin) Cc: development@qt-project.org Subject: Re: [Development] Demos, examples, docs etc for Alpha release Ok, here we go: http://qt-project.org/wiki/Qt-Essentials-Modules http://qt-project.org/wiki/Qt-Add-ons-Modules There are many inconsistencies listed at the Notes section of each page (and pasted below for convenience). Please help ironing these details. Unless it's a topic for discussion you can edit the wiki directly or reply to me personally (no need to flood the list with tiny details). Thanks! Essentials: * What is the right way to spell these modules? Qt Widget or QtWidget? Qt WebKit or QtWebkit… ? * Is “Qt Quick 2” the right name or “Qt Declarative” or…? * Is it “Qt JS Backend”, “V8 JavaScript engine” or…? * “Qt WebKit” is already listed as Add-on. Is it Essential or are we talking about the WebKit1 vs WebKit 2 difference here? * Is “Qt Test” = “qttestlib”? * Is “Qt System Info” = “qtsystems”? * Is Qt 3D an Essential or Add-on? * It seems Qt D-Bus, Qt Sensors are Add-ons? * Are Qt Service Framework, Qt Publish and Subscribe still in Essentials? Not in Alpha release? Add-ons: * Should these be added? qlarl, qtconnectivity, qtdoc, qtdocgallery, qtimageformats, Phonon (or Qt Phonon?), qtpim, qtplatformsupport, qtqa, qtrepotools, qttranslations, qtwebkit-examples-and-demos * Is it “ActiveQt”, qtactiveqt or…? * Is it “Qt JSON DB”, “Qt JsonDB” or…? * Is “qttools” = “Qt Script Tools” or “Qt UI Tools” or…? * Is “Qt WebKit” in Add-ons or Essentials or…? Plus these that were listed in the old page (feel free deleting them if they are not relevant anymore, or adding the comments to the cell of the appropriate component): * Phonon will be maintained upstream by KDE. * Open: Add Qt Quick components modules * Open: whether Qt 5.0 will include the Qt Document Gallery add-on module. * Open: whether Qt 5.0 will include the Qt Local connectivity add-on * Open: whether Qt 5.0 will include the Qt Messaging add-on -- Quim From: Knoll Lars (Nokia-MP/Oslo) Sent: Tuesday, March 13, 2012 12:56 PM To: Gil Quim (Nokia-DXM/SiliconValley); Storm-Olsen Marius (Nokia-MP/Austin) Cc: development@qt-project.org Subject: Re: [Development] Demos, examples, docs etc for Alpha release Hi Quim, sounds good, please go ahead. Cheers, Lars On 3/13/12 8:05 PM, ext quim@nokia.com quim@nokia.com wrote: (Sorry for top-posting from this web client) Thank you for the list of modules. Can I do the following changes to the wiki? 1. Move the list of modules at http://qt-project.org/wiki/Qt_5.0#66036ddf6d03c9ce1fc742741417f128 to two new pages: - Qt Essential Modules - Qt Add-on Modules Reasoning: the are not roadmap anymore and they are not even 5 exclusive. They are simply Qt modules in trunk. This way it's easier to link to them from other pages (e.g. Alpha release notes) without having to drag the whole Qt 5 Roadmap content. 2. Mark somehow (e.g. different background color) the modules available in the alpha release. Reasoning: to have a clear idea of the status of those modules. 3. Try to improve the names and descriptions of each module. Reasoning: now it's confusing. For instance, is qtjsbackend = V8 JavaScript engine? 4. Link each module to whatever landing page there is available somewhere in the wiki, if available. Reasoning: now only the insiders can bridge that list with whatever info is somewhere else. -- Quim From: Storm-Olsen Marius (Nokia-MP/Austin) Sent: Monday, March 12, 2012 9:05 PM To: Gil Quim (Nokia-DXM/SiliconValley) Cc: development@qt-project.org; Hausmann Simon (Nokia-MP/Oslo) Subject: Re: [Development] Demos, examples, docs etc for Alpha release On 12/03/2012 18:10, ext Quim Gil wrote: Also, a basic question: where can someone find the actual list of Essential and Add-on modules that will be included in the Alpha? A Work-in-progress list is fine, now the only reference I have is a slide from last October-November. The current release script generates a package (890MB tar = 251MB tar.gz), correlated with the categorization of modules at http://qt-project.org/wiki/Qt_5.0 and corrected with some recent discussions between Henry, Lars and Thiago, this list of modules: Qt Essentials: qt3d
Re: [Development] QDoc can't ignore Q_PROPERTY
On 03/13/2012 07:04 AM, Vandonderen Casper (Nokia-MP/Oslo) wrote: The solution given above would mean that it will become optional to document NOTIFY signals. But is that not completely different from the original problem? Yes. The original question was how to make qdoc not see Q_PROPERTY (presumably because the OP didn't like what that did to the documentation). As far as I know, the answer to that is actually fairly simple: #ifndef Q_QDOC Q_PROPERTY(...) #endif To have the properties show up in the docs but to leave the documentation for the getters and setters in too, you'd need something like this: #ifdef Q_QDOC Q_PROPERTY(int myprop) #else Q_PROPERTY(int myprop READ myprop WRITE setMyprop) #endif However, I don't understand why you would want/need to do this. Anyway, my first reply was a complaint about how you are forced to document NOTIFY signals and I guess at that point the thread was hijacked onto a separate topic. -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On 03/12/2012 11:56 PM, ext Thiago Macieira wrote:
qmake does not add a dependency on the .a file, so the other target doesn't
get
relinked.
Qtopia had a large number of .a files and this hit us hard so we devised
a workaround.
# A function to create explicit dependencies in a Makefile
defineTest(create_raw_dependency) {
var=$$1
dep=$$2
eval($${var}.depends*=\$$dep)
export($${var}.depends)
QMAKE_EXTRA_TARGETS*=$$var
export(QMAKE_EXTRA_TARGETS)
}
# relink our binary when foo.a changes
create_raw_dependency($$TARGET, /path/to/foo.a)
This literally gave us a rule in the Makefile like this:
mybin: /path/to/foo.a
Luckily, make doesn't care if you have multiple rules for a product,
as long as only one of them executes commands.
I doubt this works on non-Makefile projects though. Possibly not even on
non-GNU make. Probably easier to just have qmake generate the dependency
itself :)
--
Lincoln Ramsay - Senior Software Engineer
Qt Development Frameworks, Nokia - http://qt.nokia.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
