Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Monday 27 July 2015 08:01:53 André Somers wrote: I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 28 July 2015 06:19:03 Andre Somers wrote: The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. Well, the passage is legalese for saying that the Foundation gets all rights to the source code. What the Foundation does with the source code is its own decision. It can: a) do nothing and let the code die b) release it to an open source project under BSD licence c) ditto, but using LGPL d) give it to a company to commercialise it under the dual licensing scheme again e) something else, but the options b, c,and d are the most likely ones The important thing to note is that the source code reverting to the Foundation does not imply neither the end of either the open source project nor the end of commercial licensing. -- 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] Qt LTS C++11 plans (CopperSpice)
On 27-7-2015 18:21, Thiago Macieira wrote: On Monday 27 July 2015 08:01:53 André Somers wrote: I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Op 27-7-2015 om 03:47 schreef Ansel Sermersheim: On 7/26/15 3:01 PM, Kevin Kofler wrote: Ansel Sermersheim wrote: We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. That in turn allows everyone else, or even you, to take the code proprietary, so in the case this clause is triggered (which depends on Qt, i.e., neither on you nor on the contributor), it is functionally equivalent to a CLA allowing proprietary relicensing. There is one fundamental difference between the CopperSpice and Qt licensing situation. In the (unlikely) event that CopperSpice becomes BSD licensed, it becomes BSD licensed for everyone. This means anyone, anywhere, has equal rights to make changes and profit from them. This is very different from one particular entity owning the right to profit from an open source project. The argument between GPL-style vs BSD-style licenses is as old as the hills, but both licenses do treat all contributors equally. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 7/26/15 3:01 PM, Kevin Kofler wrote: Ansel Sermersheim wrote: We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. That in turn allows everyone else, or even you, to take the code proprietary, so in the case this clause is triggered (which depends on Qt, i.e., neither on you nor on the contributor), it is functionally equivalent to a CLA allowing proprietary relicensing. There is one fundamental difference between the CopperSpice and Qt licensing situation. In the (unlikely) event that CopperSpice becomes BSD licensed, it becomes BSD licensed for everyone. This means anyone, anywhere, has equal rights to make changes and profit from them. This is very different from one particular entity owning the right to profit from an open source project. The argument between GPL-style vs BSD-style licenses is as old as the hills, but both licenses do treat all contributors equally. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Ansel Sermersheim wrote: We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. That in turn allows everyone else, or even you, to take the code proprietary, so in the case this clause is triggered (which depends on Qt, i.e., neither on you nor on the contributor), it is functionally equivalent to a CLA allowing proprietary relicensing. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Wednesday 22 July 2015 16:47:21 Olivier Goffart wrote: template typename Key, typename T using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey; This is still source incompatible (because of forward declarations) and binary incompatible too. Oops! You're right. -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21. July 2015 16:03:56 Thiago Macieira wrote: On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Not passing judgement. I was only asking for clarification, since that was the only feature that Ansel mentioned and, depending on the actual change, is not a feature at all since QMap alreaydy supported it. Too bad that adding a template parameter to QMap is a huge SiC, as people forward declare it with two template arguments, and we never provided headers for forward declarations... :( We can fix that with C++11 template aliases. template typename Key, typename T using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey; This is still source incompatible (because of forward declarations) and binary incompatible too. Note however that a function taking QMapFoo, Bar is *not* the same as a function taking QMapComparatorFoo, Bar, qMapLessThanKeyFoo. The two types are not the same, even though they are. Anyway, If one need to do advanced usages, one could use std::map. Re-implementing the standard library is not a goal of Qt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
We would like to announce our release of CopperSpice 1.1.0. We have added and changed several things including a modification to to QMap to user defined comparisons. We have a timeline others may be interested in viewing in our overview documentation. We will have API documentation uploaded by Aug 15. http://www.copperspice.com/docs/cs_overview/timeline.html Barbara spent a good deal of time reviewing the CLA for Qt. We appreciate the work Thiago and Lars have done on the CLA and contribution guidelines. On every thread she read and with people she spoke with, there was always several who expressed concerns. We even had a nice chat with Tobias Hunger about this issue. Our view as well as the view from many other developers, is that the CLA gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version. We feel this goes against the share and share alike principle of community based open source software. From the countless local developers in the Silicon Valley area we have communicated with, Qt is not typically viewed as a community project. There is nothing inherently wrong with this approach, it just did not fit our paradigm. We are speaking at CPPCon in September and our intent is simply to explain the CLA did not work for us. The main purpose of our presentation is to present CopperSpice and offer C++ developers an alternative GUI library. Ansel On 7/3/15 12:52 AM, Simon Hausmann wrote: On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote: There is always CopperSpice the Qt fork which uses C++11. They've got rid of moc and plan to replace Qt containers with std ones. Afterwards maybe they will add support for namespaces to their peppermill source convertor utility. I am one of the developers of CopperSpice and I would like to elaborate on our project. Our initial release of CopperSpice was in July 2014 with our target audience being our local C++ Users Group in the San Francisco Bay area. We wanted to explore the interest in CopperSpice and obtain feedback regarding the steps we took to remove moc. Our full presentation in February 2015 was well received and attended by several prominent people. I for one welcome your efforts. I think it's great that you're trying out new things on the shoulders of Qt. To me this feels healthy and I'm at this point not worried about fragmentation. Experimentation is something we should encourage, even if those experiments happen in deep core parts of the framework. I'm also glad to see that you're sharing your work with the rest of the development community on github. It would be great if some of your improvements, some of your innovations could - in the future - find their way back to Qt. It's not evident at this point how exactly, but I think it would be good to keep it in the back of our heads. That said, I did see the slides of your presentation in February 2015 and I am disappointed about the slide with the heading Why we developed CopperSpice. It says that one of the reasons was that Libraries not developed as a true open source project. This is disappointing for me to read. Thiago, Lars and others who have worked on the governance rules of Qt have done tremendous work to establish the true open source umbrella, especially by learning from other projects and taking the experience into account when formulating the contribution and governance guidelines. I hope that in future presentations of your project you are not going to give your audience the impression that Qt is not a true open source project. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com: gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 18:32:09 Ansel Sermersheim wrote: On 7/21/15 6:23 PM, Thiago Macieira wrote: Right, we usually work around this by having QMapCaseInsensitiveString, X. Certainly possible to do, but sometimes quite awkward depending on the situation. Agreed. I don't see the need to do the same for QHash. How often do people need a different comparator and/or a different hashing function for a given class type? I have in the past used non-standard hashing and equality functions for std::unordered_map, but I will admit it is far less common. Can you share why you needed 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote: The most common use case of this is creating a QMapQString, X that is sorted case insensitively. The STL allows this for std::map, and coming to Qt from a background of standard C++ I was amazed that this very common use case was not supported. Right, we usually work around this by having QMapCaseInsensitiveString, X. This is something we should fix or 6.0, if we can accept the source compatibility break against forward declarations of QMap. I don't see the need to do the same for QHash. How often do people need a different comparator and/or a different hashing function for a given class type? -- 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] Qt LTS C++11 plans (CopperSpice)
On 7/21/15 3:15 PM, Marc Mutz wrote: On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote: As to your question about relicensing, can you please elaborate on what this is referring to? As long as Qt is covered by the current license, we can not relicense CopperSpice since we are bound by the terms of the licenses under which we forked the code. You own the copyright to those parts which you added. Come GPL4, you might conceivably want to use that license. Assuming TQC releases its code under GPL4, too, which it can, that leaves your own original work. Assuming it's just you and Barbara, you won't have problems. But if you have 200 contributors, half of which vanished from the face of the earth after a few months of being active, you will have a harder time to track every contributor down and get approval for the relicensing from each of them. It's why many Free Software projects require some form of copyright assignment, incl. the Godfather of GPL projects, GNU. As we mentioned, we have several people testing CopperSpice as well as others asking about how to contribute to the project. We certainly look forward to having an active development community. We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. You seem to say that Copperspice is in some sense more free than Qt, because of the missing CLA, but you may have locked yourself into a set of licenses forever, like the Linux kernel did (and it's anyone's guess whether Linus is *actually* happy with the GPL v2 and being stuck with it forever, or whether dropping the or later clause secretly gnaws at his conscience, after all he also publicly condemns C++ and then goes to write his diving app in Qt/C++ :) Just to be clear, we are not opposed to a CLA and as noted above we have one as well. We simply did not feel comfortable contributing under the Qt Company CLA for reasons which we have previously stated. We do understand and appreciate the logic and the financial reasons that led to the Qt Company CLA. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 7/21/15 6:23 PM, Thiago Macieira wrote: On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote: The most common use case of this is creating a QMapQString, X that is sorted case insensitively. The STL allows this for std::map, and coming to Qt from a background of standard C++ I was amazed that this very common use case was not supported. Right, we usually work around this by having QMapCaseInsensitiveString, X. Certainly possible to do, but sometimes quite awkward depending on the situation. This is something we should fix or 6.0, if we can accept the source compatibility break against forward declarations of QMap. I don't see the need to do the same for QHash. How often do people need a different comparator and/or a different hashing function for a given class type? I have in the past used non-standard hashing and equality functions for std::unordered_map, but I will admit it is far less common. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote: Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com: gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. Note how it's copperspice._com_, not .org :) Will be interesting to see how they want to make money off their project. Or how they deal with the problem of relicensing once they grow to 200 instead of 2 developers... Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Suppose you want to have maps sorting by different criteria, especially if the type doesn't have proper semantics for operator and thus shouldn't have one defined (e.g. complex numbers). Too bad that adding a template parameter to QMap is a huge SiC, as people forward declare it with two template arguments, and we never provided headers for forward declarations... :( Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote: We would like to announce our release of CopperSpice 1.1.0. We have added and changed several things including a modification to to QMap to user defined comparisons. As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Our view as well as the view from many other developers, is that the CLA gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version. We feel this goes against the share and share alike principle of community based open source software. True. It's intended instead to support the virtuous cycle that Trolltech talked about: the commercial version helps fund the development of the open source version. Shut down the commercial version and the well runs dry. We wouldn't be able to sustain the development pace we currently have. All other attempts at funding exclusively through extra services have failed and have not produced nearly as much funds as the licensing business. From the countless local developers in the Silicon Valley area we have communicated with, Qt is not typically viewed as a community project. There is nothing inherently wrong with this approach, it just did not fit our paradigm. You have to qualify what you mean by community project. As long as you do that, it should be no problem. We are speaking at CPPCon in September and our intent is simply to explain the CLA did not work for us. The main purpose of our presentation is to present CopperSpice and offer C++ developers an alternative GUI library. That's fine. We just ask that you don't say CLA means not a community project. There are quite a few people and companies that don't like CLAs (I work for one -- getting Intel to sign the Qt Project CLA took 8 months). Their existence is an understandable reason to not contribute to a project. But please don't say we're not a community. -- 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] Qt LTS C++11 plans (CopperSpice)
Hi Gunnar, We used to say Qt which we thought was the name of the project. We were asked to use the name The Qt Project. We do not mind changing how we address the company and the library. Since we meant to harm may we suggest this be conveyed to others a little more gently. As to your comment regarding licensing, I will quote from the current Qt CLA, Section 3.1: Subject to the terms and conditions of this Agreement, Licensor hereby grants, in exchange for good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, to The Qt Company a sublicensable, irrevocable, perpetual, worldwide, non-exclusive, royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt, translate, modify, and prepare derivative works of, publicly display, publicly perform, sublicense, make available and distribute Licensor Contribution(s) and any derivative works thereof under license terms of The Qt Company’s choosing including any Open Source Software license. I am not a lawyer but this language is very clear. It may not be The Qt Company policy or practice to accept changes into the commercial version only, but if I were to sign the CLA I would be granting them the right, irrevocably and perpetually. Since these rights are transferable I have no recourse if the license is transferred to another entity who uses my contribution in a way I did not intend. Most open source development communities are structured in such a way that all participants have equal rights. The Qt Company is in a position to exercise additional rights not enjoyed by the rest of the Qt community. This is certainly a legal and enforceable position. However, it bothers many members of the larger open source community including myself. We have talked with other developers and read discussions about this for over a decade. Many members of the larger open source community, including myself, are not comfortable with this clause. Ansel Sermersheim On 7/21/15 10:53 AM, Gunnar Roth wrote: Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com mailto:an...@copperspice.com: gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Hi Marc, We do own copperspice.com, .org, .net, and .info. We set .com up as the primary site for no particular reason. There is no question that making money is of value. However, our main goal at this time is to develop CopperSpice and share it with the community. We believe money will follow but it is not our primary goal or direction. We have a few beta testers, an excellent project mentor, a couple of people contributing changes, and we are working with someone on the packaging process with various unix distributions As to your question about relicensing, can you please elaborate on what this is referring to? As long as Qt is covered by the current license, we can not relicense CopperSpice since we are bound by the terms of the licenses under which we forked the code. Ansel Sermersheim On 7/21/15 12:36 PM, Marc Mutz wrote: On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote: Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@copperspice.com: gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. Note how it's copperspice._com_, not .org :) Will be interesting to see how they want to make money off their project. Or how they deal with the problem of relicensing once they grow to 200 instead of 2 developers... Thanks, Marc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Suppose you want to have maps sorting by different criteria, especially if the type doesn't have proper semantics for operator and thus shouldn't have one defined (e.g. complex numbers). Too bad that adding a template parameter to QMap is a huge SiC, as people forward declare it with two template arguments, and we never provided headers for forward declarations... :( It's spelled _s_t_d_:_:_m_a_p_ :) -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim an...@copperspice.com wrote: As to your question about relicensing, can you please elaborate on what this is referring to? As long as Qt is covered by the current license, we can not relicense CopperSpice since we are bound by the terms of the licenses under which we forked the code. I think the actual question(s) were: - Are you and Barbara developing CopperSpice full-time, part-time or just on your spare time? - How do you sustain development of CopperSpice? Support services to Qt4 delopers? You use it only for your own (paid-for) projects? Venture Capital? No funding at all, just hobby? And I would repeat the question Milian asked: why did you fork Qt4 instead of Qt5? -- 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] Qt LTS C++11 plans (CopperSpice)
On 7/21/15 11:37 AM, Thiago Macieira wrote: On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote: We would like to announce our release of CopperSpice 1.1.0. We have added and changed several things including a modification to to QMap to user defined comparisons. As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? The qMapLessThanKey solution does not help at all if you want to create a user defined sort order for a class that already has a defined ordering. The most common use case of this is creating a QMapQString, X that is sorted case insensitively. The STL allows this for std::map, and coming to Qt from a background of standard C++ I was amazed that this very common use case was not supported. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 7/21/15 4:03 PM, Thiago Macieira wrote: On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Not passing judgement. I was only asking for clarification, since that was the only feature that Ansel mentioned and, depending on the actual change, is not a feature at all since QMap alreaydy supported it. We brought this change up as representative of the kind of things that are being done. For a more comprehensive list check out the overview documentation on our website: http://www.copperspice.com/docs/cs_overview/index.html Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Not passing judgement. I was only asking for clarification, since that was the only feature that Ansel mentioned and, depending on the actual change, is not a feature at all since QMap alreaydy supported it. Too bad that adding a template parameter to QMap is a huge SiC, as people forward declare it with two template arguments, and we never provided headers for forward declarations... :( We can fix that with C++11 template aliases. template typename Key, typename T using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey; Note however that a function taking QMapFoo, Bar is *not* the same as a function taking QMapComparatorFoo, Bar, qMapLessThanKeyFoo. The two types are not the same, even though they are. -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 21 July 2015 12:21:35 Ansel Sermersheim wrote: Hi Gunnar, We used to say Qt which we thought was the name of the project. We were asked to use the name The Qt Project. We do not mind changing how we address the company and the library. Since we meant to harm may we suggest this be conveyed to others a little more gently. The point is that there's a difference between: Qt the product, the framework, the libraries Qt Project the open source project organised to develop Qt The Qt Company the company that holds the rights under the CLA and the trademark to Qt And, for that matter, Qt Creator the IDE (lots of people come on IRC and say something about Qt, when they meant Qt Creator) I am not a lawyer but this language is very clear. It may not be The Qt Company policy or practice to accept changes into the commercial version only, but if I were to sign the CLA I would be granting them the right, irrevocably and perpetually. Since these rights are transferable I have no recourse if the license is transferred to another entity who uses my contribution in a way I did not intend. That's actually common practice. The commercial version is identical to the open source version in functionality and codebase. The reverse is required by the KDE Free Qt Foundation: everything released commercially must be present in the open source version (at least, as long as it's Android or X11, but in practice it is the case for all platforms). It makes no sense to keep two separate trees. Even when Trolltech had pieces of functionality that weren't present in the open source version, Trolltech kept a single tree. The release scripts simply removed some files before the release. That hasn't been the case since March 2009. When the Git repositories opened. Most open source development communities are structured in such a way that all participants have equal rights. The Qt Company is in a position to exercise additional rights not enjoyed by the rest of the Qt community. This is certainly a legal and enforceable position. However, it bothers many members of the larger open source community including myself. Understandable. For us, it's a trade-off: the community accepts giving The Qt Company some extra rights in exchange for them employing a large chunk of the work force, including the entirety of the QA team and running the entire CI system and infrastructure for us. We have talked with other developers and read discussions about this for over a decade. Many members of the larger open source community, including myself, are not comfortable with this clause. -- 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] Qt LTS C++11 plans (CopperSpice)
On Wednesday 22 July 2015 00:15:19 Marc Mutz wrote: You own the copyright to those parts which you added. Come GPL4, you might conceivably want to use that license. Assuming TQC releases its code under GPL4, too, which it can, that leaves your own original work. Assuming it's just you and Barbara, you won't have problems. But if you have 200 contributors, half of which vanished from the face of the earth after a few months of being active, you will have a harder time to track every contributor down and get approval for the relicensing from each of them. It's why many Free Software projects require some form of copyright assignment, incl. the Godfather of GPL projects, GNU. To be fair, those projects often limit the set of licences that the code can be relicensed under. For example, KDE requires all inbound contributions to be either: GPLv2, GPLv3 or later GPLv2, GPLv3 or any later version by a decision of the KDE e.V. That is, even if the e.V. wanted to, it could not relicense under, say, the Apache licence version 2. It has to be an upgrade of the GPL. The KDE Free Qt Foundation requires relicensing under the terms of the BSD licence. No other. Other projects may limit to licenses approved by the Open Source Initiative. Some others may say OSI approved *and* copyleft. In the specific case of the Qt Project CLA, it makes no judgement. It can be any license, including non-open source ones. Which is the case. And since I'm being fair: the CLA is required by the KDE Free Qt Foundation, since The Qt Company has to have the rights to relicense everything under the BSD license. The only other option would be to have all inbound contributions under the BSD licence. -- 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] Qt LTS C++11 plans (CopperSpice)
snip, shared pointers Bo Thorsen sayeth: This answer is going to be one big IMHO. Anything that stops people from throwing shared pointers all over the code is A Good Thing. As someone once said: Shared pointers are a solution in search of a problem. Scoped pointers are fine, but shared pointers indicate a lack of handling of responsibility and ownership, which indicates bad design. This. Thank you, Bo. We regularly see issues with new-grads that seem to think that naked pointers should no longer exist, and all things should be std::unique_ptr or std::shared_ptr. OMFG. My assertion is that Design is: (1) What objects should exist. (2) Who owns them. (3) There is no Number Three ...and, we almost never have a good reason to use shared pointers. For you to use this as a reason for forking Qt is a very bad indication. I'm curious how much of the CopperSpice motivation is this, or other things like signals-on-templates and removal of moc. (I no longer need signals-on-templates, but many years ago I thought I did.) I must say, some of the CopperSpice decisions are very clever (heavy use of preprocessor to generate unique IDs that would otherwise be handled by moc). I similarly thought the Woboq guys with their moc-removal approach was quite clever, and these are two very different examples of a possible-future-direction-of-Qt that I think is quite healthy for our community to discuss. I appreciate the CopperSpice guys talking about their decisions and rationale on their design approach, and hope they will remain active in these forums. It's quite clear to me that some of the very dramatic moves occuring in C++14/17, including possible modules, and some of the new TMP capabilities open up options that we never previously could consider. And, it seems that some of these patterns and directions remain somewhat unexplored or otherwise represent new territory for consideration. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Friday 03 July 2015 09:42:54 Milian Wolff wrote: The above statement is far to broad to leave it uncommented. First, and foremost, the only place where Qt does not play nicely with smart pointers are QObject-inherited classes. This is true, but at the same time not a big deal as its parent-child ownership model has proven itself over the past twenty years. I'm not saying it's better than smart pointers, just that it's not much different. And furthermore, Qt is so much more than QObject inherited classes, and your own types in an application are also only QObjects if really necessary. All of the rest you can put into smart pointers if you want to, and Qt even offers it own fair share of smart pointers that are being used internally and externally (i.e. for C++98 projects). That said, there are a couple of places where smart use of smart pointers could improve Qt API. For example, a lot of I/O code takes a QIODevice*, but does not transfer ownership. Which means those classes often have a getter that gives you that QIODevice *. The problem is that there are other places that are QIODevice factories, like QNAM (QNetworkReply). Is there anything that would help people know when a pointer's ownership is transferred instead of just the documentation? Probably std::unique_ptr. -- 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] Qt LTS C++11 plans (CopperSpice)
On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote: There is always CopperSpice the Qt fork which uses C++11. They've got rid of moc and plan to replace Qt containers with std ones. Afterwards maybe they will add support for namespaces to their peppermill source convertor utility. I am one of the developers of CopperSpice and I would like to elaborate on our project. Our initial release of CopperSpice was in July 2014 with our target audience being our local C++ Users Group in the San Francisco Bay area. We wanted to explore the interest in CopperSpice and obtain feedback regarding the steps we took to remove moc. Our full presentation in February 2015 was well received and attended by several prominent people. I for one welcome your efforts. I think it's great that you're trying out new things on the shoulders of Qt. To me this feels healthy and I'm at this point not worried about fragmentation. Experimentation is something we should encourage, even if those experiments happen in deep core parts of the framework. I'm also glad to see that you're sharing your work with the rest of the development community on github. It would be great if some of your improvements, some of your innovations could - in the future - find their way back to Qt. It's not evident at this point how exactly, but I think it would be good to keep it in the back of our heads. That said, I did see the slides of your presentation in February 2015 and I am disappointed about the slide with the heading Why we developed CopperSpice. It says that one of the reasons was that Libraries not developed as a true open source project. This is disappointing for me to read. Thiago, Lars and others who have worked on the governance rules of Qt have done tremendous work to establish the true open source umbrella, especially by learning from other projects and taking the experience into account when formulating the contribution and governance guidelines. I hope that in future presentations of your project you are not going to give your audience the impression that Qt is not a true open source project. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Den 03-07-2015 kl. 07:09 skrev Ansel Sermersheim: On 7/2/15 2:23 PM, Milian Wolff wrote: On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. This answer is going to be one big IMHO. Anything that stops people from throwing shared pointers all over the code is A Good Thing. As someone once said: Shared pointers are a solution in search of a problem. Scoped pointers are fine, but shared pointers indicate a lack of handling of responsibility and ownership, which indicates bad design. For you to use this as a reason for forking Qt is a very bad indication. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Thursday 02 July 2015 22:09:13 Ansel Sermersheim wrote: Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. You have Microsoft to thank for that. Dropping something like 40% of our userbase is not worth constexprs. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. On the other hand, existing Qt programmers will feel right at home and their existing applications will continue to run. -- 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] Qt LTS C++11 plans (CopperSpice)
On Thursday, July 02, 2015 10:09:13 PM Ansel Sermersheim wrote: On 7/2/15 2:23 PM, Milian Wolff wrote: On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. What was your reasoning behind forking the archaic Qt 4 instead of a recent Qt 5 which already uses a ton of C++11? Esp. note how it does use constexpr when available for many value types, thanks to the hard work by Marc. Also, considering that you were not working on the internals of Qt (or did you?), I find your reasoning above highly amusing. Forking Qt just to use C+ +11 for its internal development won't give users of the framework any value (quite the contrary, as Thiago pointed out many times). Also, as it's a fork, it won't affect us Qt developers at all, as we will stick to the original. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. The above statement is far to broad to leave it uncommented. First, and foremost, the only place where Qt does not play nicely with smart pointers are QObject-inherited classes. This is true, but at the same time not a big deal as its parent-child ownership model has proven itself over the past twenty years. I'm not saying it's better than smart pointers, just that it's not much different. And furthermore, Qt is so much more than QObject inherited classes, and your own types in an application are also only QObjects if really necessary. All of the rest you can put into smart pointers if you want to, and Qt even offers it own fair share of smart pointers that are being used internally and externally (i.e. for C++98 projects). Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 7/2/15 2:00 PM, Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. This is exactly one of the major reasons that we started CopperSpice. When working with the Model/View framework there are many situations where one wants to use a templated model. It's possible to get the same end result with some creative use of multiple inheritance, but it is a very unpleasant hack. Given several comments we have seen, it sounds like this is not the direction Qt is going for many years if at all. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. Then you should have used Boost.Signals. Qt is not the only C++ library out there, and asking it to be everything for everyone is unreasonable. That said, in my experience, if you want signals on templates, you're usually going it wrong. You probably intend to use it far away from the GUI layout, maybe even in your cenral data model (!= QAbstractItemModel here). Overuse of signal-slots can make a program very hard to understand, and possibly also slow. If you don't believe, I invite you to study pre-Akonadi KMail code. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 7/2/15 2:23 PM, Milian Wolff wrote: On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. The problem in doing this is how to create the meta object so that runtime reflection works. Using the template parameter(s) inside the class leads to HUGE complexity. Think of something horribly complex: you're probably only two orders of magnitude away from the real complexity. One way of doing this would be to drop the meta object and the runtime reflection. That would also get rid of QtScript, QtQml, QtDBus, ActiveQt, QtWebKit's registering of QObjects, etc. It's a complete non-starter. Another way is to do it like CopperSpice is doing, by way of boilerplate macros and manual runtime registration, at the expense of making the code (subjectively) harder to read and of runtime cost. Qt's current[1] meta object system is *entirely* read-only, shared memory, except for the QMetaObject structure itself, which is read-only data with local relocations[2]. This is much beyond pure C++: we're investigating performance, code size, data size, relocation count, etc. [1] Current, because it wasn't so before Qt 4. So you see that this has 15 years of learnings applied. [2] Local relocations, as opposed to global relocations, are much faster to resolve, as they have no symbol name to be looked up. Also, local relocations disappear on position-dependent code, which we'll get back to allowing once GCC introduces the necessary options. PS: I've just got an idea for getting rid of the relocations on Linux/x86-64... I need to check if there's a way of doing it before Qt 6. -- 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] Qt LTS C++11 plans (CopperSpice)
For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien +1. I do that a lot: QObject = MyClass = MyTemplate = MyClassDerived --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
30.06.2015, 23:38, Bernhard priv...@bernhard-lindner.de: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! http://www.labri.fr/perso/guenneba/code/ppmoc.php No C++11 required (code was written in 2008 or earlier) -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit : For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 6/30/15 1:01 PM, Thiago Macieira wrote: On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. You need to use -fvisibility-inlines-hidden and retry. I don't think your solution works under those circumstances. As we mentioned we have already changed parts of the CopperSpice registration system. This will be released within the next month or so. We are definitely aware of -fvisibility-inlines-hidden, and we will look into supporting it. We are going to fully support exceptions, and make exception safety guarantees where possible. Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. Yes, many parts will need to be redone and we are starting with the container classes. These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. We do not feel that requiring a compiler to support C++11 is unreasonable. Our main issues with MSVC is with constexpr and expression SFINAE. MS has added partial support of constexpr for MSVC 2015, although they are still reported to have a few issues. They will get there eventually. No word yet on when expression SFINAE will be added. Yes, we make use of macros as macros were intended to be used. We strongly believe the syntax for our macros is concise and clean, and that this tradeoff is worthwhile. Ansel CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Wednesday 01 July 2015 00:49:19 Olivier Goffart wrote: On Tuesday 30. June 2015 22:37:24 Bernhard wrote: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can do that with moc. https://codereview.qt-project.org/49864/ There was a discussion about it on the mailinglist at the time, but nobody expressed much interest in having that feature. The feature is probably affected by the -fvisibility-inlines-hidden issue too. -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 19:40:55 Ansel Sermersheim wrote: Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. Yes, many parts will need to be redone and we are starting with the container classes. You may be underestimating the effort required. You'll need to spend a couple of man-decades of work to get this done... These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. We do not feel that requiring a compiler to support C++11 is unreasonable. Our main issues with MSVC is with constexpr and expression SFINAE. MS has added partial support of constexpr for MSVC 2015, although they are still reported to have a few issues. They will get there eventually. No word yet on when expression SFINAE will be added. And that's where we disagree. We feel that we have to be pragmatic and support compilers that people have access to. This is exactly why this thread started. I'm not saying you can't do what you're doing. I'm simply saying it's a trade- off. You're trading a potentially large userbase for the ability to use those C++11 features. Yes, we make use of macros as macros were intended to be used. We strongly believe the syntax for our macros is concise and clean, and that this tradeoff is worthwhile. No doubt you do. But I still disagree. My opinion is that a code generator is far preferable to boilerplate macros. -- 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] Qt LTS C++11 plans (CopperSpice)
On 6/29/15 11:37 PM, Alejandro Exojo wrote: El Tuesday 30 June 2015, Ansel Sermersheim escribió: Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Can you explain which are your long term plans? Given that you renamed all the classes and modules (or so I understood), this is full source incompatible, and it doesn't seem like you want to sync again with the original Qt (applications might include a large file full of typedefs, but applying to CopperSpice any bugfix patch found in Qt seems completely manual). Some developers experiment with their own branches to research or have fun, which is great, but seems like you are aiming to be a full new project. We renamed the libraries to avoid naming conflicts with the Qt libraries when CS and Qt are installed on the same system. We have not renamed the classes, and our intention is to keep source compatibility as much as possible. Some incompatible changes were unavoidable, particularly the signal / slot declaration syntax. Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. We would like to support multiple inheritance properly. We would like the CsGui classes to work seamlessly with STL containers, and to add things like reverse iterators to the CS container library to bring it in line with the STL. We are going to fully support exceptions, and make exception safety guarantees where possible. We are working on redesigning the QObject lifetime model so that it works smoothly with C++11 smart pointers. These are some of the limitations that frustrated us when using Qt in an existing codebase. Thank you very much for your question, Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! -- Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. You need to use -fvisibility-inlines-hidden and retry. I don't think your solution works under those circumstances. We are going to fully support exceptions, and make exception safety guarantees where possible. Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. We are working on redesigning the QObject lifetime model so that it works smoothly with C++11 smart pointers. I researched that 4 or 5 years ago and I found two problems: First, you must either choose to use smart pointers everywhere or not at all. You can't pick and choose, which is what caused most of the problems. Second, and most importantly, all the QWidget-derived classes share state with their parent widgets. You MUST delete the children when the parent is getting deleted, which is incompatible with smart pointers. Like I said above for exceptions, you'll need to redesign the entire stack to get support for smart pointers here. These are some of the limitations that frustrated us when using Qt in an existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. And, critically, like I mentioned above, is that I don't think your solution works with -fvisibility-inlines-hidden, due to taking and comparing addresses of inline functions. -- 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] Qt LTS C++11 plans (CopperSpice)
On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. Visual Studio 2015 will have constexpr fixed [1] and it should compile CopperSpice. The replacement of qmake with autotools in CopperSpice makes things very hard to test with Visual Studio. It seems CMake is being under evaluation [2]. The combination of CMake and ninja is quite effective. Cheers, Cristian. [1] http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx [2] http://forum.copperspice.com/viewtopic.php?f=10t=7 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 6/29/15 10:59 PM, Thiago Macieira wrote: On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. Out of curiosity: You've removed moc, but what's your replacement for rcc? I hope I understand your question correctly. By removing moc and not using qmake, we were able to remove all the bootstrap code from CsCore. This allowed us to build rcc simply linking with CsCore. We did not see any reason to replace rcc at this time. Our goal was to allow developers to use CopperSpice without altering their build systems. Since the resource system is not mandatory we did not feel like an alternative to rcc was required. We would like to encourage developers to attend CPPCon to learn about Maybe Meeting C++ will get better luck. Most of the Qt developers live in Europe. I encourage you to submit your session there. By the way, you're also welcome to discuss your ideas in this mailing list. We're not against new C++ techniques, but we want to support existing deployments, so we have to be a little more pragmatic on our choices. Thank you for your warm welcome and encouragement. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. Out of curiosity: You've removed moc, but what's your replacement for rcc? We would like to encourage developers to attend CPPCon to learn about Maybe Meeting C++ will get better luck. Most of the Qt developers live in Europe. I encourage you to submit your session there. By the way, you're also welcome to discuss your ideas in this mailing list. We're not against new C++ techniques, but we want to support existing deployments, so we have to be a little more pragmatic on our choices. -- 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] Qt LTS C++11 plans (CopperSpice)
El Tuesday 30 June 2015, Ansel Sermersheim escribió: Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Can you explain which are your long term plans? Given that you renamed all the classes and modules (or so I understood), this is full source incompatible, and it doesn't seem like you want to sync again with the original Qt (applications might include a large file full of typedefs, but applying to CopperSpice any bugfix patch found in Qt seems completely manual). Some developers experiment with their own branches to research or have fun, which is great, but seems like you are aiming to be a full new project. -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote: On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com wrote: You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. Visual Studio 2015 will have constexpr fixed [1] and it should compile CopperSpice. It's still not working in MSVC 2015 RC1. I'd be wary of relying on RTM fixing it if it's still not fixed yet. The replacement of qmake with autotools in CopperSpice makes things very hard to test with Visual Studio. It seems CMake is being under evaluation [2]. The combination of CMake and ninja is quite effective. Autotools is backwards direction. Everyone moves *away* from Autotools, not towards it (except people who had no buildsystem in the first place). -- 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] Qt LTS C++11 plans (CopperSpice)
On Tuesday 30. June 2015 22:37:24 Bernhard wrote: For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! You can do that with moc. https://codereview.qt-project.org/49864/ There was a discussion about it on the mailinglist at the time, but nobody expressed much interest in having that feature. -- 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] Qt LTS C++11 plans (CopperSpice)
There is always CopperSpice the Qt fork which uses C++11. They've got rid of moc and plan to replace Qt containers with std ones. Afterwards maybe they will add support for namespaces to their peppermill source convertor utility. I am one of the developers of CopperSpice and I would like to elaborate on our project. Our initial release of CopperSpice was in July 2014 with our target audience being our local C++ Users Group in the San Francisco Bay area. We wanted to explore the interest in CopperSpice and obtain feedback regarding the steps we took to remove moc. Our full presentation in February 2015 was well received and attended by several prominent people. Our intent was to formally announce CopperSpice at CPPCon in September. Oddly, once we submitted a proposal for speaking at CPPCon, someone in Europe decided to post information about CopperSpice on reddit. As of today I can announce we have been approved to speak about CopperSpice at CPPCon. The current version of CopperSpice supports the full Qt Metaobject System, requires C++11, and includes CsCore, CsGui, CsPhonon, as well as CsScript, and CsWebkit. We have CsDBus partially ported, however more time has been spent on other libraries. It will be available in our September release. I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. As a consequence of our presentation in February we have modified parts of the internal registration code to better implement reflection. We will be making a few more changes before this is released. Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Our thanks go out to Trolltech, Nokia, and Digia for all the work they have done. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
