Re: [Development] Nokia/Digia copyright in PDF produced by QPrinter
On 10/7/13 12:35 PM, David Boddie dav...@met.no wrote: On Sun Oct 6 20:51:40 CEST 2013, Lars Knoll wrote: The producer field in PDF is generally used for marking what has been used to produce the PDF. In Qt 5 this reads: xprintf(\n/Producer ); printString(QString::fromLatin1(Qt QT_VERSION_STR (C) 2012 Digia Plc and/or its subsidiary(-ies))); which gives inside the PDF: /Producer (Qt 5.1.1 \(C\) 2012 Digia Plc and/or its subsidiary\(-ies\)) I think this is fully correct, and doesn't assert any copyright over the generated PDF. It states that the PDF got produced by the PDF generator of Qt 5.1.1, which is (C) Digia. While this interpretation may be valid, it is unusual to put the copyright of the creation tool in the Producer string. I can find documents with the following Producer strings on my disk: (AFPL Ghostscript 8.54) (Acrobat 5.0 Image Conversion Plug-in for Macintosh) (Adobe PDF library 4.800) (Aladdin Ghostscript 6.01) (GNU Ghostscript 7.07) (GPL Ghostscript 9.05) (ImageMagick 6.3.8 01 (Inkscape inkscape 0.44.1) (LaTeX with hyperref) (Mac OS X 10.5.8 Quartz PDFContext) (MiKTeX pdfTeX-1.40.9) (Microsoft� Publisher 2010) (cairo 1.9.5 (http: (pdfTeX-2.00.0) (pdfeTeX-1.403) (xdvipdfmx \(0.7.5\)) The only two that I found that included a copyright symbol were Qt and Microsoft Word. The above Microsoft Publisher string presumably includes a registered trademark symbol, which is more common. True. I was mainly pointing out that I don't think the copyright would extend to the document. I don't mind removing it, but I'd like to have the producer point to Qt by default. I suggest removing the Producer copyright string to avoid confusion since it is clear that Digia doesn't seek to claim copyright on user-generated content. Along the same lines, it might be useful to add a setProducer() function to QPrinter for applications that create PDFs as a key part of their functionality. Both are fine for me, a patch is welcome :) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: Disable ActiveQt from MinGW
Hi, I'm wondering whether we should remove ActiveQt from the MinGW binary packages, and skip it by default if we build for MinGW. I'm not an expert on ActiveQt, but my understanding is that it's of minor use without an IDL compiler. MinGW doesn't offer one, which is why all examples except the 'webbrowser' one are skipped for MinGW ... and that one crashes: https://bugreports.qt-project.org/browse/QTBUG-32140 So, any thoughts on this? Surely the bug above mentioned can be fixed, but is there any use of shipping ActiveQt for MinGW if there is no idl compiler? I understood you can't just use the Microsoft midl one ... Regards Kai -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868 Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Disable ActiveQt from MinGW
Hello, Wine provides an IDL compiler, which has been adopted my mingw-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-tools/widl/ Mozilla is using it: https://developer.mozilla.org/en/docs/Cross_Compile_Mozilla_for_Mingw32#Install_widl_(optional) On Thu, Oct 10, 2013 at 11:24 AM, Koehne Kai kai.koe...@digia.com wrote: Hi, I'm wondering whether we should remove ActiveQt from the MinGW binary packages, and skip it by default if we build for MinGW. I'm not an expert on ActiveQt, but my understanding is that it's of minor use without an IDL compiler. MinGW doesn't offer one, which is why all examples except the 'webbrowser' one are skipped for MinGW ... and that one crashes: https://bugreports.qt-project.org/browse/QTBUG-32140 So, any thoughts on this? Surely the bug above mentioned can be fixed, but is there any use of shipping ActiveQt for MinGW if there is no idl compiler? I understood you can't just use the Microsoft midl one ... Regards Kai -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868 Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.2 Testing
Hello, It's time to test Beta 1 candidate packages to make sure that they are as good as possible. Could you help by testing them? 1. Beta 1 packages are available here (please take the latest ones; Linux and Mac available): http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/http://download.qt-project.org/development_releases/qt/5.2/5.2.0-alpha/ 2. Qt bug reports should be reported in JIRA: https://bugreports.qt-project.org/ 3. The Sanity Test Guidelines can be used during testing: http://qt-project.org/wiki/Sanity-Test-Guidelines 4. Feel free to report your testing effort via: http://testresults.qt-project.org/forms/release-testing/ Thanks, /Rafal Rafal Motyka Quality Assurance Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing
On Thu, 2013-10-10 at 10:11 +, Motyka Rafal wrote: Hello, It's time to test Beta 1 candidate packages to make sure that they are as good as possible. Could you help by testing them? 1. Beta 1 packages are available here (please take the latest ones; Linux and Mac available): http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ 2. Qt bug reports should be reported in JIRA: https://bugreports.qt-project.org/ 3. The Sanity Test Guidelines can be used during testing: http://qt-project.org/wiki/Sanity-Test-Guidelines 4. Feel free to report your testing effort via: http://testresults.qt-project.org/forms/release-testing/ Thanks, /Rafal I have to mention that your link http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ actually points to http://download.qt-project.org/development_releases/qt/5.2/5.2.0-alpha/ don't know how that happened. Petko ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing
First thing to mention - I could not deselect QtCreator (or Tools ) from the installation (Manjaro/GNOME environment , I don't know if that matters) . Secondly : Could not load the following plugins : Help Details: /home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp.so: Cannot load library /home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp.so: (libudev.so.0: cannot open shared object file: No such file or directory) 3.There are no examples present , and Creator crashes when I search for examples but , that's probably because of the lack of Help plugin. 4.This bug (I just filed it,though it's been around for some time now) : https://bugreports.qt-project.org/browse/QTBUG-34005 . That's pretty much it for now. Petko On Thu, 2013-10-10 at 10:11 +, Motyka Rafal wrote: Hello, It's time to test Beta 1 candidate packages to make sure that they are as good as possible. Could you help by testing them? 1. Beta 1 packages are available here (please take the latest ones; Linux and Mac available): http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ 2. Qt bug reports should be reported in JIRA: https://bugreports.qt-project.org/ 3. The Sanity Test Guidelines can be used during testing: http://qt-project.org/wiki/Sanity-Test-Guidelines 4. Feel free to report your testing effort via: http://testresults.qt-project.org/forms/release-testing/ Thanks, /Rafal ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing
Oh , sorry ,I'll use the form for reporting, I didn't see it on first glimpse. On Thu, 2013-10-10 at 10:11 +, Motyka Rafal wrote: Hello, It's time to test Beta 1 candidate packages to make sure that they are as good as possible. Could you help by testing them? 1. Beta 1 packages are available here (please take the latest ones; Linux and Mac available): http://download.qt-project.org/snapshots/qt/5.2/5.2.0-beta1/ 2. Qt bug reports should be reported in JIRA: https://bugreports.qt-project.org/ 3. The Sanity Test Guidelines can be used during testing: http://qt-project.org/wiki/Sanity-Test-Guidelines 4. Feel free to report your testing effort via: http://testresults.qt-project.org/forms/release-testing/ Thanks, /Rafal ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of p10 Sent: Thursday, October 10, 2013 1:18 PM Cc: development@qt-project.org Subject: Re: [Development] Qt 5.2 Testing First thing to mention - I could not deselect QtCreator (or Tools ) from the installation (Manjaro/GNOME environment , I don't know if that matters) . That's by design. The Qt versions need to register themselves with Qt Creator, and therefore require it. The alternative would be to accept that if you say install Qt first, and then later on Qt Creator, there's no automatically configured Kit for this version in Qt Creator. Or we invent some more complicated mechanism , like a central registry ... Secondly : Could not load the following plugins : Help Details: /home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp .so: Cannot load library /home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp .so: (libudev.so.0: cannot open shared object file: No such file or directory) That's probably a webkit dependency ... did we require libudev in previous installers? Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Testing
On windows cmake cannot find dll-s again
Had to change QtCoreConfig.cmake and other modules line 31
set(imported_location ${_qt5Core_install_prefix}/lib/${LIB_LOCATION})
to
set(imported_location ${_qt5Core_install_prefix}/bin/${LIB_LOCATION})
and on mac cmake complains missing GL framewroks
workaround added ${CMAKE_OSX_SYSROOT}/ to path
Qt5GuiConfigExtras.cmake line 64
_qt5gui_find_extra_libs(OPENGL OpenGL;AGL
/System/Library/Frameworks/OpenGL.framework/Headers;/System/Li..
_qt5gui_find_extra_libs(OPENGL OpenGL;AGL
/${CMAKE_OSX_SYSROOT}/System/Library/Frameworks/OpenGL.framework/Headers;/${CMAKE_OSX_SYSROOT}/System/Li..
Raul
On Oct 10, 2013, at 3:03 PM, Koehne Kai kai.koe...@digia.com wrote:
-Original Message-
From: development-bounces+kai.koehne=digia@qt-project.org
[mailto:development-bounces+kai.koehne=digia@qt-project.org] On
Behalf Of p10
Sent: Thursday, October 10, 2013 1:18 PM
Cc: development@qt-project.org
Subject: Re: [Development] Qt 5.2 Testing
First thing to mention - I could not deselect QtCreator (or Tools ) from the
installation (Manjaro/GNOME environment , I don't know if that
matters) .
That's by design. The Qt versions need to register themselves with Qt
Creator, and therefore require it.
The alternative would be to accept that if you say install Qt first, and then
later on Qt Creator, there's no automatically configured Kit for this version
in Qt Creator. Or we invent some more complicated mechanism , like a central
registry ...
Secondly : Could not load the following plugins : Help
Details:
/home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp
.so: Cannot load library
/home/p10/Qt5.2.0/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libHelp
.so: (libudev.so.0: cannot open shared object file: No such file or
directory)
That's probably a webkit dependency ... did we require libudev in previous
installers?
Regards
Kai
___
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] Disabling exception support in QtCore?
On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Since we have public signals and public slots and other libraries do the same, it stands to reason that a third-party is expected to connect them. Moreover, it stands to reason that a third-party might connect a fourth-party slot to one of our (first-party) signals. Your logic is flawed. The fact that some signals cannot be connected to slots that do not throw exceptions does not implies that no signals can be connected to slot that throw exceptions. When developing an application, developer who throw exceptionshould know what they are doing. It is not allowed to connect a signal from a exception unsafe class to a slot that may throw exception. But if they know that the class is exception safe, it should be allowed for them to connect signal from this class to slots that throw exceptions. That would mean people who do connections should have to pay attention to what slots throw and know what signals can cope with exceptions being thrown. Signals and slots are not different from normal functions in that respect (especially virtual functions) One need to take care who calls your function when you throw exceptions. I agree. Which is why I am saying that we need to establish rules for when exceptions would be allowed to escape a slot. Right now, our rule is: Qt code is noexcept. If your slot throws when called by Qt, the behaviour is undefined. If it throws when something else calls it, we make no statements. If you want to change that rule, then we can discuss it. I want to change that rule. Unles specified here, Qt code is noexcept. The only places where exceptions are allowed are: - Exceptions thrown by a slot are propagated to the signal connected with direct connection - Exceptions propagated through a call to invokeMethod are propagated from the method to the call - Exceptions thrown from QtConcurrent will be by re thrown when calling the QFuture API if the exception is a subclass of QException (Did I miss something?) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ABI of deprecated supportsThreadedFontRendering()
Hi!
I just learnt about what looks like an ABI regression in Qt 5.2:
The function QFontDatabase::supportsThreadedFontRendering() got deprecated
in 5.2 with commit b0b786a2f05e9451a65519ab8904f55c35f51b7d:
-static bool supportsThreadedFontRendering();
+#if QT_DEPRECATED_SINCE(5, 2)
+QT_DEPRECATED static inline bool supportsThreadedFontRendering() {
return true; }
+#endif
At the same time it got inlined. At least with MinGW this made the symbol
go away. While e.g. MSVC still exports it.
Now I don't know the exact strategy pursured by QT_DEPRECATED but I assume
that the function's symbol should not disappear from the 5.2 ABI? If so,
I wonder whether removing the inline will already do the job.
Harri.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Disable ActiveQt from MinGW
-Original Message- From: Pau Garcia i Quiles [mailto:pgqui...@elpauer.org] Sent: Thursday, October 10, 2013 11:44 AM To: Koehne Kai Cc: development@qt-project.org Subject: Re: [Development] Proposal: Disable ActiveQt from MinGW Hello, Wine provides an IDL compiler, which has been adopted my mingw-w64: http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64- tools/widl/ Fair enough. We're even shipping it in the mingw-builds toochain, although it's named 'i686-w64-mingw32-widl' :) Let's see, maybe I can get the combo even working... Regards Kai (who didn't have anything to do with ActiveQt / COM since a decade, but well ...) Mozilla is using it: https://developer.mozilla.org/en/docs/Cross_Compile_Mozilla_for_Mingw3 2#Install_widl_(optional) On Thu, Oct 10, 2013 at 11:24 AM, Koehne Kai kai.koe...@digia.com wrote: Hi, I'm wondering whether we should remove ActiveQt from the MinGW binary packages, and skip it by default if we build for MinGW. I'm not an expert on ActiveQt, but my understanding is that it's of minor use without an IDL compiler. MinGW doesn't offer one, which is why all examples except the 'webbrowser' one are skipped for MinGW ... and that one crashes: https://bugreports.qt-project.org/browse/QTBUG-32140 So, any thoughts on this? Surely the bug above mentioned can be fixed, but is there any use of shipping ActiveQt for MinGW if there is no idl compiler? I understood you can't just use the Microsoft midl one ... Regards Kai -- Kai Köhne, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868 Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ABI of deprecated supportsThreadedFontRendering()
On Thursday 10 October 2013 15:04:40 Harri Porten wrote:
Hi!
I just learnt about what looks like an ABI regression in Qt 5.2:
The function QFontDatabase::supportsThreadedFontRendering() got deprecated
in 5.2 with commit b0b786a2f05e9451a65519ab8904f55c35f51b7d:
-static bool supportsThreadedFontRendering();
+#if QT_DEPRECATED_SINCE(5, 2)
+QT_DEPRECATED static inline bool supportsThreadedFontRendering() {
return true; } +#endif
At the same time it got inlined. At least with MinGW this made the symbol
go away. While e.g. MSVC still exports it.
Now I don't know the exact strategy pursured by QT_DEPRECATED but I assume
that the function's symbol should not disappear from the 5.2 ABI? If so,
I wonder whether removing the inline will already do the job.
Hi,
Thanks for spotting this issue.
That patch indeed removed a symbol.
Removing inline is not enough. One need to put back the definition in the
.cpp file.
Please fill a bug report. (or a patch :-))
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Thursday 10 October 2013 15:14:02 André Somers wrote: Op 10-10-2013 14:53, Olivier Goffart schreef: On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Even for applications this statement is nonsense. For all but trivial applications that during their lifetime only get worked on by a single developer, the likelyhood of the same person always writing the slots for every signal goes to 0 rapidly with the age and number of developers on a project. That's not what I said. And regardless, I don't think it has any relevance for the problem in question. Within a code base that uses exception, developers should know which part of the code is exception safe and which part of the code can throw exception. And they know they should not call a function that can throw an exception from code that is not exception safe. (Hence they don't connect a signal from code that is not exception safe to a slot that throw an exception) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Split submission
On 10 oct. 2013, at 01:49, Thiago Macieira wrote: On quinta-feira, 10 de outubro de 2013 01:36:18, Samuel Gaist wrote: Hi, I just started to split a submission in several patches like Stephen Kelly taught me. There's just one thing I forgot to ask him: how should the patches be organized and sent since when broken down (it should be three patches), the last one would only apply once the second patch is applied ? The first and second part can be separated (so two different submissions) since they solve two different but related problems (the second being triggered when solving the first). Also what would be the best/recommended setup git wise ? Should I make a topic branch from my topic branch ? The easiest is to just git push all three. They will be reviewed independently. And you are the person to hit the stage button, so you should know which one needs to go in which order. Now, the problem is when the second or third patch needs to be updated. You should avoid updating the first (and second) patch(es) when submitting the update, unless you actually want that. To do that, you should check out the parent commit and then cherry-pick the new change. Steps: 1) open the review page in Gerrit 2) copy the SHA-1 of the latest patch 3) in your shell, right: git checkout [paste the SHA-1]~ remember to include the ~ at the end 4)git cherry-pick [your new commit] 5)git gpush :stable or, if you're using my gerrit-pick script, you can do it in one command: git gp -t stable -b [paste here]~ [your commit] -- 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 Thank you for the instructions ! Is there already a wiki describing that ? Something like Advanced Gerrit Usage ? That might come handy for people not having their git-fu black-belt yet ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Split submission
Thank you for the informations and tips ! On 10 oct. 2013, at 07:50, Ziller Eike wrote: Hi, you can just have the patches sequentially in your local branch and push these together (git push gerrit HEAD:refs/for/dev or whereever that should go, that pushes all your local commits up to HEAD). Gerrit shows dependency information in the changes if you push them together, i.e. the 'later' changes show the changes they depend on in the dependencies section of the page. Gerrit never prevents that changes are (tried to be) submitted in a different order though, even with topic branches afaik. If you want to make sure that your reviewers are not confused (if you haven't talked to them already anyhow), you can add a comment about the dependency too. Br, Eike -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chaussee 13, D-12489 Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius From: development-bounces+eike.ziller=digia@qt-project.org [development-bounces+eike.ziller=digia@qt-project.org] on behalf of Samuel Gaist [samuel.ga...@edeltech.ch] Sent: 10 October 2013 01:36 To: development@qt-project.org Subject: [Development] Split submission Hi, I just started to split a submission in several patches like Stephen Kelly taught me. There's just one thing I forgot to ask him: how should the patches be organized and sent since when broken down (it should be three patches), the last one would only apply once the second patch is applied ? The first and second part can be separated (so two different submissions) since they solve two different but related problems (the second being triggered when solving the first). Also what would be the best/recommended setup git wise ? Should I make a topic branch from my topic branch ? Thank you ___ 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] Disabling exception support in QtCore?
On Thursday, October 10, 2013 9:26 AM, Olivier Goffart oliv...@woboq.com wrote: On Thursday 10 October 2013 15:14:02 André Somers wrote: Op 10-10-2013 14:53, Olivier Goffart schreef: On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote: On quinta-feira, 3 de outubro de 2013 10:36:44, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible with the connection semantics. That would mean any signal could throw ANY exception. It would also preempt the execution of further slots, which might be important. Usually the person who connects a signal to a slot is a completely different developer than who wrote the signal or the slot. I think your assumptions are false. When using signals and slot in an application one write both the signal and the slot at the same time, to wire two part of that same appliation. That's not at all true. If it were, we wouldn't have signals or slots in our public API. If people were supposed to write the signals and the slots they connect, all our signals and slots would be private. I did not said that the signal and the slot were always written by the same person. And I explicitly said for an application, and you are talking about libraries. Even for applications this statement is nonsense. For all but trivial applications that during their lifetime only get worked on by a single developer, the likelyhood of the same person always writing the slots for every signal goes to 0 rapidly with the age and number of developers on a project. That's not what I said. It may not have been what you said, but it is what would occur. And regardless, I don't think it has any relevance for the problem in question. Quite relevant. Within a code base that uses exception, developers should know which part of the code is exception safe and which part of the code can throw exception. And they know they should not call a function that can throw an exception from code that is not exception safe. (Hence they don't connect a signal from code that is not exception safe to a slot that throw an exception) So now you have to a wrapper slot to wrap exceptions for any object from a library that you may interact with, or potentially any other code in your own project. I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Thursday 10 October 2013 08:22:44 BRM wrote: I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. Programming is not easy. Now, our goal is to make programming with Qt as easy as possible. Tell me what makes programming easier: 1) We forbid any use of exception in any slot connected to any signal. - Programmers that don't use exceptions don't care because it does not impact them. - Programmers that uses exception in their application to forward errors cannot use signals and slots to propagate exceptions from one object of their application to another anymore. 2) We allow slots to forward the exception to the signal. - Programmers that don't use exceptions still don't care because it does not impact them. - Programmers that use exceptions can hapilly let exceptions go from the slot to where the signal is emitted. If you are not using exception now as I understand from your text above, then nothing changes for you. However, someone who is using currently exceptions, they will have to change their code for more complicated code because we decided to forbid it (for their own good) May I recall that exceptions through signals and slots always worked, and was used.And now you need to give a good reason to forbid it. Reducing the size of QtCore might be a good reason, but just saying it's for your own good is not. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On 10/10/13 6:02 PM, Olivier Goffart oliv...@woboq.com wrote: On Thursday 10 October 2013 08:22:44 BRM wrote: I have personnally maintained a 400k+ SLOC codebase based on QT. It made extensive use of Signals/Slots between objects. Even though I was pretty much the only developer working on it, I still had to quite often track through signals/slots to make sure I understood things. Not because the codebase was unclear, but because it was quite non-trivial. It would have been an extensive PITA to try to know which ones I could or could not use exceptions with. I'm no compiler expert - but without help from the compiler to make sure that kind of things doesn't happen - e.g. marking signals/slots as Q_EXCEPTION_THROW and Q_EXCEPTION_SAFE and having some part of the compiler chain detect and at minimal warn of issues - it will not be feasible. Programming is not easy. Now, our goal is to make programming with Qt as easy as possible. Tell me what makes programming easier: 1) We forbid any use of exception in any slot connected to any signal. - Programmers that don't use exceptions don't care because it does not impact them. - Programmers that uses exception in their application to forward errors cannot use signals and slots to propagate exceptions from one object of their application to another anymore. 2) We allow slots to forward the exception to the signal. - Programmers that don't use exceptions still don't care because it does not impact them. - Programmers that use exceptions can hapilly let exceptions go from the slot to where the signal is emitted. If you are not using exception now as I understand from your text above, then nothing changes for you. However, someone who is using currently exceptions, they will have to change their code for more complicated code because we decided to forbid it (for their own good) May I recall that exceptions through signals and slots always worked, and was used.And now you need to give a good reason to forbid it. Reducing the size of QtCore might be a good reason, but just saying it's for your own good is not. Agree with Olivier. Let's keep the level of support we had in Qt 4.x for throwing exceptions from slots: * It's undefined behaviour unless the place that emits the signal is prepared to catch the exception. * If a slot throws, no further slots connected to the signal will get called * throwing from any place that's connected to a signal defined in the Qt libraries leads to undefined behaviour The size reduction of QtCore is not a valid argument IMO. First of all we're talking about a number below 10%, and secondly this number could be reduced to almost 0 by making the build system for Qt Core only compile a few selected files with exception support enabled. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for Tizen Alpha 4 Released: Support for 3.0, New SDK, IVI Wayland
Update: 1. Video: Deploying Apps to Smartphone With Qt for Tizen SDK: https://www.youtube.com/watch?v=aA-8h-Vh4I0 2. Video: Tizen IVI Device Powered By Qt Wayland: https://www.youtube.com/watch?v=5c35fqNZlmU -- regards / pozdrawiam, Jaroslaw Staniek Kexi Calligra KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quinta-feira, 10 de outubro de 2013 13:54:09, Alex Malyushytskyy wrote: It never worked.with other than direct connections. As I see it there is a simple choice either to provide indirect connections or propagate exceptions to signal. Otherwise you always have to assume that every slot is called the way you can't let exception leave slot anyway. I don't mind complex rules. If anyone wants to use this feature, they have to know how it works. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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
