[Development] HEADS-UP: Branching from 'dev' to '5.14' started
Hi all, '5.14' is soft branched from 'dev' now. Final downmerge from 'dev' to '5.14', Qt 5.14 Feature Freeze ( and most probably also branching '5.15' from '5.14' [1]) will happen Monday 26th August. So start using '5.14' for new changes targeted to Qt 5.14 release. And please fill Qt 5.14. new features in new features page (https://wiki.qt.io/New_Features_in_Qt_5.14) br, Jani Heikkinen Release Manager [1] https://lists.qt-project.org/pipermail/development/2019-August/037109.html ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
Jason H wrote: > I also have to point out that there was a statement made by Lars to make > QML [more] strongly typed. I had expected that from the beginning, that > Python would be the scripting language of QML, not Javascript[0], I don't see how Python is inherently more strongly typed than JavaScript. Python variables are untyped, method calls are duck-typed and hence work with any type that happens to implement the called method. The variable contents at a specific point in time are typed at runtime, but that is not strong typing. Any type mismatches are only caught when you actually run the code, just as in JavaScript. And the type of a variable can also change each time it is reassigned, just as in JavaScript. Python now has the typing module which allows you to set type hints, but they are not directly part of the language and in particular not enforced by default. (You have to actually run some static type checker explicitly to validate them.) The module is also provisional, which means that the API is subject to change. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updating holdover API from Qt 1 times
Sze Howe Koh wrote: > 3) Pick one of the options above, but go one step further and use > std::optional (C++17) instead of returning null objects. I imagine this > should apply more broadly to the whole of Qt, not just the functions > discussed here. IMHO, std::optional conceptually makes sense only for types that are not able to natively represent a null state. This is not the case for implicitly-shared data objects, which have a natural native null state (where the shared d pointer is null). So std::optional is redundant and introduces an unwanted distinction between a null optional and a null object. And it also means that at least a boolean flag is unnecessarily added somewhere in memory. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updating holdover API from Qt 1 times
On Sun, 18 Aug 2019 at 07:37, Mutz, Marc wrote: > > On 2019-08-17 07:13, Sze Howe Koh wrote: > [...] > > Which should we implement? I personally prefer (2) as it it can be > > added to Qt 5.x and provides backward compatibility while keeping the > > nice compact function names. We could enable QT_NO_COW by default in > > Qt 6.5 LTS and then remove the old function and Qt::ReturnByValue_t in > > Qt 7.0. > > > > I'm not sure I like the verbosity or SiC-ness of std::optional, hence > > I'm asking for thoughts here. > [...] > > Which one is more SiC? > > old: > > QPixmap *pm = label->pixmap(); > if (pm) > use(*pm); > > with (2): > > QPixmap pm = label->-pixmap(); > if (!pm.isNull()) > use(pm); > > with optional<>: > > std::optional pm = label->pixmap(); > if (pm) > use(*pm); > > old, using auto: > > auto pm = label->pixmap(); > if (pm) > use(*pm); > > (2), using auto: > > auto pm = label->pixmap(); > if (!pm.isNull()) > use(pm); > > optional<>, with auto: > > auto pm = label->pixmap(); > if (pm) > use(*pm); > > To me, that looks like optional<> with auto is SC while (2) is SiC with > or without auto. > > Seeing as auto will also have to be the solution for code that wants to > stay compatible between Qt 5 and 6 when it comes with QList, I don't > think anything but optional<> passes muster. I agree that (3) indeed allows these functions to work under Qt 5 and Qt 6 simultaneously. But so does (1) and (2): * (1) lets users opt-in to the deprecated functions. * (2) lets users #undef QT_NO_COW_POINTERS. Note that the options have very different goals: (1) and (2) aim to eliminate an existing inconsistency in the Qt API, while (3) turns the inconsistency into an opportunity to introduce a new language feature into the Qt API. Personally, I'm more interested in the former goal. I can see the value in the latter goal but I can't see a good way to achieve it. As I said in my previous email, we shouldn't just apply (3) to QLabel::pixmap() and QLabel::picture() and call it a day. IMHO, we should only implement (3) if we are prepared convert most (all?) other functions in Qt that return value objects, like QAbstractButton::icon(). And I can't see how we are prepared to do so, because it involves SiC changes throughout the entire Qt code base. > Thanks, > Marc Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
On Monday, 19 August 2019 12:34:23 PDT Jason H wrote: > > > Can Qt set a "no private destructor!" rule? > > > > No. > > > > Private destructors have a purpose. > > Would a workable re-wording be "always provide a public means of > destruction"? No, since the purpose is to prevent you from doing that. That's usually a singleton, though not always. > To be clear, I am not sure what the actual issue is, why it's private, or > why shiboken can't handle it. In the immediate case PyQt provides the class > so there seems to be some way around the issue... From knowledge of past code generators, they try to derive from every class, so any class that is final or has only private constructors or has a private destructor will fail. It needs a different strategy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt PDF as a new TP module for Qt 5.14
Dear all, I implemented PDF rendering in Qt application. My opinion is that Poppler is not the best piece of open source code, look the code in comparison to MuPDF, it is C but clean C and run on embedded devices. Rather Poppler is more like a pile-up of crappy codes. Some years ago, somebody complained that Poppler doesn't use the same rendering engine on Gnome and KDE ... And Okular is nearly unable to print a document, try to print a 10 cm square on a printer or to do complex printing, personally I would prefer to boot Windows and use Acroread instead. However I don't have experience with PDFium. Cheers, Fabrice Le 12/08/2019 à 17:16, Thiago Macieira a écrit : On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote: I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech Preview state, and Shawn Rutledge is volunteering to be the maintainer. Although still staying an independent library from the user's perspective, it will be hosted and built in the qtwebengine.git repository. Initially only the desktop platforms (Windows, Linux, macOS) would be supported. Qt PDF is so far a Qt labs module [1]. It allows Qt applications to render/view PDF's in QWidget based applications [2], and is built on top of PDFium. However, development has been stagnant, also because it is built on top of a rather old version of PDFium. Has any analysis been done comparing the feature and platform support, and codebase size, for PDFium versus Poppler? Or is the big problem that the library we need to use (poppler-qt) depend on Qt itself? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
Dear all, I am using PyQt since 10 years now and my points are: - It is true that missing bindings is a serious issue to use PySide actually. - I noticed PyQt has simpler wrapper code, but I don't investigated more. - I would dream to have Python instead of JS, but we know how to implement a good JS virtual machine, for Python who really knows ??? - I experimented complex issues and I don't know how to debug them : we need a good debugging tool to figure out what happen in threads signal/slot ... - A good tutorial : how to wrap your custom C++ classes ( maybe there is one ??? ) - I think that something like a white paper " how to make a reactive Python/Qt application " would help people to understand GIL issue and how to deal with it. Because we can make serious applications using Python/Qt and competitive with Electron. - support async and pypy - A referential of applications that just works ( I could provide https://github.com/FabriceSalvaire/book-browser ) Cheers Le 19/08/2019 à 14:39, Cristián Maureira-Fredes a écrit : Hello, After the general discussion of the vision for Qt6, we wanted to say a few things regarding Qt for Python. Even though we are talking about a Python module, the whole development is C and C++ related, and due to Python's popularity, we have been getting a lot of attention on Shiboken, the binding generator that we use to expose our beloved C++ framework to Python. That's why I felt motivated to write to the main qt mailing list. A couple of people here has provided us with really nice feedback regarding the module, and even related to the integration with QtCreator. We are really thankful for that. Since the beginning of the project we have seen it as a complementary project, and never as a competition to the long-standing performant C++ counterpart, but most importantly as a really nice way to extend the Qt project community with a whole new set of users. As you will read on the blog post, there are a couple of aspects from the C++ point of view that are really useful, like fast prototyping, exposing existing C++ projects to Python, or even extend Qt/C++ application with Python. It will be really nice to know what do you think, because at the moment we have been mostly community driven, and many aspects from the C++ expertise on this mailing list will help us improving Qt for Python. https://blog.qt.io/blog/2019/08/19/technical-vision-qt-python/ Cheers ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
> > Can Qt set a "no private destructor!" rule? > > No. > > Private destructors have a purpose. Would a workable re-wording be "always provide a public means of destruction"? To be clear, I am not sure what the actual issue is, why it's private, or why shiboken can't handle it. In the immediate case PyQt provides the class so there seems to be some way around the issue... ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dev branch moving towards Qt 6
In response to >> To reflect that and help us all understand that the development focus >> is now towards Qt 6, I would like to propose that dev becomes the Qt >> 6 branch after we branched away 5.14 Friedemann Kleint (19 August 2019 13:57) asked: > How long do we keep merging 5.14->dev? At what point do we go into > cherry-pick mode for 5.14->dev? This should probably be done after > 5.14 API review and initial testing at the earliest? Well, if we follow recent practice (without treating the major version change specially), I suppose we keep merging up from 5.14 through 5.15 (once it exists) to dev. The release of 5.14 signals the demise of the 5.13 branch, at which point 5.12 is disconnected and goes into cherry-pick mode. Later, the release of 5.15 shall close 5.14; if we still don't treat the major version change specially, we'd continue merging 5.15 up through 6.* after the release of 6.0 but switch 5.15 to cherry-pick mode when 6.0 closes, probably when 6.1 releases. See also https://quips-qt-io.herokuapp.com/quip-0005.html So I guess the real question is: at what point do we start treating the major version change specially, in our merge / cherry-pick process ? Albeit I believe some would also like to consider changing that process in any case, e.g. to an "always dev" model, with cherry-picking back to the branches that need it. This is apparently common in other communities, giving it the benefit of familiarity for many potential contributors, to add to its (at least superficial) simplicity. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
On Monday, 19 August 2019 08:55:45 PDT Jason H wrote: > Can Qt set a "no private destructor!" rule? No. Private destructors have a purpose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Technical vision for Qt for Python
Thanks Cristián! If you thought I was suggesting it was done, I was not. I was just stating the facts as they appear at the current time feedback is being given. :-) I am encouraged at PySide continuing development! I hope that the private destructor issue is avoided for all future classes. I don't know how Qt can enforce that though, but Qt6 provides a great opportunity to make the API change. Can Qt set a "no private destructor!" rule? About the event loop, 1 official solution is preferred over 2 contrib solutions. ;-) Just like with my choosing to use PySide then finding classes I needed were not supported, I will always chose wrong the first time! LOL. The Jupyter notebook suggestion really is a minor issue AFAIAC, it's where Qt could really shine and pick up some users. (Interactive Qt+Jupyter notebooks? Amazing!) But it in no way factors into my day-to-day. When those dev changes land in a release I'll take a look again, or if I get something that doesn't require them, I'll see about giving it a go. The only remaining concerns I have are about QtCreator's integration. The .pyproject format is extremely limited. Proper python project packaging, FTW. (Say that 4 times fast!) I have python purists that I work with that I have to appease (and they use the asyncio event loop too!) In my day-to-day I don't really care that it is in C++. But I care that I can do what I set out to do. That's my benchmark. That's got me in C++. But I'm also eagerly awaiting for the time I can interop with my python coworkers! > Sent: Monday, August 19, 2019 at 10:36 AM > From: "Cristián Maureira-Fredes" > To: "development@qt-project.org" > Subject: Re: [Development] Technical vision for Qt for Python > > Hello Jason, > > I will comment inline. > > On 8/19/19 3:52 PM, Jason H wrote: > > I tried PySide 2, and was extremely disappointed that not all the classes > > are supported. What's worse it PyQt supports the classes that are not > > supported. Having that kind of errata is devastating to the confidence in a > > project. Qt6/PySide6 must have parity from day 1. > > This is true, we still have missing bindings, > but you skipped the good part of the issue you had: > > - You reported a couple of missing classes, > - We verify that's specific case, and we discover it was due to Private > destructor not supported by our binding generator. > - This led to start fixing this issues on the Qt Multimedia module, > that ended app on PYSIDE-1041 being related to QTBUG-74422 which was > merged on dev > > So we are truly addressing all the concerns by our users. > > > Concerning the missing bindings, we have been publicly listing them > all, and even comparing them with PyQt5: > https://wiki.qt.io/Qt_for_Python_Missing_Bindings > > There are many things that make little sense in Python land, > and other classes from which we don't have a use-case, or we are not > aware of how critical for a project could be. > > That's why we need your feedback. > > > Next, the biggest flaw is lack of Python 3 native event loop integration. A > > lot of people have codebases Python 3 event loops now, PySide should be > > seamless from day 1. > > It would be really nice to have a proper integration, > but this is a difficult implementation, and not even PyQt5 has it > natively, that's why at the moment we have an open task from which > you can find two external plugins so interact with the Python event > loop, asyncqt, and quamash: https://bugreports.qt.io/browse/PYSIDE-769 > > > > I also have to point out that there was a statement made by Lars to make > > QML [more] strongly typed. I had expected that from the beginning, that > > Python would be the scripting language of QML, not Javascript[0], just for > > this reason. Instead, V4 was developed... I would probably execute Qt6 QML > > as Python code, not Javascript. I've repeatedly called for QML to be a web > > framework, and I've routinely had that idea shot down. So why involve a web > > language at all[1][2]? Coincidentally, you will also get that AI stuff Lars > > also talked about, for free (on the Python side anyway) > > I tend to think that technologies should coexist better, > rather than choosing one or another, and since there are so many > things being improve in the QML side, I would expect to see the > goodies from Qt6 first to analyze how we could improve the experience > using Python. > We are always open to people trying new things, > maybe somehow has some ideas of adding Python to the scene, > or even improve the current PySide2/QML interaction. > > > Jupiter concerns me. I'm wondering how well we can get Qt to integrate with > > Jupiter notebooks? Can we get interactive Qt in the notebook? (WASM?) > I got contacted by Jupyter developers, because there is a lot of > interest to better integrate Qt in their notebooks, but of course, > this is not a straightforward task. > We would love to see how things can change in future
Re: [Development] Technical vision for Qt for Python
Hello Jason, I will comment inline. On 8/19/19 3:52 PM, Jason H wrote: > I tried PySide 2, and was extremely disappointed that not all the classes are > supported. What's worse it PyQt supports the classes that are not supported. > Having that kind of errata is devastating to the confidence in a project. > Qt6/PySide6 must have parity from day 1. This is true, we still have missing bindings, but you skipped the good part of the issue you had: - You reported a couple of missing classes, - We verify that's specific case, and we discover it was due to Private destructor not supported by our binding generator. - This led to start fixing this issues on the Qt Multimedia module, that ended app on PYSIDE-1041 being related to QTBUG-74422 which was merged on dev So we are truly addressing all the concerns by our users. Concerning the missing bindings, we have been publicly listing them all, and even comparing them with PyQt5: https://wiki.qt.io/Qt_for_Python_Missing_Bindings There are many things that make little sense in Python land, and other classes from which we don't have a use-case, or we are not aware of how critical for a project could be. That's why we need your feedback. > Next, the biggest flaw is lack of Python 3 native event loop integration. A > lot of people have codebases Python 3 event loops now, PySide should be > seamless from day 1. It would be really nice to have a proper integration, but this is a difficult implementation, and not even PyQt5 has it natively, that's why at the moment we have an open task from which you can find two external plugins so interact with the Python event loop, asyncqt, and quamash: https://bugreports.qt.io/browse/PYSIDE-769 > I also have to point out that there was a statement made by Lars to make QML > [more] strongly typed. I had expected that from the beginning, that Python > would be the scripting language of QML, not Javascript[0], just for this > reason. Instead, V4 was developed... I would probably execute Qt6 QML as > Python code, not Javascript. I've repeatedly called for QML to be a web > framework, and I've routinely had that idea shot down. So why involve a web > language at all[1][2]? Coincidentally, you will also get that AI stuff Lars > also talked about, for free (on the Python side anyway) I tend to think that technologies should coexist better, rather than choosing one or another, and since there are so many things being improve in the QML side, I would expect to see the goodies from Qt6 first to analyze how we could improve the experience using Python. We are always open to people trying new things, maybe somehow has some ideas of adding Python to the scene, or even improve the current PySide2/QML interaction. > Jupiter concerns me. I'm wondering how well we can get Qt to integrate with > Jupiter notebooks? Can we get interactive Qt in the notebook? (WASM?) I got contacted by Jupyter developers, because there is a lot of interest to better integrate Qt in their notebooks, but of course, this is not a straightforward task. We would love to see how things can change in future releases. > Finally, I've used PyQt off and on since Qt 3.3 days. I really like Python as > a language to use Qt in a rapid prototype development way, but the > limitations stated above prevent it from being my default environment. Since both statements have workarounds and future solutions, we are looking forward to hear what else is missing and stopping you to use the module. Thanks for your comments, Cheers > (snip) > > > >> Sent: Monday, August 19, 2019 at 8:39 AM >> From: "Cristián Maureira-Fredes" >> To: "development@qt-project.org" >> Subject: [Development] Technical vision for Qt for Python > ... >> It will be really nice to know what do you think, >> because at the moment we have been mostly community driven, >> and many aspects from the C++ expertise on this mailing list >> will help us improving Qt for Python. >> >> https://blog.qt.io/blog/2019/08/19/technical-vision-qt-python/ >> > -- Dr. Cristian Maureira-Fredes Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Technical vision for Qt for Python
Hello, After the general discussion of the vision for Qt6, we wanted to say a few things regarding Qt for Python. Even though we are talking about a Python module, the whole development is C and C++ related, and due to Python's popularity, we have been getting a lot of attention on Shiboken, the binding generator that we use to expose our beloved C++ framework to Python. That's why I felt motivated to write to the main qt mailing list. A couple of people here has provided us with really nice feedback regarding the module, and even related to the integration with QtCreator. We are really thankful for that. Since the beginning of the project we have seen it as a complementary project, and never as a competition to the long-standing performant C++ counterpart, but most importantly as a really nice way to extend the Qt project community with a whole new set of users. As you will read on the blog post, there are a couple of aspects from the C++ point of view that are really useful, like fast prototyping, exposing existing C++ projects to Python, or even extend Qt/C++ application with Python. It will be really nice to know what do you think, because at the moment we have been mostly community driven, and many aspects from the C++ expertise on this mailing list will help us improving Qt for Python. https://blog.qt.io/blog/2019/08/19/technical-vision-qt-python/ Cheers -- Dr. Cristian Maureira-Fredes Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dev branch moving towards Qt 6
Hi, >To reflect that and help us all understand that the development focus is now towards Qt 6, I would like to propose that dev becomes the > Qt 6 branch after we branched away 5.14 How long do we keep merging 5.14->dev? At what point do we go into cherry-pick mode for 5.14->dev? This should probably be done after 5.14 API review and initial testing at the earliest? Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] NTLM Issue with Qt-5.12 LTS
On 19 Aug 2019, at 11:41, coroberti . mailto:corobe...@gmail.com>> wrote: Hi, Could be this issue be given a priority since it's a regression and strikes deployments of Qt-5.12 LTS on Windows? https://bugreports.qt.io/browse/QTBUG-44096 Thanks in advance! Kind regards, Robert Iakobashvili Hey Robert (and others), could you help with verifying the proposed fix in https://codereview.qt-project.org/c/qt/qtbase/+/265900 FWIW, from the report it doesn’t seem to be regression within Qt 5; the report is originally against Qt 5.4, at least. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] NTLM Issue with Qt-5.12 LTS
Hi, Could be this issue be given a priority since it's a regression and strikes deployments of Qt-5.12 LTS on Windows? https://bugreports.qt.io/browse/QTBUG-44096 Thanks in advance! Kind regards, Robert Iakobashvili ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Heads up: QWeakPointer re-education
Il 16/08/19 11:02, Mutz, Marc via Development ha scritto: It seems that the presence of QWeakPointer::data() in the past has given many Qt developers the wrong impression and they're now fighting hard to keep that impression intact when porting away from deprecated data(). Many thanks for dealing with the fallout of this deprecation! Indeed, the important message here is that QWeakPointer is not supposed to be treated like a raw pointer; std::weak_ptr is lacking data()/get() for the same reason, although implementing it costs nothing. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] HEADS-UP: Branching from '5.12' to '5.12.5' started
Hi, We have soft branched '5.12.5' from '5.12' today. All new changes targeted to Qt 5.12.5 release should be done in '5.12.5'. Final downmerge from '5.12' to '5.12.5' will happen this Friday (23th August) so there should be enough time to finalize ongoing changes in '5.12' Target is to release Qt 5.12.5 at the end of August. Release blocker list here: https://bugreports.qt.io/issues/?filter=21420 br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CI is in maintenance break
Hi, CI is up and running again. Br Heikki From: Heikki Halmet Sent: maanantai 19. elokuuta 2019 8.43 To: development@qt-project.org; Qt Development Subject: CI is in maintenance break Hi, CI is in maintenance break and will be down approximately 1 hour. We are redeploying our hosts. Ystävällisin terveisin / Kind regards, Heikki Halmet Software Engineer | CI Lead Release and Test Automation | CI Team The Qt Company | Finland | Oulu ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
