Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13/05/2014 16:47, Thiago Macieira wrote: Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu: That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. Then the problem is simply of running the network tests. The CI could be smart and decide that it doesn't need to run tests/auto/network if src/network wasn't modified. I don't think that this is a good idea. Changes in QtCore which break something in network wouldn't cause a CI error and test failures would only surface as soon as a change to network is made. Isn't that one of the situations we want to avoid? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On Wednesday 14 of May 2014 08:01:33 Oliver Wolff wrote: On 13/05/2014 16:47, Thiago Macieira wrote: Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu: That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. Then the problem is simply of running the network tests. The CI could be smart and decide that it doesn't need to run tests/auto/network if src/network wasn't modified. I don't think that this is a good idea. Changes in QtCore which break something in network wouldn't cause a CI error and test failures would only surface as soon as a change to network is made. Isn't that one of the situations we want to avoid? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, As far I know the plan was to have a full Qt5 build and test cycle per day. So no, brokenness would be detected much earlier. Btw. the same argumentation could be used for every other module. In my opinion it is fine to break intermodule dependencies from time to time, assuming that we can detect and recover quickly. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Accessibility Mailing List and News
Hello, I have some good news which I won't repeat here, please read up on the state of Qt accessibility in Qt 5.3 and onward: http://blog.qt.digia.com/blog/2014/05/14/accessibility-in-qt-5-3/ I'd like to invite everyone interested to join our new Qt accessibility mailing list: http://lists.qt-project.org/mailman/listinfo/accessibility -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Tue, May 13, 2014 at 03:31:52PM -0500, Keith Gardner wrote: On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: my point is that this class is becoming unreasonably complex for a rather trivial thing, which only a fraction of the applications will use. Your argument is backwards, the problem is complex and the approach is simple. You have spent many emails arguing that there are many different methods of version numbers and that we cannot satisfy all of them. that's besides the point. by trivial i mean that the concept of version numbers as such is pretty trivial, and individual implementations are generally quite simple and short. but exactly because the concept is so fuzzy, there is simply no reasonable way to make a solution that comes even close to being universal. this is a huge red flag. just don't go there. I agree that only a fraction of the applications will use this API, but that is still greater than zero. In my applications, I heavily rely on version number comparisons. it would seem that the code is already where it should be. imo, the cases which are fully under the user's control (internal version checking) should be handled solely numerically (even without considering any pre-releases), which basically means a minimalistic semver(-like) implementation which can be fully inline (or even just a collection of macros). in this segment, it is entirely unreasonable to try to support existing users with bizarre versioning schemes, because they most likely already have their own solutions. and new users can be told to use the straight-forward system. With that perspective, we can accomplish that now by just dropping the suffix, which was what my initial proposal for QVersion was. yes. you actually had me convinced that this would be a useful addition. The request to include suffix information came from the reviewers and this mailing list. scope creep. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Tuesday 13 May 2014 21:58:29 André Pönitz wrote: On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote: Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? I am. At the very least, this is still missing an explanation what actual problems this is going to solve, and a few _plausible_ scenarios where this code will be reused. A couple of users actually asking for such a framework would already help to understand the need. Hey Andre, let me (re-)raise two valid use cases for this new repository: GammaRay and KDevelop (as previously mentioned by Kai). But I guess people out there working on any other IDE might want to use it eventually, if they add support for QML. Momentics comes into mind there. Once the need to have it is established, the implementation can be discussed. I would like to see such a debugsupport module. Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
1. Numerical groupings should be compared integers instead of characters in order to properly allow for alpha2 alpha11. 2. Delimiters should only be used to denote groups of content but be skipped during the compare. alpha == -alpha == ~alpha == .alpha 1. Can be restricted to the first character if this is too broad. Given that we're numbering things, your last point would probably be better- numbered 3 instead of 1 again, right? It was actually suppose to be a sub item to 2 but it looks like the tabbing was lost. Note also that version number schemes for particular software are not constant over time. https://blog.qt.digia.com/blog/2009/09/03/qt-4th-edition-feature-pack-7/ Are Windows versions in scope? Are you referencing kernel versions or how the OS embeds version numbers into binaries? If it is the latter, support is there since they are strictly four numerical segments. I changed grantlee versions to drop a 'v' at some point. http://www.grantlee.org/downloads/ I'm sure there are other examples in the past and in the future. I didn't read closely enough to see if that affects your proposal at all. At this moment, the 'v' is optional and if present, will be ignored. My bikeshed color is that a version comparator should only do 'component-wise numeric comparison' and shouldn't also try to handle prefixes and suffixes etc. I'm just adding that because I don't really support any side of this discussion beyond bikeshedding. I like the color of your bikeshed. I personally think prefixes are the most ambiguous out of all the potential parts to a version number and I would prefer to not include them. Suffixes were initially not on my radar but others responses have convinced me that the desire to have them is there. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Wednesday, May 14, 2014 07:41:20 you wrote: At this moment, the 'v' is optional and if present, will be ignored. Try to ignore the specificness of that. The only point I was making is this: Version number schemes change over time in a way you can't predict. Thanks, -- Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. What are your thoughts about comparing a QVersion to a QSpecializedVersion or a QSpecialized1Version to a QSpecialized2Version since both would have different isNonNumericalSectionLessThan functions? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Keith Gardner schreef op 14-5-2014 15:45: Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. What are your thoughts about comparing a QVersion to a QSpecializedVersion or a QSpecialized1Version to a QSpecialized2Version since both would have different isNonNumericalSectionLessThan functions? Good one, I did not consider that. I was simply proposing my ideal color for the bike shed ;-). I think they should not compare at all. Not sure what the best way to ensure that would be though. Otherwise, you'd end up with the situaton that QVersion QSpecilializedVersion but not QSpecializedVersion QVersion due to which instances compare function was used. Or, if it is not easy to prevent that from happening without cluttering the API, you simply clearly document that the result of comparing two different QVersion specializations is undefined. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calling a function at frame-rate before rendering
It depends on what your update state is... If you want to tick rendering state (OpenGL and Scene Graph stuff) then you can call QQuickWindow::update() and make a direct connection to QQuickWindow::beforeRendering() to advance the state on the render thread just before the scene is drawn. If you have a QSGNode structure you want to update, call QQuickItem::update() and QQuickItem::updatePaintNode() will be called to synchronise your item state into the scene graph before the scene graph is rendered. If you have GUI thread state, application logic and other stuff you can call QQuickItem::polish() and reimplemnt QQuickItem::updatePolish() which is called just before the QML tree is synced into the render thread. If you have continuous animations use QAbstractAnimation and use the time you get in updateCurrentTime(). cheers, Gunnar On 14 May 2014, at 16:53, raskolni...@es.gnu.org wrote: Hi guys! So... I am working on a project where the data model is written in a functional style and uses a epochal approach to move it's state forward... the details would probably bore you but the important thing is that it requires a tick() function to be called to make an updated world state visible. This seems to be tricky in Qt and I haven't found the best approach yet... and I am starting to wonder if is even possible at all. Because following some discussions in this list it seems that animations are ticked at frame-rate, I tried deriving from QAbstractAnimation and tick updateCurrentTime(), however, that made the state lag one frame behind rendering, something quite visible when dragging an object (the Qt draggable would be updated automatically, but our data-model based stuff would lag one frame). Then I tried making an eventFilter() in which I do something like this: if (event != MyTickEvent) postEvent(MyTickEvent) else tick() I expected this to remove the lagging, but while it improves the situation, there are cases in which I can still see some lagging. Furthermore, this approach involves too much ticking, while ticking one per frame should be enough. So, am I missing something? Is there a general way to tick my state update before rendering? Thanks! JP ___ 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] Adding support for version number comparisons
Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu: Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. I don't want virtuals in this class. I could accept a comparator function (e.g., a lambda), but I still think that's overkill. QVersion could simply report how many tokens it could parse and then leave it up to the upper layer to deal with the rest of the string. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On 2014-05-14, at 04:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu: Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. I don't want virtuals in this class. I could accept a comparator function (e.g., a lambda), but I still think that's overkill. QVersion could simply report how many tokens it could parse and then leave it up to the upper layer to deal with the rest of the string. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development I think the fact that this email thread is already 40 messages long clearly illustrates the need for custom comparators. Let's use a lambda as an optional argument to compare(). We could even export a few default comparator functions from QtCore if deemed necessary. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Em qua 14 maio 2014, às 14:12:40, Stephen Kelly escreveu: Note also that version number schemes for particular software are not constant over time. https://blog.qt.digia.com/blog/2009/09/03/qt-4th-edition-feature-pack-7/ That was a joke! Tongue in cheek with how Symbian/S60 named its versions at one point in time. Are Windows versions in scope? Also, we support version numbers, not marketing names. Symbian 5th Edition, Feature Pack 1 was 5.1. And that got retroactively renamed to Symbian^1. And then Symbian^3 became Symbian Anna. The same goes for Windows: the marketing name Windows 7 does not represent the version number. QSysInfo::osVersion() will return Windows 8 but QSysInfo::osKernelRelease() will return 6.2.9200. My bikeshed color is that a version comparator should only do 'component-wise numeric comparison' and shouldn't also try to handle prefixes and suffixes etc. I'm just adding that because I don't really support any side of this discussion beyond bikeshedding. I can support that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Development Digest, Vol 32, Issue 29
Em ter 13 maio 2014, ?s 12:28:11, achart...@fastmail.fm escreveu: Hi all, I would like to enable the -Weverything and -Werror Clang compiler flags for my application code to treat all warnings as errors. Please note that Qt compiles mostly cleanly with -Wall -Wextra -Werror. We do not support -Weverything, since it produces warnings that are, well, stupid. Unfortunately, Qt itself generates a large number of warnings. I would like to suppress the warnings generated for Qt code but have Clang report all the warnings (errors) in my application code. I have searched a lot on this subject and have not found a solution that really works. The proper way to do this is to use the -isystem flag and specify the Qt include directories so they may be treated as system headers, however qmake seems to always pass the Qt include directories with the -I argument no matter what I do (I even tried INCLUDEPATH -= Qt_include_dirs to no avail). Make sure you're using 5.3. If so, qmake will automatically use -isystem for all system header paths. Note: *system* header paths. You need to install Qt in one of the system header paths for that to take effect. That is, /usr/include or /usr/local/include or one of the rest listed in: $ grep DEFAULT_INCDIRS mkspecs/qconfig.pri QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.8 /usr/include/c++/4.8/x86_64- suse-linux /usr/include/c++/4.8/backward /usr/lib64/gcc/x86_64-suse- linux/4.8/include /usr/local/include /usr/lib64/gcc/x86_64-suse- linux/4.8/include-fixed /usr/x86_64-suse-linux/include /usr/include The only approach that has worked so far is to use the -Wno flag to disable certain warnings. This is far from desirable, as then the warning checking in my application code is tied to the quality of the Qt codebase. We only need -Wno-error=deprecated-register and that's because of a macro from glibc (Linux). No other flags are necessary with -Wall -Wextra. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Thanks Thiago, I'm glad to hear -isystem is supported. I'll give this a try with the Qt 5.3 release. Regarding QMAKE_DEFAULT_INCDIRS: is it possible to append additional paths to this variable from within project files? Thanks again! Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Wed, May 14, 2014 at 11:37:45AM +0200, Milian Wolff wrote: On Tuesday 13 May 2014 21:58:29 André Pönitz wrote: On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote: Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? I am. At the very least, this is still missing an explanation what actual problems this is going to solve, and a few _plausible_ scenarios where this code will be reused. A couple of users actually asking for such a framework would already help to understand the need. Hey Andre, let me (re-)raise two valid use cases for this new repository: GammaRay and KDevelop (as previously mentioned by Kai). But I guess people out there working on any other IDE might want to use it eventually, if they add support for QML. Momentics comes into mind there. Once the need to have it is established, the implementation can be discussed. I would like to see such a debugsupport module. That's a clear vote. I'd still like to try to set expectations right: I understand the proposition _sounds_ good, and the code actually _looks_ good. But it doesn't _do_ anything sensible, nor does it help when trying to do anything sensible. What's currently proposed to be moved into Qt Base is several thousand lines of pure infrastructure for things like packet and connection handling. _There is no actual debugging or profiling service included_. The communication protocol used is completely ad-hoc, and not used by anything else in the world. This infrastructure supports _only_ services that run _inside_ the application it examines, i.e. a profiler based on this framework shares address space, including heap, network connection etc. with the object it claims to profile, _while using resources of this object for its own operations_. Unless special measure are taken, the service will remain and be accessible in the deployed application. There is no build-in security. This infastructure cannot be used to interface classical profiling/debugging tools like Valgrind, GDB, etc. It does _not_ simplify IDE integration: First, it can as-is only be used with Qt based clients/IDEs. This won't be much of a problem for KDevelop or GammaRay, but e.g. Momentics would have to wrap or essentially re-do the client side in Java. Second, Qt based frontends do not get a free ride either. Exemplified by Qt Creator: The amount of code needed to use that framework in the debugger plugin to make QML debugging work is in the same order as the amount of code we have for the direct GDB and LLDB interfaces. And to put it into proportion, plugin/debugger/qml/* is roughly 1.5 the size plugins/designer, the Qt Designer integration. I maintain that this framework is completely over-engineered. It does not work like typical tools in the field, nor does it help to write such tools. I believe there is not a single use case where it gives any benefit over a direct implementation of whatever kind of communication/data extraction is needed. This code does not belong into Qt Base, nor should it be advertised as a re-usable framework. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML DropArea documentation unhelpful
On Thursday 15 May 2014 04:44:34 Ben Lau wrote: well , I also think that the document about Drag and Drop is not clear enough.. Reading from example code is more easy to understand. Anyway , the solution to your problem: You should call drag.accept() within the onEntered slot. Then it will enable the onDropped slot to be executed. http://qt-project.org/doc/qt-5/qml-qtquick-dragevent.html#accept-method Heh, that doesn't work either. And that's exactly what my second thought was as well (accepting the event in 'onEntered'). Sorry, no cigar. Greets -- Kevin Funk ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
Em qua 14 maio 2014, às 13:36:30, Thiago Macieira escreveu: QSysInfo::osVersion() will return Windows 8 but QSysInfo::osKernelRelease() will return 6.2.9200. BTW, on Linux: $ qtdiag | head -2 Qt 5.3.1 (x86_64-little_endian-lp64 shared (dynamic) debug build; by GCC 4.8.1 20130909 [gcc-4_8-branch revision 202388]) on xcb OS: Linux (openSUSE 13.1 (Bottle) (x86_64)) [kernel version 3.11.10-7-desktop] from: OS: QSysInfo::prettyOsName() [kernel version QSysInfo::osKernelVersion() ]\n; The osVersion() on my machine is openSUSE_13.1. That's not orderable, because other entries might be Fedora_20 and unknown. Windows: Qt 5.3.1 (x86_64-little_endian-llp64 shared (dynamic) release build; by MSVC 2013) on windows OS: Windows 8 [kernel version 6.2.9200] Mac: Qt 5.3.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 5.1 (clang-503.0.40) (Apple)) on cocoa OS: OS X Mavericks (10.9) [kernel version 13.1.0] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.
Hi All, My mac app just got rejected by the Mac App Store for the following reasons: The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application: '/usr/lib/libSystem.B.dylib' : bootstrap_look_up2 : bootstrap_register2 '/usr/lib/libicucore.A.dylib' : ubrk_getRuleStatus : ubrk_setUText : ucnv_getCanonicalName : ucnv_reset '/usr/lib/libiodbc.2.dylib' : SQLAllocHandle : SQLBindParameter : SQLCloseCursor : SQLColAttributeW : SQLColumnsW : SQLDescribeColW : SQLDisconnect : SQLDriverConnectW : SQLEndTran : SQLExecDirectW : SQLExecute : SQLFetch : SQLFetchScroll : SQLFreeHandle : SQLGetData : SQLGetDiagRecW : SQLGetFunctions : SQLGetInfoW : SQLGetStmtAttrW : SQLGetTypeInfoW : SQLMoreResults : SQLNumResultCols : SQLPrepareW : SQLPrimaryKeysW : SQLRowCount : SQLSetConnectAttrW : SQLSetEnvAttr : SQLSetStmtAttrW : SQLSpecialColumnsW : SQLTablesW -- First of all, my app doesn't even use SQL, why are those APIs being called? As to the first two issues, from what I read online, it is because of QtWebkit, which I have to use in my app. Is there any hope we could get these fixed? Thank you! Ping ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.
On 2014-05-14, at 07:39 PM, P Bai ap...@yahoo.com wrote: Hi All, My mac app just got rejected by the Mac App Store for the following reasons: The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application: '/usr/lib/libSystem.B.dylib' : bootstrap_look_up2 : bootstrap_register2 '/usr/lib/libicucore.A.dylib' : ubrk_getRuleStatus : ubrk_setUText : ucnv_getCanonicalName : ucnv_reset '/usr/lib/libiodbc.2.dylib' : SQLAllocHandle : SQLBindParameter : SQLCloseCursor : SQLColAttributeW : SQLColumnsW : SQLDescribeColW : SQLDisconnect : SQLDriverConnectW : SQLEndTran : SQLExecDirectW : SQLExecute : SQLFetch : SQLFetchScroll : SQLFreeHandle : SQLGetData : SQLGetDiagRecW : SQLGetFunctions : SQLGetInfoW : SQLGetStmtAttrW : SQLGetTypeInfoW : SQLMoreResults : SQLNumResultCols : SQLPrepareW : SQLPrimaryKeysW : SQLRowCount : SQLSetConnectAttrW : SQLSetEnvAttr : SQLSetStmtAttrW : SQLSpecialColumnsW : SQLTablesW -- First of all, my app doesn't even use SQL, why are those APIs being called? As to the first two issues, from what I read online, it is because of QtWebkit, which I have to use in my app. Is there any hope we could get these fixed? Thank you! Ping ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development The ODBC APIs are probably from the Qt ODBC SQL plugin. Simply don't deploy it with your app and it should resolve that issue. Not sure about the rest. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.
Em qua 14 maio 2014, às 16:39:15, P Bai escreveu: As to the first two issues, from what I read online, it is because of QtWebkit, which I have to use in my app. Is there any hope we could get these fixed? Correct, all of them come from QtWebKit. Anyway, there's no plan on further updating QtWebKit from upstream because upstream WebKit is no longer cross-platform. I have no clue about the bootstrap symbols, but all of the ICU symbols are documented to be stable in icu-project.org and have been for some time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.
BTW, when will QtWebkit be replaced? On Thu, May 15, 2014 at 8:48 AM, Thiago Macieira thiago.macie...@intel.comwrote: Em qua 14 maio 2014, às 16:39:15, P Bai escreveu: As to the first two issues, from what I read online, it is because of QtWebkit, which I have to use in my app. Is there any hope we could get these fixed? Correct, all of them come from QtWebKit. Anyway, there's no plan on further updating QtWebKit from upstream because upstream WebKit is no longer cross-platform. I have no clue about the bootstrap symbols, but all of the ICU symbols are documented to be stable in icu-project.org and have been for some time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt WebKit replacement (Was: Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.)
On 15 May 2014 09:18, Yang Fan missd...@gmail.com wrote: BTW, when will QtWebkit be replaced? The plan is to make Qt WebEngine available to Qt Enterprise Embedded users from Qt 5.3, and other users from Qt 5.4: http://blog.qt.digia.com/blog/2014/05/13/news-from-the-qt-webengine-team/ Regards, Sze-Howe On Thu, May 15, 2014 at 8:48 AM, Thiago Macieira thiago.macie...@intel.com wrote: Em qua 14 maio 2014, às 16:39:15, P Bai escreveu: As to the first two issues, from what I read online, it is because of QtWebkit, which I have to use in my app. Is there any hope we could get these fixed? Correct, all of them come from QtWebKit. Anyway, there's no plan on further updating QtWebKit from upstream because upstream WebKit is no longer cross-platform. I have no clue about the bootstrap symbols, but all of the ICU symbols are documented to be stable in icu-project.org and have been for some time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Mac app built with Qt5.3.0 RC got rejected by Mac App Store because of non-public API calls.
Em qui 15 maio 2014, às 09:18:31, Yang Fan escreveu: BTW, when will QtWebkit be replaced? From yesterday: http://blog.qt.digia.com/blog/2014/05/13/news-from-the-qt-webengine-team/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] `/opt/qt5/bin/qdoc: not found` with `-prefix /opt/qt5` config
Em sex 09 maio 2014, às 16:53:20, Yuchen Deng escreveu: If I have to do `make install` first, then I can't use `make install INSTALL_ROOT=$PWD/qt` anymore. It's means INSTALL_ROOT does not support for this case? make install_docs INSTALL_ROOT=$PWD/qt install.log 21 2014-05-09 10:21 GMT+08:00 Thiago Macieira thiago.macie...@intel.com: make install; make docs; make install_docs By the way, if you're building packages, you should use the split sources and then this just becomes a dependency cycle. You need to have Qt 5 installed in order to build Qt 5 docs. That is, qdoc must exist at the time you're building qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] `/opt/qt5/bin/qdoc: not found` with `-prefix /opt/qt5` config
Em qua 14 maio 2014, às 20:17:34, Thiago Macieira escreveu: Em sex 09 maio 2014, às 16:53:20, Yuchen Deng escreveu: If I have to do `make install` first, then I can't use `make install INSTALL_ROOT=$PWD/qt` anymore. It's means INSTALL_ROOT does not support for this case? make install_docs INSTALL_ROOT=$PWD/qt install.log 21 2014-05-09 10:21 GMT+08:00 Thiago Macieira thiago.macie...@intel.com: make install; make docs; make install_docs By the way, if you're building packages, you should use the split sources and then this just becomes a dependency cycle. You need to have Qt 5 installed in order to build Qt 5 docs. That is, qdoc must exist at the time you're building qtbase. Hmm... that's probably easily fixable by setting LD_LIBRARY_PATH to the not- yet-installed qdoc when building qtbase docs which it already does. For all of the other modules, just install the qtbase package and, therefore, $prefix/bin/qdoc will exist. The above is valid for html_docs. In order to build the qch_docs, qttools must have already been built. That creates a build cycle dependency. I guess Linux distributions that will rebuild documentation will simply skip the .qch files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
