[Development] Units in QML (was: Re: Scalable UIs in QtQuick (take 2))

[André Somers]

Op 25/02/2016 om 01:41 schreef Michael Brasser:

Hi,

Regarding (2), last time around I had concerns about the proposed limitations 
associated with language-level unit support (see some of the discussion at 
https://codereview.qt-project.org/98288). I'd be interested to hear the 
particulars of what unit support might look like this time around.

Regards,
Michael

Thanks for bringing up that patch again, and pointing out your (valid!) 
concerns there as well again.


I think that generic unit support in the QML language would be awesome 
to have, but indeed I don't like it to be tied too much to Quick and 
screens. It would be great if it were possible somehow to define your 
own units in Quick or whatever other domain specific use you make of the 
language, and you then specify properties using those units in 
quantities instead of plain numerical values as we do now. Numerical 
values could be implicitly convertable to quantities, but not to each 
other unless such a relation is explicitly defined. That should prevent 
anyone from trying to do 3cm + 4s.


Perhaps the basic units and their relations could be defined by default 
already (the different length units like mm, cm, m*, inch, and the 
different time units ms, s, m*, h, day), and then adding domain specific 
units like px at the Quick level. In a domain application like aviation 
you may want to add specific units like FL (fleight level; which is an 
altitude in hundreds of feet above a standard isobaric reference plain 
at 1013,2 hectopascal), feet_QNH or m_QNH which can depend on some 
context variable.


Properties would be in some defined unit, and any numerical value 
assigned to that would be implicitly be regarded to be specified into 
that unit.


André


)* Note the first clash already...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QDesktopWidget for an X display

[Shiva sitamraju]

Hi,

I am trying to put a widget on a given X Display from inside QT
application. Also posted same question on stackexchange
http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display
.

Would be very grateful if anyone can help me in this regards

Shiva
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Turunen Tuukka]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=theqtcompany@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: torstaina 25. helmikuuta 2016 0.18
> To: development@qt-project.org
> Subject: Re: [Development] Supported platforms for Qt 5.8
> 
> On quarta-feira, 24 de fevereiro de 2016 21:53:06 PST Blasche Alexander
> wrote:
> >
> > The commitment towards WEC2013 in Qt 5.6 is what really matters due to
> > its LTS character. By the time 5.6 support runs out Qt 5.8 support has
> > been ancient history.
> >
> > In summary Qt does not gain anything from pushing WEC2013 to 5.8:
> >
> > - Potential Qt Customers are not stranded due to 5.6
> > - WEC2013 in 5.8 doesn't really enable more projects
> > - MS says it is dead and licenses are hard to come by
> > - the currently visible project pipeline is rather dry on this
> > platform
> >
> > *But* our C++11 offering is yet longer chained.
> 
> So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8?
> 
> Let's drop it now.
> 

That is fine for me as well. As Alex wrote, most important is that Qt 5.6 LTS 
supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer have these 
to slow down adoption of C++11 and other planned changes.

Yours,

Tuukka
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Scalable UIs in QtQuick (take 2)

[Michael Brasser]

Hi,

Regarding (2), last time around I had concerns about the proposed limitations 
associated with language-level unit support (see some of the discussion at 
https://codereview.qt-project.org/98288). I'd be interested to hear the 
particulars of what unit support might look like this time around.

Regards,
Michael


From: Development  
on behalf of Hausmann Simon 
Sent: Thursday, February 18, 2016 4:50 AM
To: development@qt-project.org
Subject: [Development] Scalable UIs in QtQuick (take 2)

Hi,

A little while ago Lars and I proposed to introduce physical units in the QML 
language for use in QtQuick. The idea was to make it easier to write user 
interfaces that adapt to different display resolutions by "pinning" your UI to 
physical dimensions. For example you could say

Image {
source: "mypprofilephoto.png"
width: 5cm
height: 5cm
}

and the image size in physical pixels would scale accordingly to always produce 
a 5cmx5cm profile image on the screen. The proposed units included "px", which 
was really an alias for nothing.

We've had some very good discussions around this at last year's contributor 
summit as well as in smaller face-to-face discussions. The main feedback I 
recall was that this would seem like a nice feature on paper but in practice 
people create their resolution independent interfaces using the current 
"pixels" and a scale factor that they introduce in a qml file or as a context 
property. That's another way of saying that perhaps the feature wouldn't really 
find any use, which is fair :). Instead the desire was expressed that making it 
_easier_ to scale "logical" pixels in the application would perhaps be better.

