Re: [Development] Important OSX 10.9.5 10.10 codesign changes
On Mon, Sep 22, 2014 at 1:03 PM, Sorvig Morten morten.sor...@digia.com wrote: On 19 Sep 2014, at 11:28, Sorvig Morten morten.sor...@digia.com wrote: This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. I’m using QTBUG-32896 as a metabug to track the effort. Here’s the current patch set (5.3): qmake - framework bundle hierarchy (QTBUG-32895): https://codereview.qt-project.org/95454 qmake - “_debug in CFBundleExecutable (QTBUG-32894): https://codereview.qt-project.org/95455 qmake - add CFBundleVersion: https://codereview.qt-project.org/95456 macdeployqt - “Current” version symlinks: https://codereview.qt-project.org/#/c/95442/ Are these patches sufficient? If not, what’s missing? Morten I see that they were integrated to 5.3. But when I get the 5.3 branch from git, the last commits seen in log are dated August and these patches have been merged on October 1. git clone git://gitorious.org/qt/qt5.git qt-5 cd gt5 git checkout 5.3 Shall I take some another branch or switch to something? Thanks, Robert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] qt.io download-open-source page updated
Hi, Thanks for your feedback related to qt.io opensource downloads page: http://www.qt.io/download-open-source/ The page is now updated based on your comments - the major changes are: 1. Automatic download is now completely removed * Recommended download is still highlighted and you can start download with button click 2. All downloads from http://qt-project.org/downloads page have been added to new page * No need to jump between sites anymore In addition some other smaller changes were implemented. We have some visual Improvements in backlog, but those want change functionality or content of the page. Does the page fulfil purpose your needs now? If you have any comments, please use Help is improve button on right hand side of the page. Br, -- Janne Anttila ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
This was discussed to exhaustion in Qt 5's development process. The conclusion is to remain at status quo since there is no good, technical solution. I’d think that the solution could be to use a dedicated class for file names, perhaps with a base class for uninterpreted platform strings. Ugh, that begins to sound like Java. Let's have a wrapper for a wrapper... please don't go that way. How do you pass it on the command-line? Mind you, QProcess takes a QStringList for arguments. It look as if we’d need something like QPlatformString that’s a “thin” wrapper around a QByteArray on unices, and around QString on Windows. No, thanks! :) I fully agree with no, thanks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt.io download-open-source page updated
On Tue, Oct 7, 2014 at 9:13 AM, Anttila Janne janne.antt...@theqtcompany.com wrote: Hi, Thanks for your feedback related to qt.io opensource downloads page: http://www.qt.io/download-open-source/ The page is now updated based on your comments - the major changes are: 1. Automatic download is now completely removed * Recommended download is still highlighted and you can start download with button click 2. All downloads from http://qt-project.org/downloads page have been added to new page * No need to jump between sites anymore In addition some other smaller changes were implemented. We have some visual Improvements in backlog, but those want change functionality or content of the page. Does the page fulfil purpose your needs now? If you have any comments, please use Help is improve button on right hand side of the page. Br, -- Janne Anttila Some more feedback. 1. The download to the community version of Qt from http://www.qt.io/download/ links to http://www.qt.io/?p=323 which redirects to http://www.qt.io/download-open-source/ .. A bit weird. 2. Again on http://www.qt.io/download/ the Download button for community is grey. So it lookslike the button is disabled which it isn't. Just make it green like the other download buttons. 3. Different tick marks are used. http://www.qt.io/support/ and http://www.qt.io/download/ Cheers, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
Hi Kuba, Your criticisms are completely valid, and the conclusions you draw from them are, too. The problems Thiago lists make this a daunting task, but mostly not because of complexity, but of sheer volume of code that needs to be modified. I believe it's worth it, but most of us here lack the time for such a change, so you're more than welcome to volunteer. I can at least help with review, and once the class is in and QDir*/QFile* are adapted to use it, I'd start using it in QtWidgets right away. Many of the issues Thiago lists can be dodged. E.g. a file path class could lack streaming operators and instead force early users to use toEncoded()/toDecoded() explicitly. On Monday 06 October 2014 19:30:29 Kuba Ober wrote: I’d think that the solution could be to use a dedicated class for file names, Yes, with s/file/path/. perhaps with a base class for uninterpreted platform strings. Value classes should not have base classes. And that class for uninterpreted platform strings may be an abstraction vehicle to streamline implementation of path name class, but not public API, unless you provide one or two more users of such API. Thanks, Marc -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Marc Mutz marc.m...@kdab.com | Senior 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
[Development] FW: Change in qt/qt5[dev]: Updated submodules.
Hi all, There seems to be real issue with qt5.git integration in 'dev' branch. Someone, please check and fix this. Br, Jani -Original Message- From: Qt Continuous Integration System (Code Review) [mailto:gerrit-nore...@qt-project.org] Sent: 7. lokakuuta 2014 11:08 To: Qt Submodule Update Bot Cc: Qt Sanity Bot; Heikkinen Jani Subject: Change in qt/qt5[dev]: Updated submodules. Qt Continuous Integration System has posted comments on this change. Change subject: Updated submodules. .. qtmultimedia failed to compile :( /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -pipe -fvisibility=hidden -fpascal-strings -fmessage-length=0 -Wno-trigraphs -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion -fexceptions -fasm-blocks -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-implicit-atomic-properties -Wformat -Wno-missing-braces -Wno-unused-function -Wno-unused-label -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-sign-compare -Wpointer-sign -Wno-newline-eof -Wdeprecated-declarations -Winvalid-offsetof -Wno-conversion -fvisibility-inlines-hidden -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-arc-abi -fobjc-nonfragile-abi -fobjc-legacy-dispatch -Wno-deprecated-implementations -Wprotocol -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -arch armv7 -O2 -isysroot /Applications/Xcode .app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.0.sdk -std=c++11 -stdlib=libc++ -miphoneos-version-min=5.0 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -DDARWIN_NO_CARBON -DQT_NO_PRINTER -DQT_NO_PRINTDIALOG -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQMEDIA_AVF_MEDIAPLAYER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NO_KEYWORDS -DQT_STATICPLUGIN -DQT_PLUGIN -DQT_MULTIMEDIAWIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/work/build/qtbase/mkspecs/macx-ios-clang -I. -I/work/build/qtbase/mkspecs/macx-ios-clang/ios -I../../../../include/QtMultimedia/5.5.0 -I../../../../include/QtMultimedia/5.5.0/QtMultimedia -I../../../../include/QtMultimediaWidgets/5.5.0 -I../../../../include/QtMultimediaWidgets/5.5.0/QtMultimediaWidgets -I../../../../include -I../../../../include/QtMultimediaWidgets -I../../../../include/QtMultimedia -I/work/build/qtbase/include -I/work /build/qtbase/include/QtWidgets -I/work/build/qtbase/include/QtGui -I/work/build/qtbase/include/QtNetwork -I/work/build/qtbase/include/QtCore -I.moc/iphoneos avfmediaplayersession.mm -o .obj/iphoneos/avfmediaplayersession.o avfmediaplayersession.mm:325:24: error: cannot initialize a variable of type 'AVPlayerStatus' with an rvalue of type 'NSInteger' (aka 'int') make[6]: *** [.obj/iphoneos/avfmediaplayersession.o] Error 1 make[5]: *** [iphoneos-all] Error 2 make[4]: *** [sub-mediaplayer-make_first] Error 2 make[3]: *** [sub-avfoundation-make_first] Error 2 make[2]: *** [sub-plugins-make_first] Error 2 make[1]: *** [sub-src-make_first] Error 2 make: *** [module-qtmultimedia-make_first] Error 2 Build log: http://testresults.qt-project.org/ci/Qt5_dev_Integration/build_00512/macx-ios-clang_OSX_10.9/log.txt.gz Tested changes (refs/builds/dev_1412665031): http://codereview.qt-project.org/94811 [PS29] - Updated submodules. -- To view, visit https://codereview.qt-project.org/94811 To unsubscribe, visit https://codereview.qt-project.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I869fce8a6bd6db20b58facdd2a476dacdf3b7d69 Gerrit-PatchSet: 29 Gerrit-Project: qt/qt5 Gerrit-Branch: dev Gerrit-Owner: Qt Submodule Update Bot qt_submodule_update_...@ovi.com Gerrit-Reviewer: Jani Heikkinen jani.heikki...@digia.com Gerrit-Reviewer: Qt Sanity Bot qt_sanity...@qt-project.org Gerrit-Reviewer: Qt Submodule Update Bot qt_submodule_update_...@ovi.com Gerrit-HasComments: No ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
On Oct 7, 2014, at 8:30 AM, Julien Blanc julien.bl...@nmc-company.com wrote: On 07/10/2014 12:11, Tomasz Siekierda wrote: For file paths, I feel QString is really enough. Changing it to something else because of a few corner cases seems like an overkill to me. We already have a lot of classes that are connected with paths and the file system (QFile, QFileInfo, QDir, QDirIterator, and more), that is enough. In my view, at least. Imho using QString for file path (or, more generally, using any string objects with a static api) is somewhat a very widespread bad idea. The std::experimental::filesystem api, for example, looks really better. Basically, on Unix, the idea that a file path has any particular encoding doesn’t hold *by the very design*. On Unix, a file path is a string of nonzero bytes with a special meaning for ‘/‘ and ‘.’ and that’s it. It’s a safe assumption that other bytes under 128 are ASCII, perhaps, but even that’s not an assumption one has to make. Armin describes it rather succinctly: it's a byte mess that for display purposes is decoded with an encoding hint. Given that Qt’s lifecycle is very different from that of standard C++, whatever solution Qt provides needs to stand on its own. Cheers, Kuba ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
El Tuesday 07 October 2014, Tomasz Siekierda escribió: For file paths, I feel QString is really enough. Changing it to something else because of a few corner cases seems like an overkill to me. Just for the sake of documenting the issue and pointing to this thread if future questions arise: Is there some solution for those corner cases? Say one writes a file manager with Qt, and has to support that one file name with a wrong encoding could be renamed to the right one. Should that person skip the Qt classes? BTW, subject says non-Windows systems, but IIRC Mac OS X doesn't allow two files with equivalent names (e.g. composed vs the precomposed characters that are equivalent). Does it apply as well? -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
On Tuesday 07 October 2014 10:38:47 Kuba Ober wrote: Just to be very clear: it is currently impossible to make a truly portable file management utility with Qt’s core APIs. Why? Because it will simply ignore all file names that it can’t decode when iterating the directory, and it won’t be able to take commandline arguments to open such files either. Furthermore, this is something that very basic C code using nothing but POSIX APIs can trivially deal with. Or that Python 2 trivially deals with. I consider it a serious enough problem. That's where we disagree: those file names are not common at all. -- 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] QtDeclarative CI
Hi, I cannot get my changes [1] through CI for qtdeclarative/5.4. Originally it failed with qquickwindow tests, but now it does not compile on Windows CE platform. Can anyone take a look at the situation? 1. https://codereview.qt-project.org/96314 Best, Oleg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDeclarative CI
On 07-Oct-14 18:21, Oleg Shparber wrote: I cannot get my changes [1] through CI for qtdeclarative/5.4. Originally it failed with qquickwindow tests, but now it does not compile on Windows CE platform. Can anyone take a look at the situation? 1. https://codereview.qt-project.org/96314 This was caused by cd1dff75561aa132f8dccd0a3c79b80962f3d161 in qtbase. Here's a fix: https://codereview.qt-project.org/96544 BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5.4 beta MinGW snapshot ?
Hi everyone, any chance to get a hold on a MinGW snapshot of the 5.4.0 beta ? I personally hate to use Micro$oft stuff and I much prefer the good old shell :) The snapshot would allow me to decide if I need to open a bug about buttons background palette on Windows. The code works fine on Linux. Thanks and keep up the awesome job ! Massimo___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
The problem is serious enough, indeed, that Python 3 has resorted to a hack where they use a private Unicode range to encode the bytes between 128 and 255 in strings that fail normal decoding. I think that putting this hack into QString is unthinkable, and the concept of a platform string has to be taken with heads up and in a manner that will make it useful, usable and unobtrusive. I don't claim that it's a trivial task, but then I'm not asking anyone else but myself to deal with it :) Cheers, Kuba I think that hack should be given serious consideration. Sure it is a hack, but it might still be the best solution. Tony ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems
On Tuesday 07 October 2014 23:19:23 Tony Van Eerd wrote: The problem is serious enough, indeed, that Python 3 has resorted to a hack where they use a private Unicode range to encode the bytes between 128 and 255 in strings that fail normal decoding. I think that putting this hack into QString is unthinkable, and the concept of a platform string has to be taken with heads up and in a manner that will make it useful, usable and unobtrusive. I don't claim that it's a trivial task, but then I'm not asking anyone else but myself to deal with it :) Cheers, Kuba I think that hack should be given serious consideration. Sure it is a hack, but it might still be the best solution. We are using the same hack in KDE4Libs, but it relies on QFile::setDecodingFunction. Unfortunately, this function is no longer available in Qt5, so in a few years, we will see the same long discussion as in https://bugs.kde.org/show_bug.cgi?id=165044 -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
