[Development] QUIP Index is not showing up at contribute.qt-project.org

[Sze Howe Koh]

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

[Sze Howe Koh]

+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

[Sze Howe Koh]

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

[Sze Howe Koh]

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)

[Sze Howe Koh]

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)

[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:

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"

[Sze Howe Koh]

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?

[Sze Howe Koh]

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?

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

== 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, ::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)

[Sze Howe Koh]

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")

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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 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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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]

[Sze Howe Koh]

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=2019-12-01=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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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)

[Sze Howe Koh]

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)

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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?

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

 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

[Sze Howe Koh]

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?

[Sze Howe Koh]

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)

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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?

[Sze Howe Koh]

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?

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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 

Re: [Development] Qt branches & proposal how to continue with those

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

y-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 , const FormatType );
> }`
>
> `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

[Sze Howe Koh]

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)

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

On 24 February 2017 at 06:08, Ch'Gans <chg...@gna.org> 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 <chg...@gna.org> wrote:
> > On 7 February 2017 at 23:18, Edward Welbourne <edward.welbou...@qt.io> 
> > 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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

[Sze Howe Koh]

On 7 May 2016 at 12:20, Joseph Crowell <joseph.w.crow...@gmail.com> wrote:
>
> On 4/05/2016 7:39 PM, Lars Knoll wrote:
>>
>> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" 
>> <development-bounces+lars.knoll=qt...@qt-project.org on behalf of 
>> 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

[Sze Howe Koh]

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

[Sze Howe Koh]

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

Re: [Development] Minimum Deployment Platforms for 5.7 onwards?

[Sze Howe Koh]

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_source=link_campaign=sig-email_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_source=link_campaign=sig-email_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

[Sze Howe Koh]

On 10 October 2015 at 11:06, Sze Howe Koh <szehowe@gmail.com> wrote:
>
> On 16 September 2015 at 15:46, Jake Petroules
> <jake.petrou...@petroules.com> wrote:
> > > On Sep 15, 2015, at 9:07 PM, Sze Howe Koh <szehowe@gmail.com> 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

[Sze Howe Koh]

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

[Sze Howe Koh]

On 16 September 2015 at 15:46, Jake Petroules
<jake.petrou...@petroules.com> wrote:
> > On Sep 15, 2015, at 9:07 PM, Sze Howe Koh <szehowe@gmail.com> 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

[Sze Howe Koh]

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

[Sze Howe Koh]

On 30 August 2015 at 16:02, Dmitry Volosnykh <dmitry.volosn...@gmail.com> 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 <szehowe@gmail.com>
> 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

Re: [Development] Documentation proposal: Remove recommended reading list of 20-year-old books

[Sze Howe Koh]

On 30 August 2015 at 16:32, Hausmann Simon
<simon.hausm...@theqtcompany.com> wrote:
> I think that there is a b‎ig 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

[Development] Documentation proposal: Remove recommended reading list of 20-year-old books

[Sze Howe Koh]

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] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

[Sze Howe Koh]

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 vmoo...@ics.com 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: some binding expression
 }
 }
 }
 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: some binding expression
 }
 }
 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] Enginio version and branch names

[Sze Howe Koh]

Hi,

On 20 August 2015 at 15:31, Frederik Gladhorn
frederik.gladh...@theqtcompany.com 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] Avoid overloading of 'error'

[Sze Howe Koh]

On 16 June 2015 at 19:28, Kurt Pattyn pattyn.k...@gmail.com wrote:
 Well,

 you can also think of “on” + event, 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 + signal, not state:
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] Avoid overloading of 'error'

[Sze Howe Koh]

On 11 June 2015 at 00:59, Alan Alpert 4163654...@gmail.com wrote:
 On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
 simon.hausm...@theqtcompany.com 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

[Sze Howe Koh]

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 (QVectorT, QListT, 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

[Sze Howe Koh]

On 9 April 2015 at 19:17, Simon Hausmann
simon.hausm...@theqtcompany.com 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

[Sze Howe Koh]

On 7 April 2015 at 17:31, Joerg Bornemann
joerg.bornem...@theqtcompany.com 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] [Interest] QJSEngine and error line

[Sze Howe Koh]

On 8 April 2015 at 22:10, Joerg Bornemann
joerg.bornem...@theqtcompany.com 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] New Qt Wiki Now Available

[Sze Howe Koh]

On 27 February 2015 at 21:04, Kojo Tero tero.k...@theqtcompany.com 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 tero.k...@theqtcompany.com
 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

[Sze Howe Koh]

