[Development] QUIP Index is not showing up at contribute.qt-project.org
These pages are blank: * https://contribute.qt-project.org/quips/ * https://contribute.qt-project.org/quips/0 In contrast, these pages show the (now-outdated) index: * http://quips-qt-io.herokuapp.com/ * http://quips-qt-io.herokuapp.com/quip-.html Regards, Sze-Howe -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Change needs review: https://codereview.qt-project.org/c/qt/qtbase/+/476336
+1'ed Regards, Sze-Howe On Mon, Jun 12, 2023, 06:48 Thiago Macieira wrote: > This change was last updated on May 12. It's a simple change to a unit > test, > but I haven't got a vote yet. > > Someone please give any thumbs up or now. I can't maintainer-approve > without > net positive votes and I feel this is worth having so I don't really want > to > abandon it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Cloud Software Architect - Intel DCAI Cloud Engineering > -- > -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Orphaned Gerrit patchset
This one has been stuck in "Integrating" state for over a year: https://codereview.qt-project.org/c/qt/qt5/+/328630 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers
On Mon, 26 Sept 2022 at 15:13, Volker Hilsheimer wrote: > > Hi, > > > I would like to nominate Christian and Andy as co-maintainers for Qt SQL. > > Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t > responded to any of my emails, including one from two weeks ago where I > explicitly informed him that he will be removed as maintainer if he doesn’t > respond (as per the recent addition to the governance model [1], I cc’ed Alex > Blasche as a second maintainer in that email). > > Christian and Andy have already agreed to take on the responsibility > together. they both have a long history of working with the module, and as we > support a number of SQL drivers in Qt it’s good to have more than one person > looking after things. > > > Volker > > [1] https://codereview.qt-project.org/c/meta/quips/+/423766 +1 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Jira tickets for Qt Print Support (Was: Volunteer wanted: update use of CUPS API)
On Thu, 5 May 2022 at 16:41, Tor Arne Vestbø wrote: > > > On 5 May 2022, at 10:32, Alex Blasche wrote: > > > > > -Original Message- > > > From: Development On Behalf Of Sze > > > Howe Koh > > > On Mon, 4 May 2020 at 15:19, Lars Knoll wrote: > > > > > > > > > On 4 May 2020, at 09:08, Albert Astals Cid via Development > > > wrote: > > > > > > > > > > P.S: Someone should really really remove John Layt as printinting > > > > > mantainer stuff, i don't think he's been around for years. > > > > > > > > Agreed. I’ll remove him. > > > > > > > > Cheers, > > > > Lars > > > > > > All of the printing-related tickets still get auto-assigned to John. > > > There are lots of recently-opened ones: > > > > The much more difficult question is who the new default assignee is. Was > > this anywhere mentioned? > > > > Otherwise, it makes no difference whether John is the auto assignee or > > not. > > If there is no maintainer then the default assignee should be > “Unassigned”. Although that might not make any difference in practice of > fixing those issue, it does make a difference in being honest about the > situation. > > Cheers, > Tor Arne Changing the default of Qt Print Support to "Unassigned" sounds reasonable in this case. How does this occur? Also, Qt 3D tickets are auto-assigned to Sean Harmer who hasn't been active in ~1.5 years [1]. Mike Krus has been manually taking recent tickets [2] and has privately expressed willingness to take Sean's place -- I'd like to nominate Mike as default assignee for Qt 3D. As far as I'm aware, the formal procedure for this and the eligibility criteria are not specified in any QUIP -- does it make sense to add Jira default assignees to QUIP 2? Regards, Sze-Howe [1] https://codereview.qt-project.org/q/owner:sean.harmer%2540kdab.com [2] https://bugreports.qt.io/secure/ViewProfile.jspa?name=mkrus [3] http://quips-qt-io.herokuapp.com/quip-0002.html ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Jira tickets for Qt Print Support (Was: Volunteer wanted: update use of CUPS API)
On Mon, 4 May 2020 at 15:19, Lars Knoll wrote: > > > On 4 May 2020, at 09:08, Albert Astals Cid via Development > > wrote: > > > > P.S: Someone should really really remove John Layt as printinting mantainer > > stuff, i don't think he's been around for years. > > Agreed. I’ll remove him. > > Cheers, > Lars All of the printing-related tickets still get auto-assigned to John. There are lots of recently-opened ones: https://bugreports.qt.io/browse/QTBUG-101740?jql=project%20%3D%20QTBUG%20AND%20status%20in%20(Reported%2C%20Open)%20AND%20assignee%20in%20(johnlayt) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Android Extras "stopgap"
A blog post [1] and the current doc snapshot [2] both say, "Clients that still rely on missing functionality can include the private header as a stopgap solution." However, I just installed Qt 6.2.0 RC for Android and can't find qtandroidextras_p.h anywhere. Are the blog and snapshot accurate? Regards, Sze-Howe [1] https://www.qt.io/blog/qt-extras-modules-in-qt-6 [2] https://doc-snapshots.qt.io/qt6-6.2/extras-changes-qt6.html#changes-to-qt-android-extras ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should null QPixmaps be allowed in a QCoreApplication?
On Tue, 31 Aug 2021 at 19:22, Eirik Aavitsland wrote: > > On 7/27/21 6:41 PM, Sze Howe Koh wrote: > > Current Qt behaviours: > > > > A) If you create any QPixmap after creating QGuiApplication, the result > > is probably the pixmap that you asked for. All is well. > > B) If you create any QPixmap after creating QCoreApplication, the result > > is a null QPixmap. No warnings are produced. > > C) If you create any QPixmap _in a secondary thread_ after creating > > QCoreApplication, the result is a segfault due to a nullptr dereference [1]. > > D) If you create any QPixmap without creating Q(Core|Gui|)Application, > > the result is a qFatal() telling you that you must have a QGuiApplication. > > > > The description of B) is not quite correct I think. The actual behaviour > is that, if you have a QCoreApplication, then > B1) If you create a QPixmap through QPixmap::fromImage(), either > directly or indirectly via QVariant or reading from QDataStream, you get > a runtime warning and a null QPixmap. > B2) If you create a QPixmap any other way, you get a qFatal() with a > message, i.e. same as D). Ah, OK. I only constructed null pixmaps in my test (calling the QPixmap constructor with no arguments) and there was no runtime warning. So really, it's B1) If you create a QPixmap through QPixmap::fromImage()... you get a runtime warning and a null QPixmap. B2) If you create a _non-null_ QPixmap any other way, you get a qFatal() with a message B3) If you create a null QPixmap, you get no warnings and have nothing to worry about. > Now the logs indicate that the exception for the B1 situation is there > to let headless, QCoreApplication-based apps handle QDataStreams that > may contain QPixmaps without crashing. DBus is mentioned as a case. This > is the reason there is an autotest that explicitly ensures this > behaviour. It was clearly done intentionally. > > What is anyway clear is that behaviour C) is not intended and is a bug. > So C) can and should be fixed; to behave the same as B), I think. > > - Eirik Aa. If it's as designed, then I'm happy to leave it (and happy to avoid breaking any user code!) So to clarify: The answer to my original question is "Yes, null QPixmaps are allowed in a QCoreApplication"? In that case, isn't the qFatal() unnecessary in qt_pixmap_thread_test()? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Should null QPixmaps be allowed in a QCoreApplication?
Current Qt behaviours: A) If you create any QPixmap after creating QGuiApplication, the result is probably the pixmap that you asked for. All is well. B) If you create any QPixmap after creating QCoreApplication, the result is a null QPixmap. No warnings are produced. C) If you create any QPixmap _in a secondary thread_ after creating QCoreApplication, the result is a segfault due to a nullptr dereference [1]. D) If you create any QPixmap without creating Q(Core|Gui|)Application, the result is a qFatal() telling you that you must have a QGuiApplication. I think that results of (B) and (C) should be changed to match (D) [2]. However, there are some complications: * There is a unit test that relies on the current behaviour of (B) [3]. * Making this change will break existing user code that relies on the current behaviour of (B). How should we proceed? Regards, Sze-Howe [1] https://bugreports.qt.io/browse/QTBUG-95358 [2] https://codereview.qt-project.org/c/qt/qtbase/+/3618911 [3] https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/serialization/qdatastream_core_pixmap/tst_qdatastream_core_pixmap.cpp ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Merging qtquickcontrols2 into qtdeclarative
On Tue, 13 Jul 2021 at 21:38, Michal Klocek wrote:
>
> Hi
>
> Please note qtpdf repository was merged into qtwebengine, authors wanted to
> keep all the history so it was kept and git blame works nicely. However,
> qtwebengine git repo is anyway big in size so adding extra ~100 commits did
> not have much impact.
>
> https://codereview.qt-project.org/c/qt/qtwebengine/+/270649
>
> Br
>
> Michal
>
> From: Development on behalf of Elvis
> Stansvik
> Sent: Tuesday, 13 July 2021 13:23
> To: Qt development mailing list
> Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative
>
> Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
> :
> >
> > >On 12 Jul 2021, at 21:19, Thiago Macieira
> > >wrote:
> > >> So a full history import MAY have negligible marginal impact over a
> > >> squashed import (.git is compressed).
> > >
> > that might be the case.
> >
> > but the point remains that the history that didn't exist along the
> > merged mainline would live elsewhere (unless we'd import all branches
> > and tags as well - we actually did that in qt creator, and it looks
> > kinda weird and confusing).
> >
> > On Mon, Jul 12, 2021 at 11:22:54PM +0200, Elvis Stansvik wrote:
> > >Personally I'm always frustrated when I hit a dead end during git
> > >blame.
> >
> > >Even if the original repo will be kept around, it's an added
> > >obstacle.
> > >
> > a rather small obstacle, given that we have a git-qt-grafts script that
> > pretty much completely automates the process (it would actually need a
> > bit of a revamp by now).
>
> Yea, I just thought it a good idea to follow Thiago's suggestion to
> see what the cost would be to do a full history import. But I may have
> misunderstood what is even possible and not.
>
> As an outsider doing a sort of drive-by git blame trying to find the
> rationale for something, I may not know about special tooling that Qt
> has.
>
> But yes, you folks who work day to day on Qt should decide. Just
> wanted to chime in with my opinion.
>
> >
> > >And at some point, I'm sure it will no longer be available.
> > >
> > we keep around all repos. the remote may just need an adjustment to
> > point to {graveyard}/.
>
> Alright, that's good. In the project I was digging through the other
> week, the commit that added the code didn't even say where it came
> from, just something like "Code moved from old repo", and after
> extensive searching I concluded that "old repo" was no longer online.
>
> Qt being a more serious project, I'm sure you guys will leave a better
> commit message and won't start bulldozing over your {graveyard}/ :)
>
> Elvis
>
> >
> > (speaking of which, it might be actually time to do that with qt.git,
> > rather than only renaming it.)
I tried this on my local repo and there were surprisingly few
conflicts (most were in dist/changes-*).
cd qtdeclarative
git checkout dev
git remote add -f qqc2 ../qtquickcontrols2
git merge --allow-unrelated-histories qqc2/dev
If we prepare qtquickcontrols2.git beforehand (for example, by moving
dist/ into a subdirectory), the conflicts would be reduced. The
labour-intensive part is then merging the CMakeLists and testing.
If I understood the earlier talk about "grafting" correctly, it can
avoid the history duplication that occurs with my approach above.
However, I don't know how to achieve that -- Could someone kindly post
a sequence of commands?
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Removing the global static QObject from QPixmapCache
== Issue ==
There is a rule that "QCoreApplication should be the first QObject
created and last destroyed" [1]. However, there exists a violation to
this rule in Qt's internals -- QPixmapCache uses an internal global
static QObject (a QPMCache, to be precise) [2].
If initialized, the QPMCache outlives the QGuiApplication and gets
destroyed when the program/library is unloaded. This violates the rule
above.
This also causes problems when the QGuiApplication is created in a
std::thread instead of in main() (e.g. when a non-Qt application loads
a Qt-based plugin to display a GUI) -- The QPMCache destructor is run
by the wrong thread, which produces a warning, " QObject::~QObject:
Timers cannot be stopped from another thread ". There are also reports
that this can cause crashes [3][4].
== Proposal ==
QPMCache does not need the thread-safe initialization offered by
QGlobalStatic, since it can only be used from the Qt GUI thread. It
should also not outlive QGuiApplication.
So, I propose replacing QGlobalStatic with
QPointer as a simple self-cleaning singleton, and replacing
access to the global variable with QPMCache::instance():
QPointer pm_cache;
QPMCache *QPMCache::instance() {
if (!pm_cache && qGuiApp && !qGuiApp->closingDown()) {
Q_ASSERT_X(QThread::currentThread() == qGuiApp->thread(),
"QPixmapCache initialization", "QPixmap can only be accessed from the
GUI thread");
pm_cache = new QPMCache;
connect(qGuiApp, &QGuiApplication::aboutToQuit, [] {
QPixmapCache::clear();
pm_cache->deleteLater();
});
}
return pm_cache;
}
I believe this approach should also take care of the ancient QTBUG-21807 [5]
Thoughts?
Regards,
Sze-Howe
[1]
https://bugreports.qt.io/browse/QTBUG-71545?focusedCommentId=430042#comment-430042
[2]
https://code.woboq.org/qt5/qtbase/src/gui/image/qpixmapcache.cpp.html#pm_cache
[3] https://forum.qt.io/topic/126128/qapplication-in-std-thread
[4] https://forum.qt.io/topic/126168/global-static-qpixmapcache-in-qt-internals
[5] https://bugreports.qt.io/browse/QTBUG-21807
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Avoiding ads and/or Google for doc searches (was: Changes to Freenode's IRC)
On Thu, 20 May 2021 at 01:40, Kai Köhne wrote: > > > -Original Message- > > From: Development On Behalf Of Jason H > > Sent: Wednesday, 19 May 2021 17:26 > > To: giuseppe.dang...@kdab.com > > Cc: development@qt-project.org > > Subject: Re: [Development] Changes to Freenode's IRC > > > > * Before you laugh, and say that is crazy, consider that the online Qt Docs search results now have ads: https://doc.qt.io/qt-5/search-results.html?q=camera shows 4 ads for me. And I don't know of any other toolkit who serves their documentation with ads. Take for example mozdev: > > https://developer.mozilla.org/en-US/search?q=camera shows 0 ads. React, 0 ads. I figure it's only a matter of time until the actual documentation pages have ads too. (There may be good reasons for ads, but it's still not a good look.) > > It's true that the embedded search on doc.qt.io sometimes shows ads. But it's not the result of evil TQtC making heaps of money with ads. It's just a side-effect of using google for embedded search, and has been like that since years (if not decades) ... We have actually recently started to look into it (again), see https://bugreports.qt.io/browse/QTWEBSITE-723 if you want to get updates. For those who want to avoid ads and/or the Google search engine, consider the Qt Doc Search browser extension. Features: * Initiate searches from any browser tab; no need to navigate to doc.qt.io first * Search a specific version of Qt or a specific tool (Qt Creator, Qt Design Studio, GammaRay, etc.) * Choose your search engine (default: DuckDuckGo) User links: * (Chrome/Edge) https://chrome.google.com/webstore/detail/qt-doc-search/gfigdpnkjnilcielpnmfmdnnbloabjoh * (Firefox) https://addons.mozilla.org/en-US/firefox/addon/qt-documentation-search/ Other links: * (Original forum post) https://forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches * (Source code, public domain) https://github.com/JKSH/qt-doc-search/ Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] How to deprecate enum values (was: "Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6")
On Thu, 8 Apr 2021 at 04:43, Volker Hilsheimer wrote: > without compile time warning those methods will still be in use, so we can’t > remove them. Is there a way to generate compile-time warnings for _enum values_? Here are some existing flags that were missed during the Qt 6.0 cull: * Code comments -- QLocale::ImperialSystem is commented as "// Qt 4 compatibility" [1] * QDoc free-form text -- QLocale::Uigur is documented as "Obsolete, please use Uyghur" [2] * QDoc commands -- Qt::Desktop (from Qt::WindowType) is hidden with the "\omitvalue" command [3] (although a QDoc bug made it partially visible still [4]) Regards, Sze-Howe [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/text/qlocale.h#n880 [2] https://doc.qt.io/qt-6/qlocale.html#Language-enum [3] https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qnamespace.qdoc#n2179 [4] https://bugreports.qt.io/browse/QTBUG-92386 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6
On Wed, 7 Apr 2021 at 22:14, Volker Hilsheimer wrote: > > > On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen wrote: > > > > On Mittwoch, 7. April 2021 15:18:10 CEST Giuseppe D'Angelo via Development > > wrote: > >> Il 07/04/21 14:56, Sze Howe Koh ha scritto: > >>> Is it acceptable to remove them during Qt 6's lifetime? Or should we > >>> wait till Qt 7? > >> > >> It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility > >> promise. And not marking things _in code_ but only in docs isn't good > >> enough. > >> > > > > We remove and change private API all the time. If it was declared > > deprecated long ago, we could argue it is kind of private in qt6. > > > > 'Allan > > But declaring an API deprecated requires two things: > > * documentation marking it as obsolete > * QT_DEPRECATED_SINCE macro usage to trigger compile time warnings > > QMessageBox::buttonText for instance doesn’t have said macro, and is not > inline, so we can’t remove it without de-facto breaking BiC in a material way > (since at least on Windows, the DLL found at runtime has to provide all > symbols that the static import library had at link time, no matter if used or > not). > > > So, what would be not only acceptable but desirable is a bunch of changes > that add QT_DEPRECATED_SINCE to those methods that so far have only been > documented as obsolete. And perhaps even a bit of qdoc tinkering to help us > maintain consistency. > > Volker https://bugreports.qt.io/browse/QTBUG-92480 https://bugreports.qt.io/browse/QTBUG-92481 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Deprecated/Obsolete API that survived the transition from Qt 5 to Qt 6
Some parts of the Qt API have been documented as obsolete for a long time, but were not removed before Qt 6.0.0 was released. For example, the following 2 pages contain exactly the same list: * https://doc.qt.io/qt-5/qmessagebox-obsolete.html * https://doc.qt.io/qt-6/qmessagebox-obsolete.html QLocale::countriesForLanguage() is another example. These probably slipped through the cracks because they were only tagged "\obsolete" for QDoc but didn't get tagged with macros like QT_DEPRECATED_SINCE() or QT_VERSION_CHECK(). Is it acceptable to remove them during Qt 6's lifetime? Or should we wait till Qt 7? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A face for the Qt Project
On Fri, 19 Mar 2021 at 02:43, Cristián Maureira-Fredes wrote: > > Dear community, > > The Qt Project is a huge effort from many people, and for the same > reason, it's quite interesting to (1) Learn how to contribute and be > part of it, and (2) Analyze the interactions of the many > Qt modules. > > For people new to the project, contributing to Qt might be challenging, > but I'm certain we all agree that being clear, and provide all the > information in one place is crucial to at least enable them to do > the first step. > > On the other hand, if you have been around for a while, > you know that Thiago's blog has a good set of statistics [1] > that helps a lot to get an overview of the current state of the project. > > With these two ideas in mind, it makes sense to use qt-project.org > as the face of the Qt Project, highlighting the two previous points > I described. > > I would like to ask the community, if we are in favor of using > the proposal from [2] as qt-project.org. > > The goal will be to have this repository under our open governance, > so anyone will be able to suggest changes, as we do in Qt. > > The idea will be not to duplicate content from https://qt.io, > but focus on aspects related to contributing to the project. > > > # About the implementation > > The page you can see on [2] was generated with Dash, > a Python module based on Plotly [3], and the data comes from the > meta qt5.git repository, including also the qt-creator and pyside-setup > ones. > > The text you see on the left-side cards, comes from local Markdown > files, so also it would be straightforward to edit them. > > I will upload the code if the community agrees to go forward, > so then we could be able to create a public repository to keep > this code. > > Cheers > > > [1] https://www.macieira.org/blog/qt-stats/ > [2] https://qt-project-org.herokuapp.com > [3] https://dash.plotly.com/ > > -- > Dr. Cristián Maureira-Fredes > R&D Manager > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > > Geschäftsführer: Mika Pälsi, > Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B +1 Great idea! Thank you for this initiative.The interactive stats provide fascinating insights, and having all the relevant resources on one page would help lower the barrier to contribution. Please also make this _prominent_. Currently, the "Community" page [1] is easy to miss on the main Qt website. The only places where I can see links are: * The footer section of qt.io * The very bottom section of the Developers page [2] Regards, Sze-Howe [1] https://www.qt.io/contribute-to-qt/ [2] https://www.qt.io/developers/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] [Releasing] download.qt.io is down
Thank you, Tuukka and co! Regards, Sze-Howe On Fri, 22 Jan 2021 at 22:33, Tuukka Turunen wrote: > > Hi, > > > > Servers have been restored and open-source downloads are working again. > > > > Archive of old and historic releases is missing, but will be made available > next week. > > > > Blog post: https://www.qt.io/blog/open-source-downloads-working-again > > > > Yours, > > > > Tuukka > > > > From: coroberti > Date: Friday, 22. January 2021 at 11.32 > To: Nils Jeisecke , Tuukka Turunen > , Qt Project Development > Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down > > On Fri, Jan 22, 2021 at 10:38 AM Nils Jeisecke via Development > wrote: > > > > Hi there, > > > > On Fri, Jan 22, 2021 at 7:59 AM Tuukka Turunen wrote: > >> > >> Hi, > >> > >> > >> > >> Status update of the problem with open-source downloads: Last night we > >> finally got a disk big enough for the packages from the service provider. > >> Most of the data has been transferred throughout the night with a few last > >> things still being uploaded to the new virtual server. After the data > >> transfer is complete we start testing and validation of the data and the > >> system. Target is to enable first the online installer, then the offline > >> packages and finally the achieve of old releases. > > > > > > just a little "Thank You" from my side. > > > > I try to imagine being of those spending hour after hour to get things > > running again and then reading all those nasty comments on the blog post. > > > > Nils > > Joining the thanks of Nils. > We are really appreciating your support of open-source distribution. > > Kind regards, > Robert Iakobashvili ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] [Interest] download.qt.io is down
Thank you for clarifying, Tuukka. I am (along with many others, I'm sure) delighted to hear about the upcoming ability to officially select mirrors, and look forward to an improved download experience going forward. MirrorBrain does not always pick the best source. [1] Best of luck with setting up an alternative file server. Regards, Sze-Howe [1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html On Wed, 20 Jan 2021 at 18:35, Tuukka Turunen wrote: > > Hi, > > > > To explain a bit why I was mistaken about the online in the mail I sent last > night. We have a development feature that allows selecting the mirror > manually. I thought it could be used, but it turned out we had not released > that version of the installer. Would have been handy, but since it is not > already released, the best approach is to re-create the master. We are doing > that now. We will also have this feature in the installer released (after we > can again make releases), because it is sometimes handy to tell explicitly > what server to download from. > > > > Yours, > > > > Tuukka > > > > From: Development > Date: Wednesday, 20. January 2021 at 8.06 > To: Sze Howe Koh > Cc: development@qt-project.org , > releas...@qt-project.org , Interests Qt > > Subject: Re: [Development] [Releasing] [Interest] download.qt.io is down > > Hi, > > > > Yes, this is correct. > > > > Yours, > > > > Tuukka > > > > From: Sze Howe Koh > Date: Wednesday, 20. January 2021 at 0.10 > To: Tuukka Turunen > Cc: Mark Long , development@qt-project.org > , Interests Qt , > releas...@qt-project.org > Subject: Re: [Releasing] [Interest] download.qt.io is down > > On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen wrote: > > > > > > Hi, > > > > There are multiple mirrors, try for example: > > > > > > > > https://qt-mirror.dannhauer.de/ > > > > https://www.funet.fi/pub/mirrors/download.qt-project.org/ > > > > https://ftp.fau.de/qtproject/ > > > > > > > > ...or just use the online installer, which picks mirrors automatically. > > > > Yours, > > > > Tuukka > > Hi Tuuka, > > The Online installer downloads files in 2 phases: > > 1. Retrieve metadata from download.qt.io > 2. Retrieve actual binaries from the auto-selected mirror > > Since Step #1 is blocked, it can't proceed to Step #2. > > > Regards, > Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] [Interest] download.qt.io is down
On Wed, 20 Jan 2021 at 04:10, Tuukka Turunen wrote: > > > Hi, > > There are multiple mirrors, try for example: > > > > https://qt-mirror.dannhauer.de/ > > https://www.funet.fi/pub/mirrors/download.qt-project.org/ > > https://ftp.fau.de/qtproject/ > > > > ...or just use the online installer, which picks mirrors automatically. > > Yours, > > Tuukka Hi Tuuka, The Online installer downloads files in 2 phases: 1. Retrieve metadata from download.qt.io 2. Retrieve actual binaries from the auto-selected mirror Since Step #1 is blocked, it can't proceed to Step #2. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
On Sat, 18 Jul 2020 at 03:58, Ulf Hermann wrote: > > > I must be missing something. I tend to think of eventloops with notify > > signals are an improvement over polling. You statement seems to say > > that asking for a value is better, and notifications are to be avoided? > > I'm not saying that you should go back to polling. In the case that you > have genuine events, for example input or network activity, signals may > just be the thing you need. This whole discussion is specifically about > properties and their _change_ signals. > > Mind that the propagation of dirty flags across a binding graph is a > kind of "change signal" in its own right. With QProperty, we just don't > calculate the values right away when we notice that a related property > has changed. Why is that? > > Properties can change fairly often, and synchronously triggering a chain > of calculations whenever some property changes can be inefficient and > can lead to unexpected intermediate values. This is why we introduce > lazy evaluation for property bindings. > > With this system, on some level, you indeed have to poll a property to > make something happen outside the system. However, certain technologies > are inherently based on polling. For example the scene graph rendering a > frame every 16ms will poll for changed items every time. For this, a > lazy evaluation strategy makes more sense than the usual change signals. > > If you want to take advantage of lazy evaluation in such places, you > should stop using the change signals there, though. Whenever a property > has a change signal, it and everything it depends on needs to be > evaluated eagerly. > > best, > Ulf Will language bindings be able to take advantage of the new QProperty system? For example, will it be possible to create a lazy-evaluated property binding from non-C++ code? (For reference, Qt for Python currently creates new properties this way: https://wiki.qt.io/Qt_for_Python_UsingQtProperties ) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] take five
On Wed, 10 Jun 2020 at 15:26, Lorn Potter wrote: > > Hi *, > On the road to Qt 6, we must remember our past: > What better way than to have a short break to listen to this worldwide > hit - The Qt 4 Dance! > > https://www.youtube.com/watch?v=NbTEVbQLC8s > > -- > Lorn Potter > Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly That video was unexpectedly enjoyable to watch. Thanks for sharing! Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] WebSocket Module [CVE-2018-21035]
On Mon, 9 Mar 2020 at 19:11, wrote: > Hi, > > I provided a patch for CVE-2018-21035, present in Qt5 WebSocket Module. > However apparently since the patch adds a new API it cannot go into Qt5. > > This vulnerability makes the Qt5 WebSocket module totally unusable for > use in non-trusted environment (like Internet). > > Is there anything to do about it ? > > https://nvd.nist.gov/vuln/detail/CVE-2018-21035 > https://bugreports.qt.io/browse/QTBUG-70693 > https://codereview.qt-project.org/c/qt/qtwebsockets/+/284735 Hi, I suggest escalating this to the Security team for their attention (see https://quips-qt-io.herokuapp.com/quip-0015-Security-Policy.html ). On a related note, is Kurt Pattyn still the Maintainer for Qt WebSockets [1]? He has been quiet on codereview.qt.io since May 2014 [2] and on GitHub since Feb 2019 [3]. Regards, Sze-Howe [1] https://wiki.qt.io/Maintainers [2] https://codereview.qt-project.org/q/owner:pattyn.kurt%2540gmail.com [3] https://github.com/KurtPattyn?tab=overview&from=2019-12-01&to=2019-12-31 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW
On Tue, 18 Feb 2020 at 20:57, Edward Welbourne wrote: > > On Tue, 18 Feb 2020 19:35:53 +0800 > Sze Howe Koh wrote: > >> See > >> https://forum.qt.io/topic/111473/maintenance-tool-error-cannot-open-file-for-writing-no-error/ > > I note that the code quoted is using rand(); the code in QTemporary file > switched to using QRandomGenerator at 5.10.0; that's what now produces > the "WARNING: RDRND generated:" message reported in one post. > > Christian Kandeler (18 February 2020 12:59) replied > > Probably the same as https://bugreports.qt.io/browse/QTBUG-77375. > > Fixed in 5.13.0 - the fix added the warning quoted above and takes steps > to ensure we don't rely on the broken HWRNG, presumably falling back to > some pseudo-random alternative. > > >> Is this worth a post on the Qt Blog? I foresee many frustrated and > >> confused Ryzen users out there who would benefit from a reminder to > >> update their BIOS. > > > I suppose it won't hurt, but I wonder how such a system is usable at > > all... > > Which version was this encountered in ? > > Eddy. Judging from the screenshots, it's the latest and greatest version of the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1] If it matters, I also realized the error message was actually: Cannot open file "" for writing: No error Regards, Sze-Howe [1] https://forum.qt.io/post/578114 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW
See https://forum.qt.io/topic/111473/maintenance-tool-error-cannot-open-file-for-writing-no-error/ In summary, a bad BIOS prevents QTemporaryFile from generating different filenames each run. The Qt Installer encounters name conflicts and produces a cryptic error message: Cannot open file "" for writing: No file name specified Is this worth a post on the Qt Blog? I foresee many frustrated and confused Ryzen users out there who would benefit from a reminder to update their BIOS. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Mon, 17 Feb 2020 at 14:18, Marc Mutz via Development wrote: > > On 2020-02-16 19:32, Thiago Macieira wrote: > > On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development > > wrote: > >> C++20 will contain new classes with emit() member functions > >> (wg21.link/P0053). While that will only pose problems for users that > >> include the new header after (almost) any Qt header, > >> this > >> should serve as a second shot across the bows (after namespace > >> boost::signals) that we should change something. > > > > Orthogonal to your request: can we ask C++20 to change the name of this > > function? We've been #define'ing emit for nearly 30 years. > > I did. There was no consensus for a change (not by a long shot). > > If it had been just the basic_syncbuf version, which returns bool, it > might have been possible to change that to try_emit, but the > basic_osyncstream version sets failbit, and returns void, so naming that > one try_emit would be awkward, and a full bikeshdding about a different > stem than 'emit' was asking for too much. > > Thanks, > Marc Marc's request is here, for the record: https://cplusplus.github.io/LWG/issue3399 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)
Another use case: Mass deployment to multiple PCs: https://forum.qt.io/topic/111587/classroom-deployment-of-qt-for-multiple-pcs-and-for-all-users-windows Regards, Sze-Howe On Sat, 15 Feb 2020 at 07:06, Sze Howe Koh wrote: > > On Sat, 15 Feb 2020 at 04:19, Thiago Macieira > wrote: > > On Tuesday, 28 January 2020 19:31:34 PST Thiago Macieira wrote: > > > On Tuesday, 28 January 2020 03:52:49 PST Tino Pyssysalo wrote: > > > > It is also possible to transfer the qtaccount.ini file to a CI machine, > > > > which removes the need for manual/interactive login. The qtaccount.ini > > > > just > > > > contains the hash of the password. > > > > > > I suggest you be very careful in suggesting how to transfer the > > > qtaccount.ini file. Test half a dozen public CI systems and give > > > instructions to them all. > > > > > > And specifically tell people NOT to "git add" it to a project on GitHub/ > > > GitLab/BitBucket. > > > > Hello Tino > > > > Can we get an answer here? > > > > What is the recommended way to install Qt on a CI to test a Qt-based > > application? > > > > Travis CI has stopped working completely and I'd like to switch to GitHub > > Actions. Does The Qt Company recommend I use Stephan Binner's PPA? Or does > > it > > want me to use its own compiled binaries? If the latter, please provide > > instructions for automated builds. > > Hello Tino, > > It's not just CI; Qt now can't be easily used with all other > automation technologies like Docker. [1] > > Please note that users have started to suggest workarounds such as > creating throwaway Qt accounts in order to automate the installation. > [2] > > > Regards, > Sze-Howe > > [1] https://forum.qt.io/post/577886 > [2] https://forum.qt.io/post/577926 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)
On Sat, 15 Feb 2020 at 04:19, Thiago Macieira wrote: > On Tuesday, 28 January 2020 19:31:34 PST Thiago Macieira wrote: > > On Tuesday, 28 January 2020 03:52:49 PST Tino Pyssysalo wrote: > > > It is also possible to transfer the qtaccount.ini file to a CI machine, > > > which removes the need for manual/interactive login. The qtaccount.ini > > > just > > > contains the hash of the password. > > > > I suggest you be very careful in suggesting how to transfer the > > qtaccount.ini file. Test half a dozen public CI systems and give > > instructions to them all. > > > > And specifically tell people NOT to "git add" it to a project on GitHub/ > > GitLab/BitBucket. > > Hello Tino > > Can we get an answer here? > > What is the recommended way to install Qt on a CI to test a Qt-based > application? > > Travis CI has stopped working completely and I'd like to switch to GitHub > Actions. Does The Qt Company recommend I use Stephan Binner's PPA? Or does it > want me to use its own compiled binaries? If the latter, please provide > instructions for automated builds. Hello Tino, It's not just CI; Qt now can't be easily used with all other automation technologies like Docker. [1] Please note that users have started to suggest workarounds such as creating throwaway Qt accounts in order to automate the installation. [2] Regards, Sze-Howe [1] https://forum.qt.io/post/577886 [2] https://forum.qt.io/post/577926 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Rationalizing qApp and qGuiApp
Currently, * The qApp macro changes type depending on which headers are included, and in what order. (If you #include but instantiate a QCoreApplication, qApp returns a QGuiApplication pointer) * The documentation says that the qApp macro is only valid if a QApplication was instantiated. [1] * The qGuiApp macro doesn't change types like qApp; it is always a QGuiApplication pointer. * There is no equivalent of qGuiApp for QCoreApplication and QApplication. To resolve this inconsistency, I propose that we do one of the following for Qt 6: A) Update the documentation to say that qApp can change types. Leave the qApp macro as-is. B) Leave the documentation as-is. Make the qApp macro disappear from qcoreapplication.h and qguiapplication.h unless compatibility mode is enabled. C) Rename "QApplication" -> "QWidgetApplication", keeping the former as a typedef. Leave the qApp macro as-is but deprecated. Add the qCoreApp and qWidgetApp macros (analogous to qGuiApp) Thoughts? Regards, Sze-Howe [1] https://codereview.qt-project.org/c/qt/qtbase/+/174414 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating André Hartmann for maintainer for QCanBus API
On Tue, 26 Nov 2019 at 17:07, Samuel Gaist wrote: > > > > > On 26 Nov 2019, at 09:36, Alex Blasche wrote: > > > > Hi, > > > > The QCanbus API is part of the QtSerialBus module. Since its first release > > it has come a long way. In particular, André Hartmann & Denis Shienkov made > > big contributions over time. For that I am very grateful. Thank you. > > > > As the current maintainer of the QCanBus API I would like to hand the > > maintainer baton over to André. > > > > He has done a very good job of fixing the day-to-day issues popping up on a > > regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and > > other parts in QtBase. > > > > -- > > Alex > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > +1 > > -- > Samuel Gaist > Research And Development Engineer > Idiap Research Institute, > Centre du Parc, > CP 592, > CH-1920 Martigny > http://www.idiap.ch/ +1 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Wither QString?
On Fri, 18 Oct 2019 at 08:43, Alexander Nassian
wrote:
>
> C++ hasn‘t even proper Unicode handling integrated. std::string is a mess in
> my opinion.
>
> Beste Grüße / Best regards,
> Alexander Nassian
>
> Am 18.10.2019 um 02:30 schrieb Henry Skoglund :
>
> > Hi, while writing lots of QString string fiddling code (keyboard macro
> > utility) I feel something tugging at my sleeve:
> > the upcoming C++20, looking at std::format(), it seems really handy, e.g.:
> >
> > std::string s = std::format("String '{}' has {} characters\n", string,
> > string.length());
> >
> > // for a German flavor you can use arg #
> > std::string s = std::format("{1} Zeichen lang ist die Zeichenkette
> > '{0}'\n", string, string.length());
> >
> > // lots of formatting options with a ':' inside the curlies
> > std::string s = std::format("{0:b} {0:d} {0:x}", 42); // s == "101010 42
> > 2a"
> >
> > Using QString::arg() works fine but it's getting harder to ignore all the
> > new C++ stuff and C++20 looks to be one of the bigger additions to the
> > language since C++11.
> >
> > Perhaps the time has come to think about a retirement plan for QString?
> >
> > Rgrds Henry
I agree with Alexander; QString is far more pleasant to use than
std::string for many everyday tasks.
Aside from Unicode support, std::string lacks (clean) equivalents of
the following functions which I use regularly:
- QString::startsWith(), QString::endsWith()
- QString::split(), QString::section()
- QString::simplified(), QString::trimmed()
- QString::contains(), QString::indexOf() by regex
- QString::replace(), QString::remove() by substring or by regex
I refuse to ditch QString for std::string until Unicode and the above
functionality are offered in std::string, at the very least.
Here are more functions that are lacking in std::string. I personally
don't use them much, but they look pretty handy if the right project
comes along:
- QString::right()
- QString::localeAwareCompare()
- QString::compare() with Qt::CaseInsensitive
- QString::chop(), QString::chopped()
- QString::leftJustified(), QString::rightJustified()
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Updating holdover API from Qt 1 times
On Tue, 20 Aug 2019 at 22:29, Matthew Woehlke wrote: > > On 17/08/2019 00.13, Sze Howe Koh wrote: > > QLabel returns some CoW types by-pointer as a legacy from Qt 1 times [1]: > > > > QPixmap *QLabel::pixmap() const; > > QPixture *QLabel::pixmap() const; > > Does this allow one to obtain the internal pixmap and modify it in-place > without then calling setPixmap? If so, note that changing these to > return by value represents a non-trivial change to the API. (Although, > perhaps that's a change we *want*...) No, it's actually a pointer-to-const-value which forbids in-place modifications: const QPixmap *QLabel::pixmap() const; > > 3) Pick one of the options above, but go one step further and use > > std::optional (C++17) instead of returning null objects. > > Ugh... I'm with Kevin; I think this doesn't make sense and adds a level > of indirection for no good reason that will only make the API's harder > to use. > > Please choose based on what produces the best API in the end, not the > least porting effort. Otherwise we are just trading one sub-optimal API > for another. Thank you for your input, Marc, Kevin, and Matthew. I agree with Kevin that std::optional doesn't make sense for implicitly-shared objects. Furthermore, using std::optional here still leaves the Qt API in an inconsistent state. Therefore, I've started implementing option #2: * https://codereview.qt-project.org/c/qt/qtbase/+/272365 * https://codereview.qt-project.org/c/qt/qtbase/+/274029 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Branching '5.14' from 'dev' complete, Qt 5.14 Feature Freeze in effect & '5.15' created
On Tue, 27 Aug 2019 at 18:48, Nils Jeisecke via Development wrote: > > Am 27.08.2019 um 08:34 hat Jani Heikkinen geschrieben: > >This issue should be fixed now > Now it says "Your edit was aborted by an ArticleSave hook". The message could be clearer, but it actually means "Your edit is pending moderation". It has been approved and is now published. > Nils Regards, Sze-Howe ___ 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
[Development] Updating holdover API from Qt 1 times
QLabel returns some CoW types by-pointer as a legacy from Qt 1 times [1]:
QPixmap *QLabel::pixmap() const;
QPixture *QLabel::pixmap() const;
If you know of any other such API, please point them out!
Anyway, a few different ways have been proposed to modernize this API
[2][3][4], summarized below:
1) Add a non-overloaded version and deprecate the existing version:
class QLabel {
QPixmap *pixmap() const; // deprecated
QPixmap labelPixmap() const; // new
};
2) Keep the existing name but change the return type, with support for a
transition period:
namespace Qt {
struct ReturnByValue_t {};
static Q_CONSTEXPR ReturnByValue_t ReturnByValue;
}
class QLabel {
QPixmap *pixmap() const; // deprecated
QPixmap pixmap(Qt::ReturnByValue_t) const; // new
};
class QLabel {
#ifndef QT_NO_COW_POINTERS
QPixmap *pixmap() const;
#endif
QPixmap pixmap(Qt::ReturnByValue_t
#ifdef QT_NO_COW_POINTERS
= ReturnByValue
#endif
) const;
}
// Without QT_NO_COW_POINTERS
QPixmap *pm1 = label->pixmap();
QPixmap pm2 = label->pixmap(Qt::ReturnByValue);
// With QT_NO_COW_POINTERS
QPixmap pm3 = label->pixmap();
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.
There's also Option (4): Leave it all alone; if it ain't broke don't fix it.
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.
Regards,
Sze-Howe
[1]
https://lists.qt-project.org/pipermail/development/2014-December/019376.html
[2]
https://lists.qt-project.org/pipermail/development/2014-December/019377.html
[3] https://codereview.qt-project.org/c/qt/qtbase/+/101233
[4] https://codereview.qt-project.org/c/qt/qtbase/+/267825
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Changes planned for the online installer
Thanks for the initiative, Tuuka and team. Much appreciated.
As part of the meeting, please review the points raised in previous
discussions [1][2]. Three major pain points were:
(A) Downloading metadata is very time-consuming.
(B) The automatic mirror selection algorithm doesn't always pick
the best mirror.
(C) (New users) It's not clear how to choose what to install.
The changes you described, as well as Fabrice's suggestions, seem to
address (A) quite nicely.
I made a tool to help with (B), but it was meant to be a quick and
dirty hack [3]. I didn't expect it to still be in use 5 years later.
Please provide the ability to override the default mirror within the
installer itself.
I believe the documentation team discussed on-boarding techniques as
part of their workshop last week [4]. Please work with them to address
(C) in a holistic manner.
Regards,
Sze-Howe
[1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html
("To improve UX of the online installer") and subsequent replies
[2] https://bugreports.qt.io/browse/QTIFW-1132
[3]
https://forum.qt.io/topic/43349/slow-downloads-with-the-online-installer-try-this-tool
[4] https://blog.qt.io/blog/2019/03/01/the-future-of-documentation/
On Tue, 19 Mar 2019 at 21:12, Fabrice Mousset | GEOCEPT GmbH
wrote:
>
> Hi,
>
> It is great to hear there will be done some update on Maintenance Tool
>
> I don’t know about internal architecture of the software, but it would be
> great if Maintenance Tool could handle locally a little “cache” to avoid
> always (re)downloading from server all information about Qt releases.
>
> Each time Maintenance Tool is launched, it downloads almost the same stuff (I
> think) for Qt Servers. It would be much faster to store this information
> locally in little “database” (XML or SQLite for example) with a MD5SUM as
> Checksum. This would speed up the boot process when nothing new on server
> between 2 starts and, I think, this will also consume less server resources.
>
> My two cents.
>
> Fabrice
>
>
> Von: Development Im Auftrag von Tuukka
> Turunen
> Gesendet: Dienstag, 19. März 2019 13:33
> An: development@qt-project.org; releas...@qt-project.org
> Betreff: [Development] Changes planned for the online installer
>
>
> Hi,
>
> Online installer has over time become quite crowded with different releases
> and many have noticed that it is getting quite slow at times. Having all this
> default content is also problematic for those who mirror Qt as it would take
> a significant amount of disk space to have a complete mirror.
>
> From user viewpoint it could be seen handy that all these different releases
> are available via the online installer, but there are caveats. One major item
> is security. We always recommend to take the latest supported patch release,
> but have offered also all the old ones. It should be more clear than today to
> users what release to take. Unsupported releases contain multiple known
> vulnerabilities and should not be used.
>
> With an upcoming version of the online installer, we are planning to make the
> following changes:
>
> * Separate the pre-releases to its own ‘preview’ category, only visible when
> enabled
> * Remove all unsupported Qt releases from the online installer
> * Move all but the latest patch releases of supported Qt releases into
> ‘archive’ category
>
> This allows for greatly improved user experience of the online installer,
> focuses users to take the latest release with all security updates and
> reduces the space needed from the mirrors.
>
> Commercial online installer uses Amazon CDN and for the commercial users we
> are planning to offer some the older, unsupported releases. There is also
> extended support available for those commercial license holders who are using
> an otherwise unsupported release of Qt.
>
> Old Qt releases continue to be available for everyone in the download.qt.io
> historical archive, but in general they should be considered as a historical
> reference, not used in active projects.
>
> Feedback and thoughts welcome. The topic could also be taken to the agenda of
> next week’s release team meeting?
>
> Yours,
>
> Tuukka
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Enum classes in signals?
On Wed, 6 Feb 2019 at 12:43, Giuseppe D'Angelo via Development
wrote:
>
> Il 05/02/19 18:16, Dmitriy Purgin ha scritto:
> > I couldn't figure out the exact combination but as far as I remember, if
> > you have namespaced code, you have to always fully qualify the enum
> > class parameters in signals and slots.
>
> This is actually also the case for enums and enum classes. For instance,
> consider
>
> class A : public QObject {
>Q_OBJECT
> public:
>enum class E { E1, E2, E3 };
> signals:
>void mySignal(E);
> };
>
> class B : public QObject {
>Q_OBJECT
> public slots:
>void mySlot(A::E);
> };
>
> This code compiles just fine, but you will NOT be able to connect
> mySignal1 to mySlot using SIGNAL/SLOT.
>
> Doing it like this
>
>connect(a, SIGNAL(mySignal(E)), b, SLOT(mySlot(A::E)));
>
> won't work because the argument lists don't match (this connect version
> compares the parameter lists _as strings_, and obviously "E" is
> different from "A::E").
>
>
> Connecting it like this
>
>connect(a, SIGNAL(mySignal(A::E)), b, SLOT(mySlot(A::E)));
>
> will not find mySignal in A, because the lookup will search for a
> function with that signature _spelled exactly that way in the source
> code_. Such a function is not there; the source code spells "E" as
> parameter type, not "A::E".
>
> The solution hence is to declare the signal with an A::E parameter.
+1
This is (kind of) illustrated at
http://doc.qt.io/qt-5/signalsandslots-syntaxes.html#type-checking-and-implicit-type-conversions
using QAudio::State as an example.
The article also shows a use-case that cannot be supported by PMF
connections, namely making connections between C++ and QML. This is
why the string-based syntax must not be deprecated.
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Best way to introduce SIC for Qt 6 (was: Branch for Qt 6)
On Tue, 15 Jan 2019 at 23:50, Thiago Macieira wrote: > > On Tuesday, 15 January 2019 00:21:54 PST Lars Knoll wrote: > > * We regularly merge dev into it > > * BC breakages are fine > > * SC breakages require a maintainer approval and a Changelog entry marking > > this as a source incompatible change * All functions you’d like to remove > > in qt6 need to be deprecated in dev first > > And please avoid Qt6 specific changes if you can, because of those merges. One of the changes we should consider is for QLabel::pixmap() and QLabel::picture() to return by-value instead of by-pointer. (Abandoned alternative at https://codereview.qt-project.org/#/c/101233/ ) This is source-incompatible. What's the best way to introduce this change? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.12 and debug/warnings messages
On Fri, 11 Jan 2019 at 19:03, Fabrice Mousset | GEOCEPT GmbH wrote: > > Hi Kai, > > I've used the development mailing list because I think this is a bug in the > release. > When I build my application with Qt 5.4.2, Qt 5.6.x or Qt 5.11.2 all works as > expected. > But with Qt 5.12.0, nothing works. Only qCritical() messages are working. > > To be more explicit, I use qInstallMessageHandler() to register my logger > callback function. > The callback method is only called (with Qt 5.12.0) when qCritical() is > used. qDebug() and qWarning() have no effect! > So I've supposed the Qt 5.12.0 release (MSVC2017 / 32bit) have been build > with QT_NO_WARNING_OUTPUT and QT_NO_DEBUG_OUTPUT. > Once again, with previous Qt release, all works as expected. > > Regards > > Fabrice Hi Fabrice, I'm on Windows 10 64-bit, using the official pre-built version of Qt 5.12.0 for MSVC 2017 32-bit. I can confirm that qDebug() and co are working as usual for me, so I don't think there is anything wrong with Qt 5.12.0 itself. So, let's figure out why it's not working on your machine. First, can you provide details on how you installed this version of Qt 5.12.0? Second, launch SysInternals DebugView (https://docs.microsoft.com/en-us/sysinternals/downloads/debugview ) before you launch Qt Creator. Do your qDebug() messages appear in DebugView? Regards, Sze-Howe > -Ursprüngliche Nachricht- > Von: Kai Koehne > Gesendet: Freitag, 11. Januar 2019 10:34 > An: Fabrice Mousset | GEOCEPT GmbH ; > development@qt-project.org > Betreff: RE: Qt 5.12 and debug/warnings messages > > Hi Fabrice, > > There's been no such change. Your problem is most likely one of two: > > - You actually disable the qDebug, qWarning via custom logging rules. See > http://doc.qt.io/qt-5/qloggingcategory.html , section "Logging Rules" for the > details. > > - You have a GUI program that logs to the system wide debugging log, but > other IDE's or debuggers are interfering. Make sure that you don't run > multiple IDE's or debuggers at the same time. > > In general, this is the wrong mailing list for questions about Qt itself. > Please contact either support (if you're a commercial customer), or use the > forums or inter...@qt-project.org. > > Regards > > Kai > > > -Original Message- > > From: Development On Behalf Of > > Fabrice Mousset | GEOCEPT GmbH > > Sent: Friday, January 11, 2019 9:50 AM > > To: development@qt-project.org > > Subject: [Development] Qt 5.12 and debug/warnings messages > > > > Hi, > > > > > > > > I have installed Qt 5.12.0 for Windows / MSVC2017-32bit with Qt > > Maintenance Tool. > > > > I wondering why qDebug and qWarning have been disabled in this version? > > > > qDebug() and qWarning() do not work, even in Debug build! Why? > > > > Is this intentional? > > > > > > > > Do I have to build Qt from sources to made them work again or will > > this be fixed/changed in next build (Qt 5.12.1)? > > > > > > > > Regards > > > > > > > > Fabrice Mousset ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Missing documentation in Qt 5.12
Significant chunks are missing from the Qt 5.12 documentation: https://bugreports.qt.io/browse/QTBUG-72357 Could we please have a prominent notice on the website informing users of this issue (and suggest viewing the Qt 5.11 version as a workaround) until a fix lands? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Christian Ehrlicher for Approver
On Tue, 20 Nov 2018 at 16:40, Samuel Gaist wrote: > > Hi, > > > On 20 Nov 2018, at 09:38, Richard Gustavsen wrote: > > > > Hi, > > > > I'd like to nominate Christian Ehrlicher for approver rights. > > > > He has done a lot of work in Qt, especially Widgets and Item Views, with > > more than 150 patches being merged during the last year. > > > > He has also been equally active in Jira, verifying bug reports, identifying > > duplicates, etc. > > > > His work: > > https://codereview.qt-project.org/#/q/owner:%22Christian+Ehrlicher%22,n,z > > > > His reviews: > > https://codereview.qt-project.org/#/q/reviewer:%22Christian+Ehrlicher%22,n,z > > > > Br, > > Richard Moe Gustavsen > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > +1 > > He’s also an active member on the forum. > > Cheers > > Samuel +1 And he's an active documentation improver too Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Resolving coding style contentions
Hi all, I can't find a final decision on this topic: http://lists.qt-project.org/pipermail/development/2016-June/026058.html The arguments from both sides were numerous (browse through http://lists.qt-project.org/pipermail/development/2016-June/thread.html ). I would like to avoid a re-hash of the same arguments. I'd just like to know: Did the Qt Project ever reach a decision? If not, how can we reach one? Thanks and regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unified data model API in QtCore => thin wrapper proposal
Hi Thiago,
On Sat, 18 Aug 2018 at 01:51, Thiago Macieira wrote:
>
> On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote:
> > > Now, looking at the code, I don't think it does work. I thought that
> > > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a
> > > set of non-const overloads returning QCborValueRef might be the trick.
> > That would be great to have as part of the API yes
>
> I won't have time to experiment with it before feature freeze. Technically,
> the API freeze doesn't happen until Beta, so we have a few more weeks, but I
> wouldn't hold my hopes up that I will have time to trial this.
>
> Any chance you can give it a go? Or someone else?
I've installed the Qt 5.12 alpha for MSVC 2015 and started playing
with the CBOR API.
map["hello"] = foo; // ERROR C2593: Operator '[' is ambiguous
map[QString("hello")] = foo; // OK
The ambiguity disappears if I remove either operator[](const QString&)
OR operator[](const QCborValue&). Oddly, operator[](QLatin1String)
doesn't matter. Why's that?
Also, chained operator[] currently doesn't work because
QCborValueRef::operator[](...) doesn't exist:
qDebug() << array[1]; // OK
qDebug() << array[1][2]; // ERROR C2676: 'QCborValueRef' does not
define this operator or a conversion to a type acceptable to the
predefined operator
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Online installer: Broken dependencies
New users cannot install at all and old users can't add new components because a preview package depends on the not-yet-released Qt 5.11.2: Cannot find missing dependency "qt.qt5.5112.win64_msvc2015_64" for "preview.qt.tools.qt3dstudioruntime.win64_msvc2015_64" Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Samuel Gaist for approver status
On Sat, 28 Jul 2018 at 16:57, André wrote: > > Hello all, > > I'd like to propose Samuel as approver. He has been active in the Qt project > for ages. > > He not only provides code changes [0], he is also active reviewing others > changes [1]. > > But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he > works > as moderator and answers plenty of questions every day. > > Some of his patches arised from forum questions, therefore Samuel perfectly > bridges > between the end users and the Qt main developers. > > I think this all qualifies Samuel for the approver status. > > Best regards, > André > > [0] > https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [1] > https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z > [2] https://forum.qt.io/user/sgaist +1 from me. I second all the points that André has raised. In addition, Samuel also improves the Qt documentation, and he has been awarded the title of Lifetime Qt Champion. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is Qt for Automation available under GPLv3?
On Fri, 8 Jun 2018 at 14:52, Frank Meerkötter wrote: > Hi, > > I would like to point out that Qt OPC UA, which is part of Qt for > Automation, can also be built with an LGPLv3 license as long as the > open62541 backend is used. > > Regards, > Frank Thanks for your clarifications, Alex and Frank. Thanks also to Leena for swiftly updating the documentation: https://codereview.qt-project.org/#/c/231875/ Just to check my understanding: Is "Qt for Automation" essentially a package/bundle that contains the following modules and their dependencies? * Qt Virtual Keyboard * Qt Quick Controls 2 * Qt Quick Compiler * Qt WebEngine * Qt Serial Bus * Qt Quick WebGL Streaming plugin * Qt MQTT * Qt KNX * Qt OPC UA Is there any special tooling (other than what's already available with the pre-built Qt Creator)? Regards, Sze-Howe > Am 08.06.2018 um 07:50 schrieb Alex Blasche: > > Hi, > > > > There are no binaries for open source users. However open source users are > > free to build their own binaries using GPLv3. > > > > -- > > Alex > > > > ____ > > From: Development > > on behalf of > > Sze Howe Koh > > Sent: Thursday, 7 June 2018 3:48:53 PM > > To: Qt development mailing list > > Subject: [Development] Is Qt for Automation available under GPLv3? > > > > Hello, > > > > According to http://doc.qt.io/QtForAutomation/qtautomation-install.html > > Qt for Automation is available under GPLv3. However, the installation > > instructions are not valid for open-source users. Furthermore, that > > page also says that Qt for Automation is built on Qt for Device > > Creation, which is commercial-only. > > > > Users are confused by that page: > > * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation > > * > > https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer > > > > Please resolve. > > > > > > Regards, > > Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Is Qt for Automation available under GPLv3?
Hello, According to http://doc.qt.io/QtForAutomation/qtautomation-install.html Qt for Automation is available under GPLv3. However, the installation instructions are not valid for open-source users. Furthermore, that page also says that Qt for Automation is built on Qt for Device Creation, which is commercial-only. Users are confused by that page: * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation * https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer Please resolve. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] To improve UX of the online installer
Thanks for chiming in, Henry. I've started filing bug reports, as Giuseppe suggested. On 3 April 2018 at 08:29, Henry Skoglund wrote: > > Hi, excellent initiative, a better MaintenanceTool UX would also improve the > general opinion of Qt I think. > > Just one to add 2 things to Sze Howe's list: > > 8c. For the users that, in search of a 32-bit MSVC2017-flavored Qt version, > downloads the UWP x86 (MSVC 2017) version of Qt, and then tries to run it on > Windows 7: please explain that the UWP stuff only runs on Windows 10. Added as part of https://bugreports.qt.io/browse/QTIFW-1125 > 11. Please make 'Update components' the default selection once you've logged > in, or 'Add or remove components'. Anything but 'Remove all components' !!! https://bugreports.qt.io/browse/QTIFW-1122 > Rgrds Henry Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] To improve UX of the online installer
On 3 April 2018 at 08:43, Jason H wrote: > I'm not involved with the installer, but 2 points. > 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's > not as optimal as a single compressed download, but it's not terrible. If > it's only 1.0, then that's a problem. Or it could be that the concurrent > connections are being limited, or the gets are just taking a fixed time to > get a response. Maybe memcached would help? I'm not familiar with the low-level details of HTTP, so I may have misinterpreted the symptoms. But judging from Eddy's and Giuseppe's posts, it sounds like MaintenanceTool is indeed being bogged down by opening one TCP connection per HTTP GET request. You can check this easily on Windows: Open Resource Monitor, go to the "Network" tab, and then start a metadata download session. The "TCP Connections" pane gets flooded with entries from MaintenanceTool.exe and the "Local Port" values increment rapidly. > 2. "Closest" mirror isn't what is important, it's speed. Though you may be > implying that the chosen mirror was still slower? It seemed that you argue > both? I'm mainly arguing that the automatic mirror selector makes bad choices for some users, which is why we need a way to manually choose our own mirror. A few years ago, I released a hack-tool to override the automatic selector: https://forum.qt.io/topic/43349/slow-downloads-with-the-online-installer-try-this-tool/ Even today, users regularly come to the forum reporting that the online installer is too slow. Even today, forum veterans recommend this tool to such users. Even today, users report that choosing their own mirror improves download speeds significantly. P.S. My impression is that the selector gives a lot of weight to "closeness" when choosing (see http://lists.qt-project.org/pipermail/development/2014-February/015614.html ). Yet, as you rightly said, "closeness" is not that important. > 3. I think the scope is ok. Qt is not a tool chain, it's a library with > tools. And the expectation is that Qt sits above the platform and compiler(s). I agree with the principle. However, you'll be amazed at how frequently new users come to the forum asking why they can't build anything. Some of them lament that it's not straightforward to install and start using Qt. I don't have any stats, but it's plausible that Qt loses a significant number of potential users simply because they install Qt the "wrong way", can't get things to work within X hours/days, and end up walking away. I think it's worth providing small guideposts if it helps increase retention rate. We don't want to be some exclusive club that's inaccessible to newbies. In any case, I'd rather spend my forum time answering questions about how to use Qt features, not helping users with basic installation woes. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] To improve UX of the online installer
3 broad issues impede new users who want to start using Qt and frustrate old users who want to update Qt: (A) Downloading metadata is very time-consuming. (B) The automatic mirror selection algorithm doesn't always pick the best mirror. (C) (New users) It's not clear how to choose what to install. == Factors that contribute to (A) include: * The metadata downloader opens lots of short-duration TCP connections. Wireshark revealed 2391 HTTP GET requests from 77.86.229.90 (download.qt.io) on Windows. This process is less painful on Linux (1205 GETs -- almost half of Windows') as there are fewer compilers/platforms. * Downloading many small files is very inefficient compared to downloading a few large files. While GET-ting metadata from download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten kibibytes). After this, the actual binaries download from my designated mirror at ~1 MiB/s, which shows that metadata downloader doesn't make good use of available bandwidth. I'm in Australia. * MaintenanceTool downloads metadata too frequently (QTIFW-975). * If the metadata download fails halfway (e.g. one file times out), the whole process needs to start from scratch. There is no retry/resume. This makes the online installer nigh unusable if the user's connection to download.qt.io is flaky: https://forum.qt.io/post/450076 * Currently, there is a way to manually avoid downloading unwanted metadata: Deselecting the unwanted Temporary Repositories. However, all 91 Repositories must be unchecked one-by-one, and this process must be repeated each time MaintenanceTool is restarted: https://forum.qt.io/post/450076 == Evidence for (B) include: * Geographical proximity does not imply mirror quality. E.g. a user from China finds Chinese mirrors too slow, and opts for non-Chinese mirrors instead: http://lists.qt-project.org/pipermail/interest/2013-December/010336.html * The algorithm doesn't pick the closest mirror anyway. E.g. a user from Israel was given a Japanese mirror instead of a European mirror: https://forum.qt.io/topic/87221/ == Examples of (C) include: * Some users don't realize there are multiple kits per Qt version. They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): https://forum.qt.io/topic/87608/windows-install-download-size * Some users don't realize Qt Creator != Qt. They install Qt Creator without Qt and end up unable to build anything: https://forum.qt.io/topic/84198/no-valid-kits-found * Some users don't realize they need to install a compiler separately. They also end up unable to build anything: https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements == Ideas for improvement (some render others unnecessary): 1. Amalgamate and compress all metadata into one file (or at least one file per "group"). 2. Cache metadata locally and use a hash to identify them; avoid re-downloading metadata that's already available (Mitch Curtis suggested this at QTIFW-975) 3. Avoid downloading metadata for archived/advanced packages by default (Iikka Eklund said this is planned in QTIFW-975) 4a. Remember the which Repositories the user has deselected before, and ignore them for future sessions. 4b. Let the user choose broad "groups" that they are interested in, and remember this choice. For example, there is no point getting metadata for Android/UWP packages or showing these packages in the "Selection Tree" if I'm only interested in Desktop development. 5. Add a "Select/Deselect All" button to the Repositories page. 6. Allow retry/resume if the metadata download fails halfway. 7. Allow users to manually pick a mirror for binary download. 8a. Before the user is asked to "Select the components to install", show a short page that to explain the difference between Qt and Qt Creator and explain that a compiler must be installed separately unless MinGW is used. 8b. Before the user is asked to "Select the components to install", have a small wizard to ask a new user some questions -- Which version(s): Latest version, LTS version, or older version? Which target platforms? Which compiler? Or do they not care/know and want us to suggest a good default? Use the answers to pre-fill the "Selection Tree" and remind the user to download an external compiler if necessary. 9. If no Qt version is selected (or if too many are selected), pop-up a confirmation dialog before installing. 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html Since (3) is already being planned, please consider (4) which is a generalization of (3). It would be fantastic to see a holistic approach that addresses (A) + (B) + (C). For example, (8b) helps the user make the right selection at the first try. At the same time, users' answers in (8b) feed into (4b) to download fewer metadata files and trim the "Selectio
Re: [Development] Qt branches & proposal how to continue with those
On 9 February 2018 at 15:54, Lars Knoll wrote: >> On 9 Feb 2018, at 07:52, Kevin Kofler wrote: >> >> André Pönitz wrote: >>> I think you need to start differentiating between Qt-without-Webengine >>> and QtWebengine. >>> >>> And maybe "we" should do that, too. >> >> I would be entirely in favor of separate (more frequent and/or more aligned >> with Chromium security fixes) QtWebEngine releases. I am already updating >> QtWebEngine in Fedora on a separate schedule from the core Qt updates (with >> the intent of delivering security updates faster), so it would not be a >> problem for me if the releases were entirely separate. And it would surely >> get security fixes delivered in a more timely manner. > > We’ve been discussing this in the past, and most people agreed that releasing > QtWebEngine on an independent schedule would be a good thing. But there’s > still a couple of things that need sorting out before that can happen, both > in the CI and how we create/package our product and SDK as well as in > QtWebengine which for example still uses private API of some other parts of > Qt. Is updating the Chromium backend alone a source- and binary-compatible act? I'm wondering if it's feasible (and desirable) to introduce "sub-patch" releases, where the only change is the updated Chromium backend -- not even bugfixes in Qt-controlled code. For example, if Chromium is updated between Qt 5.10.0 and Qt 5.10.1, then: 1. Branch off the v5.10.0 tag (call it the "5.10.0-x" branch, for Chromium updates only) 2. Update Chromium in 5.10.0-x and release "Qt WebEngine 5.10.0-1" 3. Merge 5.10.0-x into 5.10 The idea is to provide security updates in a timely manner, without: * Worrying about private API breakages * Requiring a full-blown Qt release * Making Qt WebEngine's version numbering go out of sync with the rest of Qt This approach would be most beneficial for a non-LTS branch, least beneficial for an LTS branch in "Very Strict" mode. I thought this might be an easy option since Qt WebEngine is already listed as a separate component in the Qt installer (please correct me if I'm underestimating something in the process). Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandon changes set on Gerrit
On 7 January 2018 at 13:04, Igor Mironchik wrote: > Hello, > > I see a button "Abandon Change" under the last patch set. Does this button > abandon all changes set or only the last patch set? > > I want to abandon whole changes set. > > Thank you. That button abandons all the patch sets with that Change-Id. Don't worry, if you make a mistake with that button, you can still un-abandon it. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Contributing to Qt
On 30 Dec. 2017 16:12, "Igor Mironchik" wrote: Hello, I want to contribute a little to Qt. I cloned qtbase from git://code.qt.io/qt/qtbase.git Created branch with git branch test git checkout test made changes git commit -a Great but now I have a question: how should I correctly push my changes? Provide a working example please. Thank you. Hi Igor, The short version is: You need to set up your Gerrit account, add Git hooks, and and configure your local repository to use the Gerrit remote repository. Push your commits to the remote repository. The exact details are a bit long. To get started, read through https://wiki.qt.io/Qt_Contribution_Guidelines and https://wiki.qt.io/Setting_up_Gerrit Note: If you use the "init-repository" Perl script from qt5.git, it will automatically set up the Git hooks and the remote repo for all Qt 5 repos (not just qtbase.git). If you don't use this script, you will need to manually configure every repo. Finally, since this thread is about contributing to Qt, let's continue this discussion at development@qt-project.org (remove inter...@qt-project.org when you reply) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository request: Qt KNX and Qt KMQTT
On 9 October 2017 at 13:53, Alex Blasche wrote: > >>We would like to have two new repositories created to share the code publicly. >>Name of the project: Qt KNX >>Name of the project: Qt MQTT > > +1. Please add the repos to https://wiki.qt.io/Maintainers. I've added the repos to https://wiki.qt.io/Spelling_Module_Names_in_Qt_Documentation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 logging/tracing session notes
On 11 October 2017 at 03:49, Thiago Macieira wrote: > > On Tuesday, 10 October 2017 20:18:42 CEST Mat Sutcliffe wrote: > > On 10 October 2017 at 15:28, Thiago Macieira > > > > wrote: > > > On Tuesday, 10 October 2017 15:12:52 CEST Christian Gagneraud wrote: > > > > (PS: I don't even know if qDebug streaming is lock-free and i'm > > > > interested to know the answer:)) > > > > > > It's not. There are mutexes inside. > > > > The SO answer and its comments claim that qDebug is not even thread-safe: > > https://stackoverflow.com/a/7154385/1639256 > > SO is wrong. https://stackoverflow.com/questions/22527253/is-qdebug-thread-safe/23517726#23517726 shows an example: The program called qDebug() from 2 threads. As a result, part of output from one call to be inserted in the middle of the output of another call. This was tested with Qt 5.2.1 -- has something changed since then? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSH access to gerrit with debian sid
On 9 October 2017 at 21:02, Orgad Shaneh wrote: > Hi, > > Recent changes in debian openssh packages cause errors when negotiating > ciphers with qt-project gerrit. > > To enable connection, you need to add the following in ~/.ssh/config > > Host codereview.qt-project.org >Ciphers +aes256-cbc > > I added this to Setting up Gerrit wiki page, it waits for moderator > approval. > > - Orgad Thanks, approved. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Introducing discussion about QStringFormatter
later..
> - e.g. `{:<10:this is the extra field}`
> - or `{::-MM-dd HH:mm:ss}`
>
> Currently the formatting options can come in any order (e.g. "L<10"
> and "<10L" does the same, the only exception being ':').
> However it would be good to enforce some sort of order for the sake
> of consistency. With a defined order we could also change
> justification format from [<>=]cn to c[<>=]n, which would allow
> people to use 1-9 as a fill-character. If this is done, what should
> the order be like?
>
> QString::arg compatibility
> -
>
> Currently QString::arg compatibility is activated using a parameter
> in the constructor. All this does is let you use %nn style tokens and
> 'disable' use of the brace-style tokens. It also supports `%L` to
> enable localization of numbers, but any other formatting must be done
> using the `QStringFormatter::Formatting` class.
>
> API for formatting custom types
> -
>
> One idea I've been experimenting with a little bit is using template
> specialization to deal with formatting custom types. To support a
> custom type you'd create a specialization of a struct called
> `Formatter`. It would use the `extra` field in `Formatting` which
> you could optionally parse for custom formatting options. The parser
> would be a separate class inheriting `Formatting` and be specified in
> the Formatter using a typedef.
>
> E.g.
> `struct QStringFormatter::Formatter
> {
> typedef DateTimeInfo FormatType;
> QString operator()(const QDateTime &dateTime, const FormatType &format);
> }`
>
> `QStringFormatter` will then instantiate this struct when it receives
> a `QDateTime` object, and create a `FormatType` object to parse the
> data located in the `extra` field of formatting options. The
> `FormatType` object is then expected to store whatever info it needs
> and then the `Formatter` will use it later.
>
> Feedback on the approach, pitfalls etc. is much appreciated!
>
> Thanks,
>
>
> -- Mårten Nordheim
Regards,
Sze-Howe Koh
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Denis Shienkov for Approver status
On 6 July 2017 at 14:36, André Hartmann wrote: > > I'd like to propose the nomination of Denis Shienkov for Approver > status. > > Denis has been the maintainer of QtSerialPort for a long time now. > He also formed the architecture of QtSerialBus and provided several CAN > plugins there. He further contributes to other parts of Qt and QtCreator and > is actively reviewing other changes (for example he has constructively > improved a lot of my changes to QtSerialBus). > > This is his own Gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > And these are his reviews: > > https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > Best regards, > André +1 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc)
On 15 June 2017 at 01:29, Tuukka Turunen wrote: > Hi, > > Yes, we would like to overall improve the examples. This is related to having a new repo for examples, but not fully the same thing. Main goal in example improvement being to make them more useful in what they are: examples of how to use Qt. Currently there are some examples that implement their own rudimentary controls instead of using Qt Quick Controls 2. We also have some examples that do not properly leverage our tooling. Some examples might not show the very best way to do things, as the new APIs allow even better way than at the time of creating the example. > > What comes to WOW, we do need to have great looking demos and at least some examples should look good as well. However, that WOW should not be the ultimate goal. The purpose of examples is to help users make better use of Qt and sometimes making things too shiny can be counterproductive. Another thing is that this WOW is a quite subjective matter and different trends come and go. It is fine to make an example look great, but that should not be the sole purpose. > > Yours, > > Tuukka Understood. On the topic of showing users "how to use Qt" and "leverage our tooling", I feel that our "getting started" tutorials/examples need some love too. IMHO, the "Getting Started" tutorial from Qt 4.3 ( https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the Qt 4.3 tute presents material in digestible chunks. Readers are introduced to the bare bones, and get to compile and interact with their code very early on. Then, the tute gradually introduces more and more concepts across a number of chapters; each chapter builds upon the previous. The reader gets to build and try out the new concepts in each chapter, before moving on to the next. In contrast, the Qt 5 tutorial takes the reader through a multitude of concepts (Qt Designer, the UIC file format, the *.pro file, subclassing widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and many different classes) before the reader is taught how to compile and run their first app. If the reader made a mistake somewhere along the way, it's hard to find out where. There is far too much material packed into a single "getting started" article. I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters 1 - 7) for Qt 5, presented in a few different ways to show how to do the same thing using different Qt technologies: 1. C++ only 2. C++ with Qt Designer 3. QML only 4. QML with Qt Quick Designer Is this something you'd want in the official documentation? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Examples and Demos in qtdoc
On 14 June 2017 at 19:18, Frederik Gladhorn wrote: > > Hi all, > > We recently had a discussion in the Qt Company about how we can improve the > first use experience of Qt and one important aspect are the examples and > demos. +1 > We have a lot of examples that are limited by the Qt module they live in, for > example not making use of ready made buttons in Qt Quick. To allow examples to > use any Qt module while keeping the build system clean (no cyclic dependencies > between modules), I'd like to propose using the qtdoc module to gather fresh > and beautiful examples. > > We currently have a few bigger examples already that would fit this category > and plan to invest more into good looking nice and welcoming examples to give > new Qt users a positive first impression. Fresh and beautiful is good. Does this initiative also involve cleaning up existing examples (including removing them, where appropriate)? For example, the old rendering at http://doc.qt.io/qt-5/qtquick-scenegraph-textureinsgnode-example.html would detract from the nice and welcoming bits on display. One reason to avoid a large-scale cleanup, though, is to avoid link rot. > Of course we could create a new repo, but considering that we have an existing > repo which did contain the demo launcher previously and which is ready to be > used, I'd propse going with it, while the name is not perfect. It's already > part of the infrastructure and qt5.git, so this seems like an easy way to go > forward. qtdoc.git currently houses a number of non-flashy but nonetheless important examples and documents (e.g. signals and slots, platform notes). Would it be better to keep a separate repo for wowing newcomers (say, "qtshowcase.git")? Especially since there will be many large files involved, as Sean mentioned. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] List of available Qt mirrors
A user from China has reported that the Chinese mirrors are no longer visible to him [1]. I also don't see any when I visit http://download.qt.io/online/qtsdkrepository/windows_x86/root/qt/Updates.xml.mirrorlist (from Australia) Now, from my experience (which is a few years old and possibly outdated), the Chinese mirrors tend to perform quite poorly, even for users within China [2]. Nonetheless, I'm still surprised to see that they have vanished from the list; at least one server seems up to date [3]. Is this behaviour expected? Has the mirror management system been updated to hide mirrors that don't meet certain performance criteria or something like that? Regards, Sze-Howe [1] https://github.com/JKSH/QtSdkRepoChooser/issues/5 [2] http://lists.qt-project.org/pipermail/interest/2013-December/010336.html [3] http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Documentation typo fixes
On 24 February 2017 at 06:08, Ch'Gans wrote:
>
> Hi guys,
>
> Who do I need to invite as reviewers for these typo fixes?
> https://codereview.qt-project.org/186292
>
>
> Thanks,
> Chris
Hi Chris,
I'm happy to review documentation patches.
> On 8 February 2017 at 11:03, Ch'Gans wrote:
> > On 7 February 2017 at 23:18, Edward Welbourne
> > wrote:
> > [...]
> >>
> >> Sze Howe Koh (7 February 2017 04:35) replied:
> >>> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories
> >>> don't have a "master" branch)
> >>>
> >>> Right now, the branches that accept documentation fixes are:
> >>>
> >>> * 5.8 (stable branch)
> >>> * 5.9 (next release branch)
> >>> * dev (development branch)
> >>>
> >>> Simply put, patches will merge from the top of the list to the bottom
> >>> of this list. For example, patches that go into "5.8" will eventually
> >>> be merged into "5.9", which in turn will eventually be merged into
> >>> "dev".
> >>>
> >>> Typo fixes are not new features or major/risky changes, so they can go
> >>> into the stable branch ("5.8").
> >>
> >> Indeed. This is all being formalised in QUIP 5:
> >> https://codereview.qt-project.org/178906
> >> where you can find out all you wish to know about which changes should
> >> go to which branches,
> >
> > Thanks both of you for the information.
> > Chris
> >
> >>
> >> Eddy.
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Documentation typo fixes
On 7 February 2017 at 08:39, Ch'Gans wrote:
>
> Hi there,
>
> It's been a while that I notice some typos here and there in Qt5
> documentation (mainly qtbase), and i decided that i would start
> correcting them in the source code.
> Most of them are really straight forward, eg. in QGraphicsView::setTransform:
> "To simplify interation with items using a transformed view, ..."
> should be:
> "To simplify interaction with items using a transformed view, ..."
>
> It's just one example from this morning. Not a big of a deal, but
> documentation looks always nicer without typos.
>
> I would like to know to which branch should i target such "code
> review" on gerrit.
> Should it be "Current release", "Next release", "dev" or "master"?
> My gut feeling tells me "dev", so that from there, maintainers can
> decide if they want to propagate or not.
> Could someone confirm this?
>
> Thanks,
> Chris
Hi Chris,
Thank you for helping to fix typos.
See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories
don't have a "master" branch)
Right now, the branches that accept documentation fixes are:
* 5.8 (stable branch)
* 5.9 (next release branch)
* dev (development branch)
Simply put, patches will merge from the top of the list to the bottom
of this list. For example, patches that go into "5.8" will eventually
be merged into "5.9", which in turn will eventually be merged into
"dev".
Typo fixes are not new features or major/risky changes, so they can go
into the stable branch ("5.8").
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
On 30 Nov. 2016 04:04, "Thiago Macieira" wrote: > > On terça-feira, 29 de novembro de 2016 20:17:23 PST Sergio Ahumada wrote: > > > Say what? Why not? > > > > I think he meant that you can't add new stuff .. say if you have a > > iOS-only offline installer, then you can't use that maintenance tool to > > install the android stuff .. you would need to download the android-only > > offline installer to install android (which, if it hasn't been fixed, > > will install a second instance of QtCreator) > > I got it that you can't do it today. > > The question is why we haven't fixed that. Sounds like a reasonable feature: > you download the offline once and you only use the maintenance tool to update. There's a related discussion at https://bugreports.qt.io/browse/QTBUG-32122 > And if you can't even share the same Qt Creator installation, then it's an > important bug. Yep, we can't even share the same Qt Creator installation: https://forum.qt.io/topic/36275/how-to-install-multiple-qt-5-2-versions-on-windows-using-offline-installers > > that's why (AFAIR) the offline installer has everything > > (desktop+ios+android), if you only want iOS, then you unselect Android > > and problem solved > > Right, but that's upside down. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stack Overflow Documentation
On 21 July 2016 at 19:04, Mitch Curtis wrote: > Hello. > > Stack Overflow Documentation is now in Beta. You can read more about it here: > > http://stackoverflow.com/tour/documentation > > It is much more accessible than our contribution system, so I see a lot of > documentation/example contributions going there instead of to Gerrit. > > I also wonder if we should consider the popularity (i.e upvotes) of the pages > there when we decide which examples to create and add to our documentation. That makes sense to me. Another similar metric is how often a question gets asked at our forum, although this is a bit hard to count. > I wonder if the licensing is such that the frameworks like Qt can benefit > from the content by "upstreaming" it into their own documentation. According to your link, Stack Overflow Documentation contributions are licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0. We'll need a legal expert's input to be sure, but from what I understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3... (Perhaps we can ask Stack Overflow for an exception?) > I'm interested to hear what others think about this. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Input events handling ideas and feedback
On 27 June 2016 at 17:28, Uwe Rathmann wrote: > > On Mon, 27 Jun 2016 08:39:42 +, Shawn Rutledge wrote: > > > We have mostly stopped working on QtQuick Controls 1, because the > > implementation of Controls 2 is much more performant ... > > Controls 2 are for "embedded" - what at least means to me: not being for > desktop applications. > > > It was achieved by implementing behavior in C++ ... > > ... and by dropping desktop specific features. > > But does your statement imply, that Qt development has mostly given up QML > as a technology for the desktop ? > > If true, was it done because of: > > a) seeing Controls 1 as complete and satisfying > b) something is wrong with the implementation of Controls 1 > c) the overhead of QML is too big for such large projects > d) nobody is interested in the desktop at all > > And what is recommended for us users: better starting off with widgets > for new desktop applications ? > > Uwe Hi, I suggest reading the comments section of https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/ for detailed comments about Desktop support. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Scope of source code license files
On 7 May 2016 at 12:20, Joseph Crowell wrote: > > On 4/05/2016 7:39 PM, Lars Knoll wrote: >> >> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" >> > szehowe@gmail.com> wrote: >> >> >> >>> Hello, >>> >>> The LICENSE.GPLvX and LICENSE.LGPLvX files from >>> http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with >>> "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say >>> "You may use, distribute and copy the Qt GUI Toolkit under the terms >>> of..." >>> >>> Is this correct? What about non-GUI parts of the toolkit? >> >> The GUI in here is just a historical thing. It applies to Qt. > > > Wording should probably should be changed then as times have changed and Qt > is certainly no longer just a GUI toolkit. Here's the first batch, targeting the "5.6" branch. If this is OK, I'll submit similar patches for the other repos too: https://codereview.qt-project.org/#/c/162394/ Some more questions: 1) What about http://code.qt.io/cgit/qt/qtbase.git/tree/LGPL_EXCEPTION.txt ? It's currently presented as additional permissions on top of LGPL v2.1. I presume LGPL v3.0 should be included too? 2) https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ says that "Qt 5.7 will not be available under LGPLv2.1 anymore" -- Does that mean LICENSE.LGPLv21 should be removed from the 5.7 branch onwards? >> Cheers, >> Lars Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] doc.qt.io: Camel-case URLs have stopped working
Hello, One month ago, URLs that contain proper class names, e.g. http://doc.qt.io/qt-5/QObject.html, worked as expected. However, they now lead to Error 404. It looks like the server currently allows lowercase URLs only, e.g. http://doc.qt.io/qt-5/qobject.html This change might break bookmarks or links from external sources. Any chance of restoring the old behaviour? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Scope of source code license files
Hello, The LICENSE.GPLvX and LICENSE.LGPLvX files from http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say "You may use, distribute and copy the Qt GUI Toolkit under the terms of..." Is this correct? What about non-GUI parts of the toolkit? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Doc: Making it easier for devs to know if a class is supported on a given platform
Hi all, With the proliferation of supported platforms and add-on modules, we now have a situation where some classes are only useable on particular platforms. There've been cases where a developer sees a class in the Qt docs and thinks "Ooh, this is just what I need!", only to find out (after spending time studying examples and writing code) that the class can't be used on their platform of interest. [1] It would be nice to help them find out earlier whether a class is available or not. We currently have some documentation, e.g. http://doc.qt.io/qt-5/qtmodules.html lists "Target Platforms" for add-on modules. However, a user who finds the class ref via a search engine might miss this. One idea is to add a "Target Platforms" row in the class reference, below the "Header", "qmake", and "Inherits" rows. qdoc could populate this for each class based on info provided about the module. However, we have a situation in Qt Multimedia where the module is broadly available, but particular features are not: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is available on iOS but QAudioProbe is not. The previous idea for an auto-populated "Target Platforms" row would be erroneous in this case. Perhaps we could have a per-class "\supports" qdoc command, or even manually type in a line saying "This class is (not) supported on _"? (I'm happy to spend time doing this, but it's not a very maintainable solution) Any other thoughts/ideas? (I haven't thought through QML types yet) Regards, Sze-Howe [1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Minimum Deployment Platforms for 5.7 onwards?
On 9 January 2016 at 01:05, John Layt wrote: > > On 8 January 2016 at 07:18, Turunen Tuukka > wrote: >> >> >> >> Hi John, >> >> >> >> This item was discussed at Qt Contributor’s Summit, please see session >> notes: http://wiki.qt.io/QtCS2015_LTS >> >> >> >> For compilers this is also documented to the Qt Base change log: >> http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 >> >> >> >> For 5.6 the current list of supported platforms and compilers is the >> following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are >> working to add OS X 10.11 to CI and fully support it) >> >> >> >> The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older >> (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent >> versions. Those who have such older platforms to support, are recommended to >> stay with the LTS version for a while. This approach allows us to move >> faster for new features planned for future Qt releases. >> >> >> >> For application developers the documentation is often the best source to >> find the list of supported platforms: >> http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been >> updated to 5.6, but will be before the final release. > > > Thanks Tuukka, but that's all a bit messy and hard to work out (not to > mention the LTS email threads here which are impossible to follow). It makes > my point really that there's no one canonical source telling us Qt > contributors what platforms we need to design or code features for in the > next Qt release, or for fixes in the last bug release. I need to know what > versions of the platform API's I can use, not what's Official, Reference, CI, > or Community supported. > > I've taken the liberty of starting a wiki page to try summarise things the > way I'd like to see them laid out: > > https://wiki.qt.io/PlatformSupport > > Feel free to edit or fix or move to a more appropriate place. > > John. Thanks for creating this summary, John. Would you be willing to merge your content into this existing page? https://wiki.qt.io/Supported_Platforms Regards, Sze-Howe https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"; target="_blank">https://ipmcdn.avast.com/images/logo-avast-v1.png"; style="width: 90px; height:33px;"/> This email has been sent from a virus-free computer protected by Avast. https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"; target="_blank" style="color: #4453ea;">www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Old platform-specific functions
On 10 October 2015 at 11:06, Sze Howe Koh wrote: > > On 16 September 2015 at 15:46, Jake Petroules > wrote: > > > On Sep 15, 2015, at 9:07 PM, Sze Howe Koh wrote: > > > > > > Hi all, > > > > > > There's a list of platform-specific functions from Qt 4: > > > http://doc.qt.io/qt-5/exportedfunctions.html > > > > > > It looks like most of these functions are now gone. The non-existing > > > functions should be removed from the documentation, but 3 functions > > > remain in the code base: > > > > > > * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC > > > (qlineedit.cpp) > > > > > > Maybe introduce a new function in QPA, exposed through QtMac namespace in > > QtMacExtras? > > > > > * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for > > > removal in Qt 6 (qmenu.h) > > > > > > Replaced by QMenu::setAsDockMenu > > (http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu) > > > > > * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any > > > way. > > > > > > Maybe introduce a new function on QShortcut that takes an enum (Auto, On, > > Off)? > > > > > > > Should any of these be left in the documentation? (Note that > > > qt_set_sequence_auto_mnemonic() is currently documented as a way to > > > get non-standard behaviour on OS X: > > > http://doc.qt.io/qt-5/qshortcut.html#details ) > > > Thanks for your input, Jake. I'll leave the decision about new > functions to the folks involved in GUI code; I'll just update the > documentation to reflect the current situation: > > https://codereview.qt-project.org/127249/ > https://codereview.qt-project.org/127250/ > https://bugreports.qt.io/browse/QTBUG-48693 > https://bugreports.qt.io/browse/QTBUG-48694 Bump. Would someone be willing to review and approve https://codereview.qt-project.org/127249/ ? (The other one has merged) Thanks, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.1 Download Problem
On 16 October 2015 at 05:50, Samuel Gaist wrote: > > On 15 oct. 2015, at 19:12, Giuseppe D'Angelo > wrote: > >> Il 15/10/2015 19:06, Volny ha scritto: >>> Same on Linux. >> >> It's https://bugreports.qt.io/browse/QTBUG-48781 , no idea about an ETA. You >> could try redownloading until you get a good mirror :( >> >> HTH, >> -- >> 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 >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Or use https://github.com/JKSH/QtSdkRepoChooser Hi, I'm the creator of the Qt SDK Repo Chooser. Unfortunately, the online installer no longer seems to honour my chosen repo. I'm not sure if this is caused by changes from Qt IFW 1.x to Qt IFW 2.x, or the change from qt-project.org to qt.io. This tool is based on Tim Jenssen's hack at http://lists.qt-project.org/pipermail/interest/2013-December/010341.html -- could a Qt IFW engineer please shed some light on this? Thanks, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Old platform-specific functions
On 16 September 2015 at 15:46, Jake Petroules wrote: > > On Sep 15, 2015, at 9:07 PM, Sze Howe Koh wrote: > > > > Hi all, > > > > There's a list of platform-specific functions from Qt 4: > > http://doc.qt.io/qt-5/exportedfunctions.html > > > > It looks like most of these functions are now gone. The non-existing > > functions should be removed from the documentation, but 3 functions > > remain in the code base: > > > > * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC > > (qlineedit.cpp) > > > Maybe introduce a new function in QPA, exposed through QtMac namespace in > QtMacExtras? > > > * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for > > removal in Qt 6 (qmenu.h) > > > Replaced by QMenu::setAsDockMenu > (http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu) > > > * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any > > way. > > > Maybe introduce a new function on QShortcut that takes an enum (Auto, On, > Off)? > > > > Should any of these be left in the documentation? (Note that > > qt_set_sequence_auto_mnemonic() is currently documented as a way to > > get non-standard behaviour on OS X: > > http://doc.qt.io/qt-5/qshortcut.html#details ) Thanks for your input, Jake. I'll leave the decision about new functions to the folks involved in GUI code; I'll just update the documentation to reflect the current situation: https://codereview.qt-project.org/127249/ https://codereview.qt-project.org/127250/ https://bugreports.qt.io/browse/QTBUG-48693 https://bugreports.qt.io/browse/QTBUG-48694 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Old platform-specific functions
Hi all, There's a list of platform-specific functions from Qt 4: http://doc.qt.io/qt-5/exportedfunctions.html It looks like most of these functions are now gone. The non-existing functions should be removed from the documentation, but 3 functions remain in the code base: * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC (qlineedit.cpp) * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for removal in Qt 6 (qmenu.h) * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any way. Should any of these be left in the documentation? (Note that qt_set_sequence_auto_mnemonic() is currently documented as a way to get non-standard behaviour on OS X: http://doc.qt.io/qt-5/qshortcut.html#details ) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Documentation proposal: Remove recommended reading list of 20-year-old books
On 30 August 2015 at 16:32, Hausmann Simon wrote: > I think that there is a big difference between it being easy enough to find > reading material and us - the project - making specific recommendations for > material that we think is of particularly high quality and perhaps also > relevance. The latter adds real value to our documentation. > > I think that if there is evidence that the currently suggested material is > not suitable anymore, then it would be great to replace it with another > recommendation. That's fair enough. I think the recommendation has been "backwards" for a long time now. It basically says, "Beginners should read these platform-specific books on multithreading, before reading the Qt documentation on multithreading". However, the Qt docs already explains the basics in a way that doesn't assume prior knowledge. If we're to replace the recommendation, I would (i) present it as "further reading", not "recommended reading before starting", and (ii) pick a book that showcases C++11 threads, not the low-level platform-specific threads. If someone has personally found a particular book very helpful in this topic, I'd be happy to add it. Otherwise, I'll proceed as originally planned. We have 3 votes for removal (including my own) and 2 votes for replacement. > Original Message > From: Sze Howe Koh > Sent: Sunday, August 30, 2015 09:49 > To: development@qt-project.org > Subject: [Development] Documentation proposal: Remove recommended reading > list of 20-year-old books > > > Hi all, > > http://doc.qt.io/qt-5/threads.html#recommended-reading points readers > to some books about multithreading. These books were published between > 1995 and 1997, and have been well and truly superseded by newer ones. > > Rather than update the list, I plan to remove it completely. I don't > think this list belongs in the Qt docs, just like how we don't > maintain a list of "learning C++" books. It's easy enough these days > to find reading material for these foundational topics. > > Any objections? > > > Regards, > Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Documentation proposal: Remove recommended reading list of 20-year-old books
On 30 August 2015 at 16:02, Dmitry Volosnykh wrote: > By the way, what are those "newer ones"? I don't have a specific book in mind, but I would encourage newcomers to learn the high-level API introduced in C++11 (std::thread, std::async, etc.) instead of the low-level, platform-specific API currently recommended by the Qt docs (pthreads/Win32 threads). The former is much cleaner and more portable (assuming the platform toolchains are C++11 compliant). I'd only recommend books on pthreads/Win32 threads to people who need/want in-depth details about those APIs. > On Sun, Aug 30, 2015 at 10:48 AM, Sze Howe Koh > wrote: >> >> Hi all, >> >> http://doc.qt.io/qt-5/threads.html#recommended-reading points readers >> to some books about multithreading. These books were published between >> 1995 and 1997, and have been well and truly superseded by newer ones. >> >> Rather than update the list, I plan to remove it completely. I don't >> think this list belongs in the Qt docs, just like how we don't >> maintain a list of "learning C++" books. It's easy enough these days >> to find reading material for these foundational topics. >> >> Any objections? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Documentation proposal: Remove recommended reading list of 20-year-old books
Hi all, http://doc.qt.io/qt-5/threads.html#recommended-reading points readers to some books about multithreading. These books were published between 1995 and 1997, and have been well and truly superseded by newer ones. Rather than update the list, I plan to remove it completely. I don't think this list belongs in the Qt docs, just like how we don't maintain a list of "learning C++" books. It's easy enough these days to find reading material for these foundational topics. Any objections? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enginio version and branch names
Hi, On 20 August 2015 at 15:31, Frederik Gladhorn wrote: > > Hello all, > > To make dealing with Enginio a bit easier (I get asked for the right version > number for each release and keep being confused myself since it doesn't see > much activity), I will change the future branch names and version number. > > As you know we cannot change the major version as that is not binary > compatible, so the major .so version will stay at 1. But we can align the rest > of the version to Qt release versions. > > Branches: > follow Qt branches: 5.6, 5.6.0, etc > > Version numbers: > follow Qt in minor and patch: 1.6.0 will be released with Qt 5.6.0. What do you think of applying this system to the Qt Quick related modules too? See https://wiki.qt.io/Qt_5_Structure -- the current set of version numbers is rather chaotic. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)
Hi,
In general, I think we should give higher priority to API simplicity
and flexibility, and lower priority to implementation simplicity.
Note that the QML Dialog is different from the C++ QDialog. QDialog
has no standard buttons of its own. Rather, it's up to the user to
manually add buttons, or to add a QDialogButtonBox (which might be a
better place to attach the "button proxy/delegate" described in
several of the approaches below). I think the C++ way provides better
separation of concerns, where QDialog manages the popup window itself
and reports the user's choice(s), while QDialogButtonBox manages the
buttons (something to consider for Qt Quick 3?)
On 22 August 2015 at 07:22, Vladimir Moolle wrote:
>
> Hi, I’d like to discuss approaches to API design in the context of
> https://bugreports.qt.io/browse/QTBUG-47850 (making Quick Controls dialogs’
> standard buttons’ enabled properly state accessible).
>
> It seems, that the desired properties of an API implementing the above would
> be:
> possibility to declaratively manipulate enabled-ness of the buttons
> lack of risks brought by “signal races” (usually happens when imperative and
> declarative code is mixed)
> optionally, possibility to tweak more than just the “enabled” property of the
> buttons (at least the API could allow for such extension in the future).
+1
> Below are some approaches coming to mind (after a discussion we had with
> colleagues):
>
> 1. A getter method on Dialog, more or less duplicating that of the QDialog.
> Pros are the API (and the patch implementing it) being trivial. Cons are
> necessity to call the getter only after the button is created (by otherwise
> declarative code) and complexities of button lifetime tracking.
I strongly dislike this. I think imperative methods should be a last
resort in QML, instead of the first thing we turn to.
(Note also that QDialog has no getters/setters for button states)
> 2. A set of applyEnabled, helpEnabled, … properties on the Dialog. Pros is
> being declarative and API simplicity, cons is the obvious verbosity
> (especially, if more properties are exposed this way later).
This seems a bit unsustainable.
> 3. An enabledButtons (disabledButtons? disabledStandardButtons?
> enabledStandardButtons??) property containing an ORed set of button roles
> (just like the standardButtons property). Pros are things being declarative,
> and uniform, cons -- that crafting a binding expression for more than a
> couple buttons may get ugly (and listening / responding to changes through
> the single QML signal handler may require having a signal parameter matching
> the old / previous state of the ORed enum combo -- which is strange; note:
> something close is discussed by
> https://bugreports.qt.io/browse/QTBUG-40868?focusedCommentId=253265)
This could work. We have something similar in Window.flags
(http://doc.qt.io/qt-5/qml-qtquick-window-window.html#flags-prop)
Is it necessary to have a signal parameter that reports the old state?
AFAIK, most stateChanged()/valueChanged() signals in Qt only report
the new state/value.
> 4. An auxiliary object can be used to make the buttons accessible
> declaratively:
> Dialog {
> StandardButtonProxy {
> id: okProxy
> role: StandardButton.Ok
> Binding {
> target: okProxy.button // here it is
> property: “enabled”
> value:
> }
> }
> }
> Pros of this approach would be its simplicity (on both API and implementation
> sides), and relative safety (the “button” property would be null when the
> button is not there, incl. temporarily -- i.e. during button model
> reorganizations, etc.), cons -- that it would be merely a means to expose
> standard buttons “the QML way”, not addressing the fact that exposing control
> instances from underneath may not be the best practice by itself (and
> especially in QML, where a smart user may try to save the reference, thus
> confusing the GC).
This is the QML way of achieving how dialog buttons are currently
managed in C++.
I currently haven't worked out if I'm for or against this.
> 5. A special ButtonState object type serving as “declarative proxy” for the
> button’s properties, i.e.:
> Dialog {
> <...>
> ButtonState {
> role: StandardButton.Ok
> enabled:
> }
> }
> Pros of this approach would be “proper” declarativity, and ability to easily
> extend the exposed property set (adding possibility to override other
> properties other than “enabled”), cons would be limiting further API changes
> in this area to being based on this one-way “reflect my properties” approach
> (and making some bindings track the state of the button by default would
> complicate things beyond reasonable).
I don't quite understand the cons you've mentioned. Could you please
explain why would it be one-way? Couldn't we do something like this?:
Dialog {
ButtonState {
id: okButtonState
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On 28 July 2015 at 15:28, Olivier Goffart wrote: > On Monday 27. July 2015 10:03:25 Thiago Macieira wrote: >> The whole thinking is that the use of operator<< for QString implies you're >> trying to figure out why that string is the way it is, as opposed to trying >> to convey a message. > > I think that's where the disagreement is. > > I would think the use of operator<< for QString is just trying to figure out > WHAT is that string. > > Most of the code looks like > qDebug() << "There was an error processing XYZ: " << job->errorString(); > qDebug() << "Error parsing file: " << fileName; > qDebug() << "User entered: " << searchLineEdit->text(); I certainly do this a lot. My main use cases are: * (During development) To track the flow of my code, when breakpoints and stepping are too slow. * (In production) To generate human-readable logs There are many use cases for qDebug/qCDebug that are very different from the use case in Qt Test that triggered this change. Yes, Qt Test needs to unambiguously output NON-printable characters to show the developer where the strings are mismatched. However, please remember users who want to read printable characters without having to bloat their code with qUtf8Printable(). (One reason I prefer qDebug over std::cout is because qDebug is so much cleaner; requiring qUttf8Printable() everywhere kills this advantage if English is not my main language) Furthermore, there was a recent argument against replacing Qt XML's backend which is relevant here too: "...you may *fix* bugs that people are accidentally depending on; or the simple fact of a change in behaviour could result in existing code getting broken." [1] > Imagine that in a app written in russian for russian, or in other languages. > You really want to know what is the error message or the file name. > > I use qDebug a lot, and I don't recall a single time I had problems with > homoglyph. However I already was annoyed by the Qt 5.5's escaping. > > So if you ask my opinion, I think this regression should be fixed in Qt 5.5.x. +1. I do agree with Thiago's rationale of removing ambiguity and inconsistency in qDebug. However, given that the change "breaks" (or provides "unwelcome fixes" to) lots of existing code, the old behaviour should be kept as default IMHO. Regards, Sze-Howe [1] http://permalink.gmane.org/gmane.comp.lib.qt.devel/22647 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Avoid overloading of 'error'
On 16 June 2015 at 19:28, Kurt Pattyn wrote: > Well, > > you can also think of “on” + , like in: onWindowClosed, > onMouseClicked, onBytesReceived, … > In the same analogy, you could have onErrorOccurred. > > Seems very intuitive to me. > > It depends if you want to react to a state or to the event causing that state. The QML spec says "on" + , not : http://doc.qt.io/qt-5/qtqml-syntax-signals.html#receiving-signals-with-signal-handlers You can call connect() on the thing after "on": http://doc.qt.io/qt-5/qtqml-syntax-signals.html#connecting-signals-to-methods-and-signals The thing after "on" is also exposed to C++ as a signal; it can be passed to QObject::connect() in the SIGNAL() macro. So, we need to use signal names (which are past tense verbs). Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some Qt3D feedback
First, a big thanks to Stephen for bringing these issues to the ML's attention. The topic of namespacing has been raised a few times before, but discussions faded without us reaching any solid conclusions: http://comments.gmane.org/gmane.comp.lib.qt.devel/13176 I think the disagreements we have on this topic stem from the desire to uphold two different values that tread on each others' toes a bit: * Progress (related to replacing old things with new and better ones) * Consistency (related to familiarity and intuitiveness) Let's aim to achieve both without unnecessarily sacrificing either. This means being willing to try new things, but also means applying the findings from these trials to the entire Qt framework as uniformly as possible. On 12 June 2015 at 16:21, Sean Harmer wrote: > On Thursday 11 June 2015 23:15:20 André Pönitz wrote: >> Specifically, for item #6: >> >> [Stephen] >> >> > Qt3DParamter might be better *and* more consistent. >> > Similar applies to other classes. >> >> [Sean] >> It's precisely because of these kinds of issues that we decided to use >> namespaces in Qt3D rather than the poor-man's prefix name spacing. >> [...] >> Name spaces are supported everywhere these days so why not just use >> them, especially in a new add-on module? >> >> That's exactly the kind of situation I was referring to in my previous >> mail: This is *intentionally* introducing API inconsistency. It does not >> really matter to me whether "poor-man's prefix name spacing" is >> unfashionable or "we" consider it bad. It is simply *inconsistent* with >> more than 200 of existing exported QQuick*, QSG* and QQml* classes. > > The majority of those QQuick*, QSG*, and QQml* classes are not exported or > documented as internal so the 200 number is overstated. > > Also, as Marc pointed out, those class names are themselves inconsistent with > other classes within QtCore, QtNetwork, QtGui etc. As I replied earlier, once > you add a using namespace Qt3D to a translation unit the Qt3D actually looks > more consistent with other parts of Qt than using QQuick* etc. with the > proviso that you need to disambiguate in the case of collisions. > > Furthermore, it is inconsistent to want to push forwards with the allowable > set of C++ 11/14/whatever features which will mean dropping support for older > compilers and platforms, yet denying the ability to evolve our API beyond the > 1990's paradigm. Dropping support for older compilers is a much harder pill to > swallow than asking people to use a namespace in a new addon module. > > I'm not arguing that namespaces should be used because they are fashionable. > I'm arguing they should be used because this is the intended use case of a > very mature language feature. If we can't try new things out in new addon > modules, then where can we try them? I agree that we should try new things to improve on the old ways. The important thing is that we convert the trial results into solid written guidelines, so that we don't spend time discussing this again come Qt 5.6 or 5.7. I propose the following, with the hope that we formalise our decisions at http://wiki.qt.io/Coding_Conventions for future reference. (1) Let's commit to extracting (and following) solid guidelines from this experiment. By the time we reach the Qt 5.6 feature freeze, we need to have clear directions in the wiki on (i) what new modules in Qt 5.6+ should look like, and ideally (ii) what all modules in Qt 6 should look like. Do we convert QQmlComponent to QtQml::QComponent, or convert Qt3D::QComponent to Q3DComponent? (2) Let's decide on how to name namespaces. We recently got new namespaces with both the "Q" prefix (QWebSocketProtocol) as well as the "Qt" prefix (QtWin, QtAndroid, Qt3D). Which shall it be? (3) Let's decide on how namespaces and #include headers should work with each other. There are a few sub-issues here: a) We already have weird headers like , and we almost ended up with weird headers like for the QtWin namespace: https://codereview.qt-project.org/#/c/69108/ We need ground rules on how to design header names around namespace names. b) Should namespaces be #includable? Some are (QtWin, QTest), some aren't (Qt3D). c) At Qt 5.0's launch, the advice given to users was "Only #include the class name, not the module name". In other words, use "#include ", not "#include . However, if class names are allowed to be non-unique, this advice must change. I guess we revert to the old way of #including the module name along with the class name? (4) Let's decide on how to name QML types. Spot the odd one out: - (Qt Multimedia module) QCamera class -> Camera QML type - (Qt 3D Core module) Qt3D::QCamera class -> Camera QML type - (Qt QML module) QQmlComponent class -> Component QML type - (Qt 3D Core module) Qt3D::QComponent class -> Component3D QML type (5) Let's decide on the relationship between C++ modules and QML modules. C++ classes are split b
Re: [Development] Avoid overloading of 'error'
On 11 June 2015 at 00:59, Alan Alpert <4163654...@gmail.com> wrote: > On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon > wrote: >> Hi, >> >> I think renaming the getter to lastError is nice! I however do like error as >> signal name and it looks good in qml as onError:... > > I disagree that it looks good in QML as onError, almost all other > signal handlers are past tense so it is visibly odd. But it's nice to > be so short, so maybe a direct past-tense-ify of "onErrored"? If you > don't like using error as a verb, we can use a similar (yet shorter) > verb: "onErred". Not that I really mind the exact name of the new > signal. I'm with Alan and Thiago on making it past tense. I personally like "errored". It hasn't yet gained widespread acceptance as a verb in general, [1] but it seems widespread enough in the computing industry. On a related note, the "Component" type has a signal called "destruction". A better signal name is "destroyed", which corresponds with QObject::destroyed(). [2] I'm guessing that the QML authors designed these around the signal handler's name (rather than the signal's name). I think "onError" and "onDestruction" look fine _by themselves_, but not when we consider the other signals in Qt, which are verbs in past tense. Ideally, both C++ and QML should use the same conventions. A simple and consistent API is one of Qt's attractive features. Regards, Sze-Howe [1] There's a lively discussion at http://english.stackexchange.com/questions/3059/is-errored-correct-usage with supporters on both sides. [2] Well actually, both the QML and C++ the signals are emitted BEFORE the object is destroyed... but that's a separate topic. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QJsonArray concatenation
Hello,
This is the cleanest way I can currently think of to concatenate 2
QJsonArrays:
for (const auto& value : array2)
array1 << value;
Most of Qt's array-like containers (QVector, QList, QByteArray,
QString) have concatenation functions, but QJsonArray doesn't. So, I
propose adding the following overloads, to match the other containers:
- QJsonArray::operator+(const QJsonArray&)
- QJsonArray::operator+=(const QJsonArray&)
- QJsonArray::operator<<(const QJsonArray&)
The gotcha: This can cause a behaviour change. Currently, inputting
QJsonArray into operator+=() makes valid code -- the QJsonArray is
implicitly converted into a single QJsonValue first. My proposal would make
the same code avoid the conversion and append each element individually
instead. Is this acceptable for Qt 5.x? (I don't know how widely-used is
the implicit conversion to QJsonValue)
Note that there has been one other behaviour change that I know of:
https://forum.qt.io/topic/50282/
QJsonArray array1;
// ...
QJsonArray array2{array1};
In Qt 5.3, array2 is a copy of array1. However, Qt 5.4 introduced the
initializer list-based constructor. This constructor implicitly converts
array1 into a single QJsonValue, so array2 contains one element only.
Ideally, this change would not have happened (and ideally, my proposed
overloads would have been added back in Qt 5.3, when the single-element
versions were added).
So, we can now choose between maintaining SC, or having a more functional
API that's more consistent with other containers. Which is the correct
choice?
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QJSEngine and error line
On 9 April 2015 at 17:08, Joerg Bornemann wrote: > On 08-Apr-15 17:45, Sze Howe Koh wrote: > >> May I suggest adding a bit of documentation on our side to help people >> discover the features? Currently, >> http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends >> using toString() to probe errors. That's an ideal place to add a list >> of standard and non-standard properties that users can take advantage >> of. > > > Point taken. In the light that the most interesting properties here are > non-standard I agree that we should extend the docs. https://codereview.qt-project.org/110445/ Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QJSEngine and error line
On 9 April 2015 at 19:17, Simon Hausmann
wrote:
>
> On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote:
> > On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote:
> > [...]
> >
> > > Going off on a slight tangent:
> > > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is
> > > converted to a QVariantMap. Each property is converted to a QVariant,
> > > recursively". However, calling toVariant() on an Error object
> > > (isError() == isObject() == true) produces an empty QVariantMap event
> > > though QJSValueIterator gets the properties just fine (using Qt
> > > 5.4.1). Is this expected?
> >
> > That could be a bug. You should see the enumerable properties, which I think
> > include message and name. If a strack trace was producible at constructor
> > time, then you should also see the fileName and lineNumber properties.
> > "stack" however will not be visible.
>
> Ah, I had another look and I have to correct myself here:
>
> The properties in question ("message", "name", etc.) are defined as being non-
> enumerable [1], which is why the are not visible in the toVariant()
> conversion. Similarly those properties are not visible if you do
>
> for (propName in error) {
>console.log(propName)
> }
>
>
> QJSValueIterator - as a C++ tool - lists _all_ properties of an object, even
> the non-enumerable ones.
Thanks for looking it up.
Was it a conscious decision to restrict QJSValue::toVariant() to
enumerable properties only? What's the rationale?
> Simon
>
> [1] Although those properties are technically vendor extensions and non-
> standard, they are commonly implemented across web browser oriented JavaScript
> engines and _there_ they are non-enumerable.
"name" and "message" are standard :)
http://www.ecma-international.org/ecma-262/5.1/#sec-15.11.4
If I've read the spec correctly, all properties of the Error prototype
should be non-enumerable, so I think Qt is compliant with this part of
the spec.
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QJSEngine and error line
On 8 April 2015 at 22:10, Joerg Bornemann wrote: > On 08-Apr-15 16:06, Sze Howe Koh wrote: > >> I think we should document this somewhere, if it isn't already done (I >> searched but couldn't find anything). I'm happy to volunteer if >> necessary. Could you please provide a list of built-in properties of >> various QJSValue types? > > > The docs state mention that isError() returns true if the value is an object > of the Error class. That's a JavaScript class. We shouldn't duplicate the > JavaScript documentation. There are two issues here: 1. The "lineNumber" and "fileName" properties are non-standard. They are Mozilla extensions (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error ), so even some JavaScript devs might not know they exist. 2. The reader might not make the connection, "This is a JavaScript Error object, therefore it has properties that help me debug" -- especially if they don't have a JavaScript background (which I presume is true for a significant number of Qt users). Personally, I scoured the QJSValue page looking for debugging hints, and the only thing that jumped out at me was QJSValue::toString(). May I suggest adding a bit of documentation on our side to help people discover the features? Currently, http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends using toString() to probe errors. That's an ideal place to add a list of standard and non-standard properties that users can take advantage of. >> Also, what do you think of some API that returns a list of available >> properties? (similar to QObject::dynamicPropertyNames() ) > > > See QJSValueIterator. Got it, thanks. Going off on a slight tangent: https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is converted to a QVariantMap. Each property is converted to a QVariant, recursively". However, calling toVariant() on an Error object (isError() == isObject() == true) produces an empty QVariantMap event though QJSValueIterator gets the properties just fine (using Qt 5.4.1). Is this expected? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QJSEngine and error line
On 7 April 2015 at 17:31, Joerg Bornemann
wrote:
>
> On 07-Apr-15 09:59, Dominique Fober wrote:
>
> > I'm using the new QJSEngine and I'm trying to get the error line number (in
> > case of error of course).
> > Currently I'm handling errors as documented:
> >
> > if (result.isError()) result.toString().toUtf8() ...
> >
> > but actually, the string is very poor: e.g. "SyntaxError: Syntax error"
> > I would like to get at least a line number. Contextual information would be
> > also welcome.
> > Is it possible with the QJSEngine? (I'm using Qt 5.3.0)
>
> Try to access the properties "message", "fileName" and "lineNumber".
>
> if (result.isError())
> qDebug() << result.property("fileName").toString();
Ooh, this is news to me.
I think we should document this somewhere, if it isn't already done (I
searched but couldn't find anything). I'm happy to volunteer if
necessary. Could you please provide a list of built-in properties of
various QJSValue types?
Also, what do you think of some API that returns a list of available
properties? (similar to QObject::dynamicPropertyNames() )
> result is a JavaScript Error object iff isError returns true.
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt Wiki Now Available
On 27 February 2015 at 21:04, Kojo Tero wrote:
>> -Original Message-
>> From: Sze Howe Koh [mailto:szehowe@gmail.com]
>> Sent: 27. helmikuuta 2015 14:12
>> To: Kojo Tero
>> Cc: Qt Project; development@qt-project.org
>> Subject: Re: [Development] New Qt Wiki Now Available
>>
>> On 26 February 2015 at 23:05, Kojo Tero
>> wrote:
>> > Hello,
>> >
>> >
>> >
>> > We just opened the new Qt Wiki at http://wiki.qt.io
>> >
>> >
>> >
>> > You can find the details in the blog post:
>> >
>> > http://blog.qt.io/blog/2015/02/26/new-qt-wiki-now-available/
>> >
>> >
>> >
>> > In short, it’s a mediawiki instance, you use Qt Account to log in for
>> > editing,
>> >
>> > and the content has been migrated from the old wiki.
>> >
>> > And as a the content is imported, it needs cleaning up. Please help us
>> > out in going through the content and fixing it.
>>
>> I notice there's an "Updated Pages" page to track cleanup progress:
>> https://wiki.qt.io/index.php?title=Updated_pages
>>
>> May I suggest doing the other way round? Apply a "cleanup required"
>> tag to every page, and have people remove the tag after cleanup. That way,
>> people who want to help with the cleanup can quickly see where to direct
>> their efforts.
>>
>> Something like http://en.wikipedia.org/wiki/Template:Cleanup , tied to a
>> Tracking Category:
>> http://en.wikipedia.org/wiki/Category:All_pages_needing_cleanup
>
> Keeping track on the individual page level does make sense, but I would like
> to see what pages we actually use too. Going through the import made me
> wonder whether a lot of the pages really are used at all or are the visits
> random.
>
> I have to familiarize myself more with the maintenance tool arsenal mediawiki
> provides. There probably are tools to add the cleanup needed-tag to
> everything in a simple manner.
I was planning to write a small bot that iterates through all pages to
fix regex-able formatting issues. Would that interfere with your
data-gathering?
I've added some simple templates to facilitate cleanup tags. Feel free
to get a web dev to polish them:
* https://wiki.qt.io/index.php?title=Template:Ambox
* https://wiki.qt.io/index.php?title=Template:Cleanup
To set up the tag, simply add the following line to the pages (a
different 'reason' can be given, if desired):
{{Cleanup | reason=Automated import from ExpressionEngine}}
Then, those pages will appear in
https://wiki.qt.io/index.php?title=Category:Articles_needing_cleanup.
We should add this page to http://qt-project.org/contribute/ for
potential contributors to find.
I've never used MediaWiki maintenance scripts before, but I know how
to use the lower-level HTTP API to iterate through every page
(excluding those in https://wiki.qt.io/index.php?title=Updated_pages )
to add the tag. Shall I do that?
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt Wiki Now Available
On 26 February 2015 at 23:05, Kojo Tero wrote: > Hello, > > > > We just opened the new Qt Wiki at http://wiki.qt.io > > > > You can find the details in the blog post: > > http://blog.qt.io/blog/2015/02/26/new-qt-wiki-now-available/ > > > > In short, it’s a mediawiki instance, you use Qt Account to log in for > editing, > > and the content has been migrated from the old wiki. > > And as a the content is imported, it needs cleaning up. Please help us out > in going through the content and fixing it. I notice there's an "Updated Pages" page to track cleanup progress: https://wiki.qt.io/index.php?title=Updated_pages May I suggest doing the other way round? Apply a "cleanup required" tag to every page, and have people remove the tag after cleanup. That way, people who want to help with the cleanup can quickly see where to direct their efforts. Something like http://en.wikipedia.org/wiki/Template:Cleanup , tied to a Tracking Category: http://en.wikipedia.org/wiki/Category:All_pages_needing_cleanup Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 20 February 2015 at 16:28, Koehne Kai wrote: >> -Original Message- >> From: development-bounces+kai.koehne=theqtcompany.com@qt- >> [...] >> But this is an implementation convenience only. You can't convince me to >> drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win CE >> or >> old gcc for blackberry or one of all the other answers that have been given >> in >> those threads over the last couple of weeks. > > I tend to agree here, but Daniel raises a very valid point when he says: > >> I would expect that allowing C++11 in Qt would similarly lead to a wider >> understanding on how to leverage the new features for better code and better >> APIs. > > Since we don't use modern C++11 in Qt , its examples and documentation > itself, there's little common understanding and best practices how to do so. > > So, short of using C++11 in Qt library code itself: How about if we encourage > using C++11/C++14 features in examples and documentation snippets? To > bootstrap this we might even do a 'porting week' once to crowd-source this... +1 Any plans for another "Qt Fix and Polish Week"? The previous one seemed very well-received. [1] Regards, Sze-Howe [1] http://blog.qt.io/blog/2014/09/22/qt-fix-and-polish-week/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of Qt3D in 5.5
On 10 February 2015 at 00:55, Sean Harmer wrote: > > On Monday 09 Feb 2015 08:44:34 Thiago Macieira wrote: > > On Monday 09 February 2015 16:15:42 Sean Harmer wrote: > > > Trying to come up with a generic way to manage all this whilst making good > > > use of n cores is a good fit for ThreadWeaver or Intel TBB or something > > > else along the same lines. > > > > Wouldn't TBB be an acceptable dependency? > > TBB has no LGPL option iirc, only commercial and GPL. Otherwise I'd be more > than happy to use TBB. I'm happy to be proven wrong of course. We explored this some time ago, and found some legal uncertainties. Lars came to the conclusion that it can't be incorporated directly into Qt, except maybe as an add-on: http://permalink.gmane.org/gmane.comp.lib.qt.devel/10232 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why does QLabel::pixmap() return `const QPixmap*`?
On 2 December 2014 at 07:37, Sze Howe Koh wrote: > > On 1 December 2014 at 16:00, Thiago Macieira > wrote: > > On Monday 01 December 2014 07:40:50 Knoll Lars wrote: > >> Exactly that. It’s been like that since Qt 1 times, where QPixmap was a > >> non shared class you had to instantiate on the heap. We never changed this > >> accessor for source compatibility reasons (I remember discussing this with > >> Matthias when we moved from Qt 3 to Qt 4 ), but I agree it feels very > >> wrong these days to return a pointer to a pixmap. > > > > Add a QPixmap::labelPixmap() const; and deprecate the old. > > Done for the pixmap and picture API: https://codereview.qt-project.org/101233/ > > Is it worth changing the internal implementation as well? > QLabelPrivate stores QImage, QPicture, and QPixmap pointers. Hi, Could someone review these, please? https://codereview.qt-project.org/101233 https://codereview.qt-project.org/101512 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Is the online repository ready for Qt 5.4?
Hi all, I'm trying to upgrade to Qt 5.4 and Qt Creator 3.3 using the online installer. However, when I select "Update components" or "Package manager", the installer gets stuck at "Preparing meta information download..." Looking at http://download.qt-project.org/online/qtsdkrepository/windows_x86/root/qt/qt/, "1.0.7meta.7z" is a meager 93 B (an empty archive) while "1.0.2meta.7z" and "1.0.4meta.7z" are both around 25 KB. Also, 1.0.7meta.7z isn't accompanied by a *.sha1 file. Is the online repo incomplete? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why does QLabel::pixmap() return `const QPixmap*`?
On 1 December 2014 at 16:00, Thiago Macieira wrote: > On Monday 01 December 2014 07:40:50 Knoll Lars wrote: >> Exactly that. It’s been like that since Qt 1 times, where QPixmap was a >> non shared class you had to instantiate on the heap. We never changed this >> accessor for source compatibility reasons (I remember discussing this with >> Matthias when we moved from Qt 3 to Qt 4 ), but I agree it feels very >> wrong these days to return a pointer to a pixmap. > > Add a QPixmap::labelPixmap() const; and deprecate the old. Done for the pixmap and picture API: https://codereview.qt-project.org/101233/ Is it worth changing the internal implementation as well? QLabelPrivate stores QImage, QPicture, and QPixmap pointers. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why does QLabel::pixmap() return `const QPixmap*`?
Hi all, I'm curious about the rationale behind this API design. I can't think of any other Qt function that returns an implicitly-shared object by pointer, so this seems inconsistent. e.g. QWidget::font() returns a QFont by const-ref. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rich Text Editor using QML
On 15 November 2014 03:58, André Pönitz wrote: > > On Fri, Nov 14, 2014 at 10:06:32AM +0100, Yann Levreau wrote: > > Hi everybody! > > > > I am starting a new project and I am looking for some advice about what > > kind of Qt/QML controls I should use. The purpose is to develop an rich > > text editor using QML. Basically I am going to develop IDE features. > > Until now I have tried the TextArea QML Control. Using this control I get > > a > > > > QQuickTextDocument and QTextDocument on the C++ side. > > > > Am I in the right direction ? Is there any limitations using this > > control that I should know ? Or maybe there is better way to implement > > this (using QWebView or a simple QTextEdit, ... ). > > On the Widget side the proper choice for an text editor base would be > QPlainTextEdit. In C++, I would use a QTextEdit instead of a QPlainTextEdit, because QTextEdit supports rich text but QPlainTextEdit doesn't. The QSyntaxHighligher class is useful too. There are examples available in the documentation: - Code Editor Example: http://qt-project.org/doc/qt-5/qtwidgets-widgets-codeeditor-example.html - Syntax Highlighter Example: http://qt-project.org/doc/qt-5/qtwidgets-richtext-syntaxhighlighter-example.html Or, for a real-world example of an IDE, see the Qt Creator source code: - http://code.woboq.org/qt5/qt-creator/ In QML, yes TextArea would be the best base type. One "limitation" I can think of is that you can't write pure QML -- QQuickTextDocument needs to be accessed from C++ (http://qt-project.org/doc/qt-5/qquicktextdocument.html). QML-C++ interaction is very common so this may not be an issue. I haven't used Qt Quick Controls much so I can't say whether it's easier to develop your project in QML or C++. By the way, this discussion should be happening on the Interest mailing list. The Development mailing list is for posts about developing Qt itself. I've included Interest in the CC field -- please remove Development if you reply. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Two QStorageInfo classes
On 5 October 2014 07:00, Aleix Pol wrote: > On Fri, Oct 3, 2014 at 7:33 PM, Thiago Macieira > wrote: >> >> On Friday 03 October 2014 18:11:22 Aleix Pol wrote: >> > If I do "git submodule update" from a qt5 in 5.4 branch, the HEAD commit >> > in >> > qtsystems is 4a324f7. If I "git checkout origin 5.4" the HEAD commit >> > is 3b3b759c6. >> > >> > Isn't the reason why submodules points to an old snapshot that the >> > provided >> > snapshot is one that is properly tested in jenkins? >> > Currently, the proposed submodules don't build. >> >> Ah, I see what you mean. >> >> Submodules that aren't part of the release nor planned to be will not be >> tested frequently. They may or may not build, so if you want to use them >> you >> need to be prepared to fix the build yourself. >> >> You should probably also keep yourself on the the master or dev branch (as >> required) instead of following the submodule link. That may require you to >> go >> to the dev branch of the other Qt modules too. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> > > Well, I never intended to build them explicitly. Maybe they should be added > to ./configure rather having them built by default? How did you clone the Qt 5 repositories? The "best" instructions for building Qt from git can be found at http://qt-project.org/wiki/Building_Qt_5_from_Git -- its instructions are to clone the root repository, and then run the `init-repository` Perl script to clone the submodules. By default, this script doesn't clone the repositories that are not part of the Qt 5 release. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Rename Qt WebSockets QML import
On 30 September 2014 20:56, Blasche Alexander wrote: >> -Original Message- >> From: development-bounces+alexander.blasche=digia@qt-project.org >> [mailto:development-bounces+alexander.blasche=digia@qt-project.org] >> On Behalf Of Sze Howe Koh > >> To bring the WebSocket QML import name in line with other modules >> (e.g. "QtWebEngine 1.0", "QtQuick 2.x", "QtWebKit 3.x", "QtSensors >> 5.x"), I propose changing the import: >> >> - From "import Qt.WebSockets 1.0" >> - To "import QtWebSockets 1.1" (no dot between "Qt" and "WebSockets") > > I was considering to do the same a couple of days ago when I fixed the docs > for it. If/when you do this please don't forgot to update the docs too. Ok, there have been no objections so here is my first attempt: https://codereview.qt-project.org/#/c/96406/ > However why bumping the version? It would be just a rename while retaining > the old name. > > If you must bump it it should rather be a bump it to 5.x. This forest of > versions is just confusion without no purpose. I considered bumping the version because the rename is a significant change, but I've left it as-is now. I'm not a fan of the potpourri of version numbers myself, but I think that's best left for a separate discussion. >> Ideally, the old import name + version number would still be available >> for compatibility, while newer versions would use the new name. Is >> this supported? > > Yes this can be done. It's just a matter of testing for both strings in the > plug-ins type registrations. Thanks. My current solution is to have a qmldir file in the old location that points to the plugin in the new location. Unfortunately, it also generates some dummy shared libraries when the module is compiled (probably because my qmake-fu is not strong enough). * Is there a way to copy the qmldir without building any binaries? * Even better, is there a way to support the extra namespace without having an extra qmldir file? >> What does everyone think? > +10 ;) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: Rename Qt WebSockets QML import
Hi all, To bring the WebSocket QML import name in line with other modules (e.g. "QtWebEngine 1.0", "QtQuick 2.x", "QtWebKit 3.x", "QtSensors 5.x"), I propose changing the import: - From "import Qt.WebSockets 1.0" - To "import QtWebSockets 1.1" (no dot between "Qt" and "WebSockets") Ideally, the old import name + version number would still be available for compatibility, while newer versions would use the new name. Is this supported? What does everyone think? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
