Re: [Development] Would it make sense to make QObject moveable in Qt 6?
On 08/25/2016 02:48 AM, Marc Mutz wrote: On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: `QObject` is already pretty much a handle to the underlying data due to pimpl. So that’s a good first step. I challenge the notion that QObject is a handle to date. QObject is first and foremost the base class of a polymorphic class hierarchy. If you wrap that in a parallel value-like-but-not-quite class hierarchy, you end up with QDomNode. I don't like QDomNode. Do you like QDomNode? That said, the Copperspice guys argue that the implicit memory management of QObject parent-child relationships is becoming alien for C++ developers. The Qt community can of course deny every claim that comes from that direction, but sometimes the look of an outsider is valuable, too. After all, the API quality matters most for newbies, not decade-long Qt users. I would like to confirm your observation about our direction for CopperSpice is accurate. It is our goal to modify QObject so users can leverage shared pointers to manage the lifetime of QObjects. One of the ways we moved this forward is by refactoring QObject. We developed a completely new standalone signal/slot library which is independent of CopperSpice and can be used in any C++ project. CopperSpice was then modified to use the new CsSignal library. During this refactoring we were able to improve the maintainability of QObject by separating some of the functionality. As an off topic comment I wanted to briefly mention why the key developers of CopperSpice scaled back work over the past two months. Barbara had a total knee replacement and she is recovering nicely, but physical therapy has been her main focus. I am looking forward to her full return to the office and continued work on CopperSpice and DoxyPress. Ansel Sermersheim CopperSpice Cofounder ___ 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)
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)
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)
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 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 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 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 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 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)
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)
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