On 26 February 2015 at 23:05, Kojo Tero tero.k...@theqtcompany.com 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

[Sze Howe Koh]

On 20 February 2015 at 16:28, Koehne Kai kai.koe...@theqtcompany.com 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

[Sze Howe Koh]

On 10 February 2015 at 00:55, Sean Harmer sean.har...@kdab.com 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*`?

[Sze Howe Koh]

On 2 December 2014 at 07:37, Sze Howe Koh szehowe@gmail.com wrote:

 On 1 December 2014 at 16:00, Thiago Macieira thiago.macie...@intel.com 
 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?

[Sze Howe Koh]

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*`?

[Sze Howe Koh]

On 1 December 2014 at 16:00, Thiago Macieira thiago.macie...@intel.com 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*`?

[Sze Howe Koh]

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

[Sze Howe Koh]

On 15 November 2014 03:58, André Pönitz apoen...@t-online.de 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] Proposal: Rename Qt WebSockets QML import

[Sze Howe Koh]

On 30 September 2014 20:56, Blasche Alexander
alexander.blas...@digia.com 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

[Sze Howe Koh]

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

Re: [Development] New company name for Qt part of Digia and unified web site

[Sze Howe Koh]

I enjoy the new look and the fluidity of the site. It conveys a sense
of what developers can achieve graphically with the technology
available in the Qt framework.

One thing I feel that could be improved is http://www.qt.io/product/
-- it gives me the impression that Qt is a commercial-only product
(the starting price is 20€/month). It doesn't even hint that a
community version is available.


On 18 September 2014 08:26, Lorn Potter lorn.pot...@gmail.com wrote:
 On 18/09/14 05:09, Kuba Ober wrote:
 One of the reasons I loath to recommend to the management to go back to 
 paying for Qt licenses is that we’d have been sponsoring what amounts to 2 
 or 3 major rebrandings and “revamps”, and it seems like throwing money down 
 the drain. As a user, I want good code. The website, as far as I’m 
 concerned, can be text-only. Any money that the owners of Qt spend for 
 anything besides the code is, to us as the end users,*our*  money burned for 
 frivolities.

 speak for yourself.

 I think it looks quite nice. They've done a good job making it look
 appealing and useful.

 While text only web site might be ok with you, managers or directors
 scoping out a dev framework for the first time might be wary about
 paying for something with a web site from 1980's

 Quality of code also runs to the web servers. I am a bit wary about dev
 apps/frameworks/tools whose web site looks like gak.

+1

If you are already world-renowned, you could get away with a text only
site (like Warren Buffett: http://www.berkshirehathaway.com/ ).
However, if you are not yet world-renowned, taking this route would do
no favours for your business -- it's akin to meeting potential
corporate clients while dressed in an old T-shirt, shorts, and
slippers.

It's not frivolities; it's an investment.


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers

[Sze Howe Koh]

On 16 September 2014 22:45, Thiago Macieira thiago.macie...@intel.com wrote:
 On Tuesday 16 September 2014 10:34:02 Paul Olav Tvete wrote:
 On Tuesday 16. September 2014 07.31.01 Reinio Topi wrote:
  I'd like to nominate Venugopal Shivashankar and Nico Vertriest as
  approvers
  in the Qt Project.

 +2

 One for each? :-)

I've always assumed that they're already approvers!

+1 +1 from me too


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New documentation errors since Qt 5.3.1

[Sze Howe Koh]

Hi all,

Using qdoc from Qt 5.4.0 Alpha1, I generated documentation from the
v5.4.0-alpha1 and v5.3.1 git tags. Then, I diff'ed the qdoc outputs
using QDocErrorTracker [1].

Below is a list of errors that are new in Qt 5.4.0 Alpha1. Could those with
knowledge of the relevant areas please fix them if time permits?


= qtbase.git =
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_Find' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_Open' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_MicVolumeUp' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_Redo' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_Undo' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_New' in Qt::Key
src/corelib/global/qnamespace.qdoc:1252
warning: Undocumented enum item 'Key_MicVolumeDown' in Qt::Key
src/corelib/global/qglobal.cpp:1106
warning: No such enum item 'MV_IOS_8_0' in QSysInfo::MacVersion
src/corelib/kernel/qmath.qdoc:206
warning: No such parameter 'radians' in qNextPowerOfTwo()
src/corelib/kernel/qmath.qdoc:206
warning: No such parameter 'value' in qRadiansToDegrees()


= qtmacextras.git =
src/macextras/qmactoolbar.mm:66
warning: Can't link to 'QWindow::attachToWindow'
examples/macextras/embeddedqwindow/doc/src/qtmacextras-example-embeddedqwindow.qdoc:28
warning: Can't link to 'Qt for OS X'
src/macextras/doc/src/qtmacextras-examples.qdoc:41
warning: Can't link to 'Qt for OS X'
examples/macextras/macfunctions/doc/src/qtmacextras-example-macfunctions.qdoc:28
warning: Can't link to 'Qt for OS X'
examples/macextras/macpasteboardmime/doc/src/qtmacextras-example-macpasteboardmime.qdoc:28
warning: Can't link to 'Qt for OS X'


= qtdeclarative.git =
src/qml/doc/src/qmlfunctions.qdoc:159
warning: Cannot find 'QQmlEgine' in '\relates'
src/qml/doc/src/qmlfunctions.qdoc:181
warning: Cannot find 'QQmlEgine' in '\relates'
src/imports/statemachine/finalstate.cpp:73
warning: Cannot find file to quote from:
'qml/statemachine/finalstate.qml'
src/imports/statemachine/finalstate.cpp:73
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/finalstate.cpp:73
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/signaltransition.cpp:227
warning: Cannot find file to quote from:
'qml/statemachine/signaltransition.qml'
src/imports/statemachine/signaltransition.cpp:227
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/signaltransition.cpp:227
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/signaltransition.cpp:239
warning: Cannot find file to quote from:
'qml/statemachine/signaltransitionsignal.qml'
src/imports/statemachine/signaltransition.cpp:239
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/signaltransition.cpp:239
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/signaltransition.cpp:253
warning: Cannot find file to quote from:
'qml/statemachine/guardcondition.qml'
src/imports/statemachine/signaltransition.cpp:253
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/signaltransition.cpp:253
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/statebase.cpp:136
warning: Cannot find file to quote from:
'qml/statemachine/basicstate.qml'
src/imports/statemachine/statebase.cpp:136
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/statebase.cpp:136
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/statebase.cpp:199
warning: Cannot find file to quote from:
'qml/statemachine/historystate.qml'
src/imports/statemachine/statebase.cpp:199
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/statebase.cpp:199
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/statemachine.cpp:117
warning: Cannot find file to quote from:
'qml/statemachine/simplestatemachine.qml'
src/imports/statemachine/statemachine.cpp:117
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, column 1
src/imports/statemachine/statemachine.cpp:117
warning: Unexpected '\snippet (//! [document])'
src/imports/statemachine/timeouttransition.cpp:96
warning: Cannot find file to quote from:
'qml/statemachine/timeouttransition.qml'
src/imports/statemachine/timeouttransition.cpp:96
warning: Unable to parse QML snippet: Expected token `numeric
literal' at line 1, 