So today during a discussion another idea came up:

(1) In order to make it really easy to scale "logical" pixels without having to 
introduce your own context property or factor in a .qml file that you multiply 
everywhere, we could turn the regular "pixels" in QtQuick into truly logical 
pixels that scale with an application wide (or window wide) factor. So Image { 
width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 
physical pixels on a x2 display. This assumes the availability of API to change 
this mapping.

(2) In the events where you still _want_ to use physical pixels, you could use 
"px" units.

So at first nothing would change for app developers at all because we map 
logical pixels to physical pixels. But
if you'd like to, you could opt into changing this mapping and having a 
relatively easy fallback to physical pixels using for example the "px" unit. We 
might as well offer the other physical units anyway, that probably causes 
little to no harm.

What do you think?

Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Supported platforms for Qt 5.8

[Thiago Macieira]

On quarta-feira, 24 de fevereiro de 2016 21:53:06 PST Blasche Alexander wrote:
> > Basically it means we are stuck with Visual Studio 2012 c++ featureset
> > for Windows Embedded Compact 2013.
> 
> I spoke to the Microsoft guys on Embedded World today. 

(too bad I couldn't go)

> They confirmed that it is 2012 and there are no plans to update this. 

This would support the position that we can't touch our compiler requirements 
unless we want to change our platform support promises.

> In fact that went as far
> as saying that the relevant development team behind WEC2013 has been
> abandoned to the point that the essential support is barely possible.

While this would indicate that people should stay away from WEC2013 and we 
should really be dropping it, to the point of not even finishing the 
experimental support.

Of course, this is anecdotal information and I wouldn't make business 
decisions like that.

> > If we want to support newer C++ with Qt 5.8 we would need to drop the
> > complete platform.
> 
> And this is the main reason behind this push.

See Marc's reply to my list of enabled features. I didn't find anything there 
that would be compelling enough to warrant dropping a platform we've only 
barely added anyway.

> The answer is no. The principle feature set is working. There are some gaps
> related to device debugging but those gaps are due to non-open protocols.
> The term "Experimental" is a rather bad choice of word.
> 
> The commitment towards WEC2013 in Qt 5.6 is what really matters due to its
> LTS character. By the time 5.6 support runs out Qt 5.8 support has been
> ancient history.
> 
> In summary Qt does not gain anything from pushing WEC2013 to 5.8:
> 
> - Potential Qt Customers are not stranded due to 5.6
> - WEC2013 in 5.8 doesn't really enable more projects
> - MS says it is dead and licenses are hard to come by
> - the currently visible project pipeline is rather dry on this platform
> 
> *But* our C++11 offering is yet longer chained.

So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8?

Let's drop it now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed"

[Thiago Macieira]

On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote:
> So my question or suggestion to reduced bug fixing time is:
> 
> - Is there or should there be an authority/committee that decides early, 
> if a bug is worth to be fixed for 5.6 LTS?
>Maybe in bugreports.qt.io: if the "Affects Version/s" contains 
> "5.6.x" the authority
>could "Label" it 5.6-LTS to hint the fixing branch?
> - Is there or should there be a Wiki-Page giving rules of thump, what 
> inconsistent between API docs and actual behavior
>is a bug that should be fixed in 5.6 LTS?

The current rule should still apply: contributors decide among themselves. The 
author of the patch makes a suggestion, other contributors and approvers may 
make different suggestions. In case there's no consensus, the maintainer makes 
a decision.

In case there's disagreement with the maintainer's decision, bring it to the 
mailing list and the Chief Maintainer will decide.

Using bugreports.qt.io won't help, since the same people who can set labels 
and the version fields are the ones in the group above anyway.

I really oppose the creation of a committee. We don't need more bureaucracy, 
especially without a proof that the current methods don't work. I think the 
above description does work.

However, a wiki page giving rules of thumb of what may be acceptable and what 
may not is a very good idea.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Supported platforms for Qt 5.8

[Blasche Alexander]

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany@qt-project.org] On Behalf Of
> Andreas Holzammer
...
> Am 22.02.2016 um 23:52 schrieb Thiago Macieira:
> > On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote:
> >> I can see the reasoning here, just as well as I see the reasoning of the
> >> people that would like to get rid of VS2012 as quickly as possible.
> >
> > Why do we need to get rid of it? What are the problems with it, aside from
> > lack of certain C++11 support?
> >
> 
> Mostly yes we see a demand in getting new c++ features into Qt. As far
> as my knowlege goes is that WEC2013 bundles they compiler with the SDK
> which is produced by the Platform Builder. As of now I did not see any
> indication that this bundled compiler will be updated(right now they
> bundle the VS2012 compiler). All websites which I did read say if you
> read closely that they are supporting the new Visual Studio IDE, but
> will take the toolchain of the SDK which is provided.
> 
> Basically it means we are stuck with Visual Studio 2012 c++ featureset
> for Windows Embedded Compact 2013.

I spoke to the Microsoft guys on Embedded World today. They confirmed that it 
is 2012 and there are no plans to update this. In fact that went as far as 
saying that the relevant development team behind WEC2013 has been abandoned to 
the point that the essential support is barely possible. 

> If we want to support newer C++ with Qt 5.8 we would need to drop the
> complete platform.

And this is the main reason behind this push.

> On terça-feira, 23 de fevereiro de 2016 19:16:48 PST Andreas Holzammer wrote:
> > As of problems to support it in newer Qt Versions, I can say the market
> > share right now is not very big, as also already indicated by someone
> > else. Hardware vendors do release right now more experimental support
> > for WEC2013, which means there might be years until they reach a decent
> > market share.
> 
> To be clear: are you expecting WEC2013 market share to increase?

Those projects which would grow this market would have to have acquired their 
license already as I have heard that new WEC2013 licenses are not handed out 
anymore. At the very least you have to "twist" Microsoft's arms to get hold of 
one. That's not a good starting point for a growing market. This is a firm 
Micosoft management decision despite the mentioned offering gaps.

>On Tuesday, 23 February 2016 13:09:10 WET Thiago Macieira wrote:
> > But you cannot commit major refactorings to improve stability in an patch
> > release, especially not the LTS release. Remember that 5.6 is also the last
> > release to support WEC7, so you cannot risk its stability for a platform
> > that's only experimental.

> But are we going to need major refactorings ? We need to know the state of
> wec2013 before discussing further, no point in speculating on what was meant
> by "experimental".

The answer is no. The principle feature set is working. There are some gaps 
related to device debugging but those gaps are due to non-open protocols. The 
term "Experimental" is a rather bad choice of word.

The commitment towards WEC2013 in Qt 5.6 is what really matters due to its LTS 
character. By the time 5.6 support runs out Qt 5.8 support has been ancient 
history.

In summary Qt does not gain anything from pushing WEC2013 to 5.8:

- Potential Qt Customers are not stranded due to 5.6
- WEC2013 in 5.8 doesn't really enable more projects
- MS says it is dead and licenses are hard to come by
- the currently visible project pipeline is rather dry on this platform

*But* our C++11 offering is yet longer chained.

There simply is no justification for such a move on the business and technical 
side.

--
Alex

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

[Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed"

[Michael Möllney]

Now (finally) Qt 5.6.0 LTS knocks at the door (RC published today)

I appreciate the decisions to support this 5.6.x release for at least 3 
years, plus possible time extension.


Looking for a definition what this actually means, I could find in
Planet Qt http://blog.qt.io/blog/2016/02/22/qt-roadmap-for-2016/ :

[quote]
Long-Term Support

Qt 5.6 is the first Long-Term Supported (LTS) version of Qt since Qt 
4.8. As part of our LTS promise,
we guarantee that Qt 5.6 will be supported for three years via standard 
support, after which additional
extended support can be purchased. During this time period, even though 
following
Qt releases (Qt 5.7, Qt 5.8 and so on) are available, Qt 5.6 will 
receive patch releases providing
bug fixes and security updates throughout the three-year period after 
the release.

[quote]

This sounds good: support, bug fixes and security updates! Yeah!
In other mailing list threads 
(http://lists.qt-project.org/pipermail/development/2016-February/024943.html)
there is even discussion if platforms that might establish in these 3 
years should get support... wow!


But who decides or gives guidance to the developers, if a bug found in 
5.6.x should be fixed in this LTS.


E.g. have a look at a patch history in 
https://codereview.qt-project.org/#/c/109157/
That patch evolved through 5.4, 5.5, 5.6 and now is moved to 5.7 with 
advice to use C++11 features.
The comments finally focused in a discussion on what branch/release to 
put that particular bug fix / behavior change.
There is some arguing that this patch is a "behavior change", but which 
fix is not a behavior change.
Sometimes bugs do not crash they "just" do not what the documentation 
says: It's not always easy to tell.


So my question or suggestion to reduced bug fixing time is:

- Is there or should there be an authority/committee that decides early, 
if a bug is worth to be fixed for 5.6 LTS?
  Maybe in bugreports.qt.io: if the "Affects Version/s" contains 
"5.6.x" the authority

  could "Label" it 5.6-LTS to hint the fixing branch?
- Is there or should there be a Wiki-Page giving rules of thump, what 
inconsistent between API docs and actual behavior

  is a bug that should be fixed in 5.6 LTS?

I think this could help developers to decide early, if the patch should 
evolve with old compiler compatibility and
becomes a fix in 5.6.x, or if the developer should jump directly to the 
5.7 branch and make use of nice C++11 features.


Cheers,
Michael
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Reduced availability

[Thiago Macieira]

On quarta-feira, 24 de fevereiro de 2016 11:27:24 PST Milian Wolff wrote:
> > If you need my attention, please send me an email or ping me on IRC.

> 
> Hey Thiago,
> 
> there is at least one change for 5.7 where people are currently blocked
> waiting for your input and expertise:
> 
> Optimized QReadWriteLock:
> https://codereview.qt-project.org/#/c/140322/
> 
> I'd really like to see this get merged sooner rather than later to extend
> the exposure of the patch.

Hi Milian

I will take a look at that one.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Scalable UIs in QtQuick (take 2)

[Gerry Boland]

Hey Simon,
I can try offering the Ubuntu Touch perspective on units with QML (sorry
if late, was busy for MWC).

We created a units system for our QML apps, called grid unit:  units.gu(x).

We did this as we needed the ability to scale the UI for different
devices, from phones with highDpi screens to lowDpi monitors.
DevicePixelRatio didn’t exist at the time, and when it appeared, it was
too limited unfortunately, as we did not trust that non-integral values
would work reliably in QML. And also such values break QWidget-based apps.


Grid units are implemented as you predicted: as a context property. It
can change at runtime too, as with our convergence strategy, we need
apps to rescale dynamically at runtime.

(We also have "device pixels" units.dp(x), which will map directly to
your proposed logical pixels, which is good. But that is primarily used
for things to be 1 or 2 pixel wide, like line thickness).

We've implemented special image loaders that will respect this unit
system. This all works, and we've found it clunky but not too
troublesome so far.

There are disadvantages however:
1. overhead of function call of a context property for every size specifier
2. multimonitor situations, we would like to have different scales on
individual monitors. Context property not allowing that, so we need to
rethink that.
3. does conflict with DevicePixelRatio somewhat. I've worked hard to
make them work together, but the complexity is unpleasant, and I’ve
still not solved all issues.
4. there are a few other internal non-visual tweaks Qt does which
depends on DPR, but naturally not our grid unit value. This is why 3.
above (marrying DPR and grid units) is being done at all, else we’d just
ignore DPR for longer.


So I'd be very happy to see some work on adding some concept of units to
QML. Perhaps we are asking too much to allow registration of a custom
unit system at QmlEngine startup? We'd love to enable app authors to write:

Rectangle { width: 10gu; height 5gu; }

and have the value runtime updatable. I understand that would make
parsing harder though, and that our requirements are probably more
complex than the norm.



Instead, I thought about embracing your proposed logical/physical pixels
approach. Our requirements would mean we have to allow logical pixels to
be more varied than x2, x3... of the physical pixels - i.e. need float
DPR values.

However one of the fundamental ideas of the grid unit was to help UI
layout consistency - it helps developers line-up their UI elements to be
visually appealing. To look best, elements should be positioned on
pixel-boundaries to ensure sharp edges. So units.gu always returns an
integer.

But using a pure float scale with your proposed logical pixels (or just
today’s QML with a float DPR), I fear that something like:
  Rectangle { color: “red”; width: 10; height: 10; x: 5 }
with a 1.5x scale, will be positioned at 7.5px and so will not have a
sharp left/right edge.


So unfortunately I fear your physical/logical pixels proposal is not of
much use to us on Ubuntu Touch. We can use them to replace our units.dp
"device pixels" thing, but our primary scaling system: grid units, won't
work with it.

Thanks for looking into this nonetheless.
-Gerry





On 18/02/16 10:50, Hausmann Simon wrote:
> Hi,
> 
> A little while ago Lars and I proposed to introduce physical units in the QML 
> language for use in QtQuick. The idea was to make it easier to write user 
> interfaces that adapt to different display resolutions by "pinning" your UI 
> to physical dimensions. For example you could say
> 
> Image {
> source: "mypprofilephoto.png"
> width: 5cm
> height: 5cm
> }
> 
> and the image size in physical pixels would scale accordingly to always 
> produce a 5cmx5cm profile image on the screen. The proposed units included 
> "px", which was really an alias for nothing.
> 
> We've had some very good discussions around this at last year's contributor 
> summit as well as in smaller face-to-face discussions. The main feedback I 
> recall was that this would seem like a nice feature on paper but in practice 
> people create their resolution independent interfaces using the current 
> "pixels" and a scale factor that they introduce in a qml file or as a context 
> property. That's another way of saying that perhaps the feature wouldn't 
> really find any use, which is fair :). Instead the desire was expressed that 
> making it _easier_ to scale "logical" pixels in the application would perhaps 
> be better.
> 
> So today during a discussion another idea came up:
> 
> (1) In order to make it really easy to scale "logical" pixels without having 
> to introduce your own context property or factor in a .qml file that you 
> multiply everywhere, we could turn the regular "pixels" in QtQuick into truly 
> logical pixels that scale with an application wide (or window wide) factor. 
> So Image { width: 100 ... } will scale automatically from 100 logical pixels 
> 

Re: [Development] Making ItemSelectionModel more useful

[Stephen Kelly]

On 20/02/16 13:19, Alberto Mardegan wrote:

Hi all!
   Since Qt 5.5, the QItemSelectionModel class is exposed to QML as
ItemSelectionModel (in the QtQml.Models module):

http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html

Apart from having almost no documentation, this component seems to be
rather hard to use in QML: its methods work with QModelIndex (while all
the models I've ever used in QML just speak row numbers) or
QItemSelection, which I believe is not usable in QML at all (at least,
it's not documented as a QML component).


Hi Alberto,

I think you're right about the integration of QAbstractItemModel related 
classes and QML types not being ideal. The recent addition of 
QItemSelectionModel support (for the TreeView) is a significant step 
forward, but some utilities are still missing.


Mostly what's missing is just some declarative-friendly APIs for things 
that already exist in an imperative form. I've written several such 
components in work over the last year which I am upstreaming when I get 
the chance.


Here's the SelectionInfo element, which I find particularly useful, and 
I just now uploaded:


 https://codereview.qt-project.org/#/c/150234/

It allows querying in a declarative way whether a particular QModelIndex 
is 'selected' or 'current'. I'd be happy for any feedback at this point!


Thanks,

Steve.

--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Announce] Qt 5.6.0 RC released

[Helio Chissini de Castro]

Hello Jani

Thanks for the packages and submodules in .tar.xz

We can confirm from our side that at least in Fedora all modules compiled
fine and
are in testing repositories.

Regards


On Wed, Feb 24, 2016 at 6:41 AM, List for announcements regarding Qt
releases and development  wrote:

> Hi all,
>
>
>
> Qt 5.6.0 RC is now released, see
> http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/
>
>
>
> Big thanks to everyone involved!
>
>
> Best regards,
>
> Jani Heikkinen
>
> Release Manager | The Qt Company
>
>
>
> The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu,
> Finland
>
> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @
> Qtproject Facebook: www.facebook.com/qt
>
>
> 
>
> ___
> Announce mailing list
> annou...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/announce
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Reduced availability

[Milian Wolff]

On Dienstag, 23. Februar 2016 20:13:01 CET Thiago Macieira wrote:
> Hello
> 
> This to let everyone know I have been and will continue to be extremely busy
> with other projects at work. Please do not expect me to react to Gerrit
> reviews (mine or someone else's) until mid-April.
> 
> If you need my attention, please send me an email or ping me on IRC.
> 
> If any of my pending changes should become needed before April, please
> update and push it.
> 
> I will continue to read email and attend the release meetings.

Hey Thiago,

there is at least one change for 5.7 where people are currently blocked 
waiting for your input and expertise:

Optimized QReadWriteLock:
https://codereview.qt-project.org/#/c/140322/

I'd really like to see this get merged sooner rather than later to extend the 
exposure of the patch.

Thanks

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development