[Development] How does QML versioning work?

[Sze Howe Koh]

Hi all,

We have a very clearly defined policy on what changes are allowed new
versions of Qt:

- Patch release: Source  binary compatible bug fixes only
- Minor release: Source  binary compatible bug fixes and new features
- Major release: Incompatible changes allowed


What about QML modules? I couldn't find a similar policy outlined
anywhere; does one exist?

Also, where are the changelogs for each new version of a QML module?
(e.g. what's the difference between QtQuick 2.2 and QtQuick 2.3?)


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to pass key-press/mouse-wheel events to underlying window after QWidget::createWindowContainer()

[Sze Howe Koh]

On 16 July 2014 08:20, Sze Howe Koh szehowe@gmail.com wrote:
 Hello,

 I'm on Windows 8.1 ×64. I got a HWND from an external process
 (Notepad.exe, in this case) and embedded it inside a QWidget:

 // Get the HWND using Windows API
 WId id = (WId)FindWindow(NULL, LUntitled - Notepad);

 // Embed the window in a widget
 QWindow* window = QWindow::fromWinId(id);
 QWidget* widget = QWidget::createWindowContainer(window);
 widget-show();


 The embedded Notepad can receive mouse clicks and drags -- I can use
 the mouse to highlight text, and use the right-click menu to
 copy+paste text. However,, it doesn’t respond to mouse wheels and key
 presses. Does anyone know how I can restore these events?

 I got the same results from both MinGW 4.8.2 and MSVC 2013 (both Qt 5.3.1).


 Thanks in advance!

Looks like a bug in the Windows implementation -- The issue doesn't
exist on Ubuntu 14.04.

I've opened https://bugreports.qt-project.org/browse/QTBUG-40320 which
contains a list of issues related to embedding and releasing foreign
windows in both Windows and Linux.


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development