Re: [Development] ListView and spaces QTBUG-46488

[Stephen Kelly via Development]

You're right, as discussed on IRC, the bugs are different. QTBUG-53263 
is a regression in Qt 5.6, and QTBUG-46488 is much older than that. 
Sorry for the noise!



On 18/05/16 14:15, Filippo Cucchetto wrote:
Maybe they're two different issues because in 
https://bugreports.qt.io/browse/QTBUG-46488

it doesn't seem to be related to the number of items shown.
But anyway these are really important bugs for those who use ListView+QAIM

2016-05-18 13:38 GMT+02:00 Stephen Kelly via Development 
<development@qt-project.org <mailto:development@qt-project.org>>:



This can also be reproduced with ListView instead of TreeView:

https://bugreports.qt.io/browse/QTBUG-53263


Thanks,

Stephen


On 18/05/16 12:21, Filippo Cucchetto wrote:

Hello everyone,
i would like to warn about this serious bug in QDeclarative that
could hit
users of ListViews with QAIM
https://bugreports.qt.io/browse/QTBUG-46488
I know that Gabriel gave it a look some time ago but he seems to
be quite
busy right now. I also gave it a look on my own but a quick fix
is a no go. Furthermore
some knownledge of the internals of QtDeclarative are needed.

-- 
Filippo Cucchetto



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


-- 
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 <mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development




--
Filippo Cucchetto


--
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] ListView and spaces QTBUG-46488

[Stephen Kelly via Development]

This can also be reproduced with ListView instead of TreeView:

 https://bugreports.qt.io/browse/QTBUG-53263


Thanks,

Stephen

On 18/05/16 12:21, Filippo Cucchetto wrote:

Hello everyone,
i would like to warn about this serious bug in QDeclarative that could hit
users of ListViews with QAIM
https://bugreports.qt.io/browse/QTBUG-46488
I know that Gabriel gave it a look some time ago but he seems to be quite
busy right now. I also gave it a look on my own but a quick fix is a 
no go. Furthermore

some knownledge of the internals of QtDeclarative are needed.

--
Filippo Cucchetto


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


--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

Thanks Andrew for these notes! You did really well to capture the key points 
from a complex and meandering discussion.






>- (Stephen) "In reality, rewriting Qt's build system in CMake will
>actually be a PITA, and will require changes to CMake to make everything 
>better"


I think something was lost in transit on this point. I don’t think it would be 
a PITA to write a CMake buildsystem for Qt. I recall the above point was in 
reference to ‘compiling host tools and using them in the build while cross 
compiling’. The way CMake makes that possible currently(!) is implemented 
separately to the core of CMake with the ExternalProject module. 

It can be implemented better in the core of CMake if someone wants to do so and 
that would be better, but it’s not very urgent and no one has volunteered to do 
it.

Even if CMake did better in that scenario though, that’s not the reason Qt is 
not going to use CMake, so it doesn’t matter anyway.

Thanks,

Steve.

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 06/09/16 02:13, Thiago Macieira wrote:

Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via
Development escreveu:

I think something was lost in transit on this point. I don’t think it would
be a PITA to write a CMake buildsystem for Qt. I recall the above point was
in reference to ‘compiling host tools and using them in the build while
cross compiling’. The way CMake makes that possible currently(!) is
implemented separately to the core of CMake with the ExternalProject
module.

That's how it should be. Every single project out there, except for Qt and
possibly GCC itself, builds for one single target. Building something for one
architecture so that it can be run to build another is ungainly and
unexpected.

Whenever you cross-compile Qt, you end up with tools that can only be run on
the host. So Qt's cross-compilation mechanism can't be used to build tools
that can be run on the target platform.



Yes, I have had problems with that in the past too. However, there's 
nothing preventing building the tools for both the host and the target. 
I think that would be cleaner (This is independent of buildsystem tool - 
I would also be happy if the current qmake build did this).


Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 06/09/16 20:30, Cristian Adam wrote:


Maybe "bad feedback" is strong, but it was non constructive and lead 
to the removal of the Qbs generator.




To clarify even further: the contribution was wip, the contributor was 
surprised at it being merged, and happy with it being reverted:


https://github.com/Kitware/CMake/pull/145#issuecomment-104292606

Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 06/09/16 20:30, Cristian Adam wrote:


Maybe "bad feedback" is strong, but it was non constructive and lead 
to the removal of the Qbs generator.




To clarify even further: the contribution was wip, the contributor was 
surprised at it being merged, and happy with it being reverted:


 https://github.com/Kitware/CMake/pull/145#issuecomment-104292606

Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 08/09/16 14:48, Milian Wolff wrote:

Someone else also told me that this is apparently harder then I thought it is
with CMake, when the name of the output files of a code generator is not
known. It is possible, but far from easy esp. when you don't have control over
the generator script (though one can always use a wrapper). I see now that
having support for this in QBS can be advantageous for the cases where one has
such cases. Thankfully, I never ran into this so far, ever.



All the talk about a 'dynamic build graph' of QBS was about satisfying 
this kind of case in a nice way. That's what makes it interesting to me 
- is that what will make QBS successful?


Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 08/09/16 14:34, Christian Kandeler wrote:

On 09/08/2016 02:03 PM, Bo Thorsen wrote:

Ok, go try it. Create a simple python or perl script that reads a file.
The file just has a single number N inside it. And based on N the script
outputs those files:



Here's the CMake version:


cmake_minimum_required(VERSION 3.5.0)
project(cmaketest)

find_package(Qt5Core REQUIRED)

execute_process(
  COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list 
${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
  OUTPUT_VARIABLE fileList
)

string(REPLACE "\n" ";" fileList ${fileList})

add_custom_command(OUTPUT ${fileList}
  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/generator.py 
${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
)

qt5_wrap_cpp(moc_files ${fileList})

add_executable(servertest servertest.cpp ${fileList} ${moc_files})
target_link_libraries(servertest Qt5::Core)
target_include_directories(servertest PRIVATE 
${CMAKE_CURRENT_BINARY_DIR}/genoutput)


However, it is cheating in the same way that the QBS version from
Christian is cheating - it assumes '--list' exists:


In qbs:

 outputArtifacts: {
 var p = new Process();
 try {
 p.exec("path_to_script", ["--list", input.filePath]);
 var files = p.readStdout.split("\n");



Christian, can you create a version which does not require --list? As 
far as I understand, that is the point of the QBS dynamic build graph. I 
would like to make sure my understanding is correct. You can find my code at


 https://github.com/ske-ableton/generated-build-inputs

if that helps.

Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 08/09/16 14:34, Christian Kandeler wrote:

On 09/08/2016 02:03 PM, Bo Thorsen wrote:

Ok, go try it. Create a simple python or perl script that reads a file.
The file just has a single number N inside it. And based on N the script
outputs those files:


Here's the CMake version:

cmake_minimum_required(VERSION 3.5.0)
project(cmaketest)

find_package(Qt5Core REQUIRED)

execute_process(
  COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list 
${CMAKE_CURRENT_BINARY_DIR}/genoutput 5

  OUTPUT_VARIABLE fileList
)

string(REPLACE "\n" ";" fileList ${fileList})

add_custom_command(OUTPUT ${fileList}
  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/generator.py 
${CMAKE_CURRENT_BINARY_DIR}/genoutput 5

)

qt5_wrap_cpp(moc_files ${fileList})

add_executable(servertest servertest.cpp ${fileList} ${moc_files})
target_link_libraries(servertest Qt5::Core)
target_include_directories(servertest PRIVATE 
${CMAKE_CURRENT_BINARY_DIR}/genoutput)




However, it is cheating in the same way that the QBS version from 
Christian is cheating - it assumes '--list' exists:



In qbs:

 outputArtifacts: {
 var p = new Process();
 try {
 p.exec("path_to_script", ["--list", input.filePath]);
 var files = p.readStdout.split("\n");



Christian, can you create a version which does not require --list? As 
far as I understand, that is the point of the QBS dynamic build graph. I 
would like to make sure my understanding is correct. I've attached the 
generator and servertest.cpp if that helps.


Thanks,

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

#!/usr/bin/env python

import os, sys

if len(sys.argv) == 4 and sys.argv[1] == "--list":
outPath = sys.argv[2]
numFiles = int(sys.argv[3])

print(os.path.join(outPath, "server.h"))

for num in range(numFiles):
print(os.path.join(outPath, "method%s.h" % num))

sys.exit(0)

if len(sys.argv) == 3:
outPath = sys.argv[1]
numFiles = int(sys.argv[2])

if not os.path.exists(outPath):
os.makedirs(outPath)
else:
print("Incorrect args. Use ./generator.py [--list] /path/to/output numFiles")

with open(os.path.join(outPath, "server.h"), "w") as serverFile:

for num in range(numFiles):
serverFile.write('#include "method%s.h"\n' % num)

serverFile.write("""
class Server {
public:
""")

for num in range(numFiles):
serverFile.write('Method%s* call%s() { return new Method%s; }\n' % (num, num, num))

serverFile.write("""};

""")

for num in range(numFiles):
with open(os.path.join(outPath, "method%s.h" % num), "w") as methodFile:
methodFile.write("""
#include 

class Method%s : public QObject {
  Q_OBJECT
};
""" % num)

#include "server.h"

#include 
#include 

int main(int argc, char** argv)
{
Server server;
auto m2 = server.call2();
if (m2->metaObject()->className() == QStringLiteral("Method2")) {
qDebug() << "PASS";
return 0;
}
qDebug() << "FAIL";
return 1;
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 13/09/16 22:29, Christian Kandeler wrote:

Stephen Kelly wrote:


There is no input file. There is only an input number. The task is from
Bo, who gave it as a simplified example.

Oops, I'm wrong here. Bo said to read the number from a file.
I don't think that changes anything though regarding dynamic build graph
being an advantage.

Sure?

It is trivial:

 https://github.com/ske-ableton/generated-build-inputs/commit/d4ef3c48

Clearly there is some kind of misunderstanding happening here. In 
particular, when I said 'advantage' above, it means 'Qbs can do this 
thing, but CMake can not'.



What about the (lack of) need for two rules to agree in advance about the 
location of a generated file?


I don't know what you are talking about. I don't know what rules have to 
'agree'.



Also, there could be several layers of indirection, with the second set of 
generated files also containing meta data etc.


Please post example code for that. Feel free to start by forking my repo.


You quoted and challenged just one small part of my email. Can you 
answer the rest of it? I want to understand Qbs and what it can do with 
a dynamic build graph which CMake can't do. I made a guess in my email 
in the hope that you would confirm that my assumption is correct, or 
would correct my assumption to fill my understanding.


Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 15/09/16 08:57, Oswald Buddenhagen wrote:

On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote:

I want to understand Qbs and what it can do with a dynamic build graph
which CMake can't do.


there is no such thing


Oh, I'm very surprised by that.

That also means I don't understand the great advantage of Qbs, just when 
I thought I was starting to understand it.


My previous guess about Qbs being able to generate unknown files in a 
particular location and then determine them by an 'ls' equivalent, moc 
them and compile everything is not something Qbs would be able to do.



so what it all comes down to is that qbs is, as in pretty much every
other regard, simply more elegant than cmake


Ok, thanks for clarifying!

I'm still interested in a Qbs solution to the code/repo I posted before. 
A full and preferably working Qbs solution, instead of a snippet, would 
be good for comparison.


Thanks,

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

On 16/09/16 03:07, Christian Kandeler wrote:

Stephen Kelly wrote:


My previous guess about Qbs being able to generate unknown files in a
particular location and then determine them by an 'ls' equivalent, moc
them and compile everything is not something Qbs would be able to do.

I'm having trouble parsing this, but if you mean that your previous guess was wrong, then 
I can tell you it was not; that's exactly what we do for "blackbox tools".


It is probably less confusing for you in the context of the previous 
email I wrote (you didn't respond to that one - I started with "There is 
no input file. There is only an input number."). Feel free to go back to 
read that one and hopefully respond to it.



I'm still interested in a Qbs solution to the code/repo I posted before.
A full and preferably working Qbs solution, instead of a snippet, would
be good for comparison.

That's more than I'm willing to invest during my vacation, but I might come 
back to you later there.


Great, thanks!

--
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

Hi Edward,


You copied the line:


(Stephen) "In reality, rewriting Qt's build system in CMake will 
actually be a PITA, and will require changes to CMake to make everything 
better"



That was a stenography error. Can you remove it?

Thanks,


On 12/09/16 16:08, Edward Welbourne wrote:

For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) 
into:
https://wiki.qt.io/Qt_build_systems_at_QtCon_2016

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


--
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] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly via Development]

> From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of 
> Jean-Michaël Celerier
> Sent: Friday 22 September 2017 13:25
> To: Stephen Kelly 
> Cc: Jean-Michaël Celerier ; 
> development@qt-project.org
> Subject: Re: [Development] New approach to hi-dpi and coordinate system for 
> layouts in Qt 6
> 
> Indeed, this seemed too easy :p 

Right ;p.

> Sligthly related, but the second approach with the coordinates makes me 
> remember
> this bug report (about QML, but the problem space is similar and proposed 
> solutions involved adding units to values): 
> https://bugreports.qt.io/browse/QTBUG-11655

This is a request for physical units.  I mentioned physical units in my 
previous 
mail, but I don't know how important they are for this design, which is not so 
much 
concerned about units, as such, but about multiple screens with different DPIs 
etc.

> > A disadvantage of the QCoordinate approach is that the values are not 
> > comparable
> > to each other without a screen. 
> 
> There is also the problem of a single Qt window between multiple screens with 
> different DPI so it'd be at least one screen per coordinate

I think that's out of scope.  Windows API doesn't even allow accounting for 
that.  Maybe you can go low-level and find some work around, but it's not 
really 
something applications (even outside of Qt) do.

> (maybe even worse if 
> someone wants to use a QCoordinate for computing a distance that would span 
> multiple screens ?)
> 
> > One of the issues raised so far is that this QCoordinate stores only
> > pixels and points, 
> 
> shouldn't this be implemented as a variant instead ? (I mean, Qt6 *will* 
> require C++17, right ? :p) 

Nope. The point is that *both* pixels and points must be stored.  std::variant 
is a sum type.  That's not what's needed here.

Thanks,

Stephen.
 

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

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly via Development]

Hi Jean-Michaël,

The issue is layouting, not painting. Sorry for not making that clear.

Feel free to modify the example code I posted if you think you have a general 
solution with QPen::setCosmetic alone to fix the layout issues.

Thanks,

Stephen.

From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of 
Jean-Michaël Celerier
Sent: Thursday 21 September 2017 11:29
To: Stephen Kelly <stke...@microsoft.com>
Cc: development@qt-project.org
Subject: Re: [Development] New approach to hi-dpi and coordinate system for 
layouts in Qt 6

> making it impossible to specify 'a one/two pixel border'
Correct me if I am wrong, but isn't this what QPen::setCosmetic is used for ?
Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jcelerier.name=02%7C01%7Cstkelly%40microsoft.com%7Ca935be0873684c352c8508d500dba175%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415865659940051=1lMb5KQYE4VI5h4ZWvpQI42CRFLYXIQD648n0r5esEY%3D=0>

On Thu, Sep 21, 2017 at 11:37 AM, Stephen Kelly via Development 
<development@qt-project.org<mailto:development@qt-project.org>> wrote:

Hi,

Qt 5 has several approaches to attempting to size/scale a UI when moving 
between screens which have
different APIs.  There is a summary here:

https://vicrucann.github.io/tutorials/osg-qt-high-dpi/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvicrucann.github.io%2Ftutorials%2Fosg-qt-high-dpi%2F=02%7C01%7Cstkelly%40microsoft.com%7Ca935be0873684c352c8508d500dba175%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415865659940051=VYg7fbhhcBr3f69cSTiFRV8TxXCUMJ%2BuJsiGOF5WyGE%3D=0>

The approaches available currently either

1) scale everything after rendering (eg with SetProcessDPIAware())
2) scale coordinates to screen metrics before rendering 
(QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))

The first approach gives a blurry result because of up/down scaling and is not 
satisfying.

The second approach scales all coordinates, making it impossible to specify 'a 
one/two pixel border' without that getting scaled too. Additionally, the 
AA_EnableHighDpiScaling will only apply integer scaling, so on a screen with 
150% scaling, the widget is scaled to 200%.

Adding a floating-point based API would not be a solution because it would 
result in painting artefacts.  This is an important point.  An approach like 
that won't satisfy designers.  The approach in

https://codereview.qt-project.org/#/c/157174/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodereview.qt-project.org%2F%23%2Fc%2F157174%2F=02%7C01%7Cstkelly%40microsoft.com%7Ca935be0873684c352c8508d500dba175%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415865659940051=9bK3ZwKx91cmG3qJIcNToe5ajsUYq0P5JNmUuBai%2Fys%3D=0>

resolves a scaling issue but does not address painting artefacts.

So, we need to find flexible and imaginative solutions.

I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP 
doesn't (yet?) go as far as approaches to addressing the problem, so I am 
writing here to see if there is wider interest in the topic.  One of the points 
he made is that some users are happy with the current state of Qt APIs and 
behavior, or would be happy with downsampling after rendering (blurry).

I don't know how widespread that acceptance would be, but I've worked on 
several teams where it would not be acceptable.

The underlying problem is that the Qt APIs do not provide a way to specify the 
units to use in layouts AND to combine values with those units.  We need to be 
able to specify coordinates which will be scaled to an appropriate number of 
pixels on the screen, but also to be able to specify coordinates in exact 
pixels (common for things like having a 'one/two pixel border' etc).  Then, Qt 
should compute the actual number of pixels to paint based on the current screen.

The approach we discussed (this is only the ideas-stage, remember!) with Morten 
is to change APIs which specify layouts to use a new unit-sensitive coordinate 
type instead of int.  This new QCoordinate type stores values in both points 
and pixels and has a toPixels method which computes the required pixel value 
for the screen.

https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fanonymous%2Fd08e0e79b05237a765e23849bbe2a78d=02%7C01%7Cstkelly%40microsoft.com%7Ca935be0873684c352c8508d500dba175%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636415865659940051=3lAJTdxL0UIj6366wsWIAwKb9cRxNpTLh26xNXc02hs%3D=0>

QCoordinates can be created with C++11 user-defined literal niftyness:

  auto coord = 34_pt + 4_px;

This also implies a requirement to have QSize/QPoint etc equivalents based on 
QCoordinate.  We haven't put much thought into this code duplicatation etc, 
focusing only on whether we can solve the prob

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly via Development]

> It's not like devices change DPI, though if
> you have multiple monitors this assumption may be invalid if the user moves
> the window to between screens or another screen.

This is indeed the topic of this thread. The other issues you raise look like 
they should be raised on another thread.

Thanks,

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

[Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly via Development]

Hi,

Qt 5 has several approaches to attempting to size/scale a UI when moving 
between screens which have
different APIs.  There is a summary here:

https://vicrucann.github.io/tutorials/osg-qt-high-dpi/

The approaches available currently either

1) scale everything after rendering (eg with SetProcessDPIAware())
2) scale coordinates to screen metrics before rendering 
(QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))

The first approach gives a blurry result because of up/down scaling and is not 
satisfying.

The second approach scales all coordinates, making it impossible to specify 'a 
one/two pixel border' without that getting scaled too. Additionally, the 
AA_EnableHighDpiScaling will only apply integer scaling, so on a screen with 
150% scaling, the widget is scaled to 200%.

Adding a floating-point based API would not be a solution because it would 
result in painting artefacts.  This is an important point.  An approach like 
that won't satisfy designers.  The approach in

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

resolves a scaling issue but does not address painting artefacts.

So, we need to find flexible and imaginative solutions.

I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP 
doesn't (yet?) go as far as approaches to addressing the problem, so I am 
writing here to see if there is wider interest in the topic.  One of the points 
he made is that some users are happy with the current state of Qt APIs and 
behavior, or would be happy with downsampling after rendering (blurry).

I don't know how widespread that acceptance would be, but I've worked on 
several teams where it would not be acceptable.

The underlying problem is that the Qt APIs do not provide a way to specify the 
units to use in layouts AND to combine values with those units.  We need to be 
able to specify coordinates which will be scaled to an appropriate number of 
pixels on the screen, but also to be able to specify coordinates in exact 
pixels (common for things like having a 'one/two pixel border' etc).  Then, Qt 
should compute the actual number of pixels to paint based on the current screen.

The approach we discussed (this is only the ideas-stage, remember!) with Morten 
is to change APIs which specify layouts to use a new unit-sensitive coordinate 
type instead of int.  This new QCoordinate type stores values in both points 
and pixels and has a toPixels method which computes the required pixel value 
for the screen.

https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d

QCoordinates can be created with C++11 user-defined literal niftyness:

  auto coord = 34_pt + 4_px;

This also implies a requirement to have QSize/QPoint etc equivalents based on 
QCoordinate.  We haven't put much thought into this code duplicatation etc, 
focusing only on whether we can solve the problems with this approach (or 
another approach?) at all.

A disadvantage of the QCoordinate approach is that the values are not 
comparable to each other without a screen.  So operator<() can't be implemented 
for example, but a separate purposeful API would be needed for things like that.

One of the issues raised so far is that this QCoordinate stores only pixels and 
points, but not other units which may be wanted, such as physical units like 
centimeters.  Morten noted that there are not many known use-cases for such 
units and that they mean little if a projector is in use.

This is of course a Qt 6 change, and now is approximately the time to discuss 
Qt 6 changes.  I don't know if anyone will be in Berlin who wants to discuss 
this at QtCS.  Shout if you want to discuss this there and I'll see if I can go 
over for it.

Thanks,

Stephen.

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

Re: [Development] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Stephen Kelly via Development]

> The approaches available currently either
> 
> 1) scale everything after rendering (eg with SetProcessDPIAware())
> 2) scale coordinates to screen metrics before rendering 
> (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
> 
> The first approach gives a blurry result because of up/down scaling and is 
> not satisfying.
> 
> The second approach scales all coordinates, making it impossible to specify 
> 'a one/two pixel border' without 
> that getting scaled too. Additionally, the AA_EnableHighDpiScaling will only 
> apply integer scaling, so on a 
> screen with 150% scaling, the widget is scaled to 200%.  

I had a request to explain the problem with screenshots, so I created 

 https://bugreports.qt.io/browse/QTBUG-63402

with screenshots showing the previously posted code with the available 
approaches and APIs to solving
the problem, along with a screenshot showing the result of this proposal.

Thanks,

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

Re: [Development] CMake Workshop Summary

[Stephen Kelly via Development]

As a deliberate design choice years ago, we put the major version in the 
package name because it avoids a class of user errors and confusion, and 
because it allows a single buildsystem with targets linking to either Qt 4 or 
Qt 5 (CMake ensures that nothing attempts to link to both).

Thanks,

Stephen.

From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday 13 February 2019 10:47
To: Vitaly Fanaskov ; development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary


That may be possible to implement. It requires the work to be done upstream in 
cmake's FindQt.cmake. It also requires maintaining compatibility with Qt 3 and 
4. See


https://devdocs.io/cmake~3.12/module/findqt

I suggest for you to get in touch with the CMake developers to see what they 
think about it.

Simon

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Vitaly Fanaskov 
mailto:vitaly.fanas...@qt.io>>
Sent: Wednesday, February 13, 2019 11:22
To: development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary


Hi Simon,



Thank you for the update.



It's not clear why you included version to a package name (e.g. Qt5/Qt6). With 
CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)

Perhaps it would be better, what do you think?


On 2/13/19 10:33 AM, Simon Hausmann wrote:
Hi,

On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the 
attempt of building Qt with CMake. I'd like to give a brief summary of this 
workshop.

Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.

A very early visible artifact was the creation of a wiki page (like all good 
workshops ;-)


https://wiki.qt.io/CMake_Port

With such a large group, we were able to make good progress:

* We were able to fix the artifacts of "make install" in qtbase to allow 
for building an external module (qtsvg) and sample apps. The plan for allowing 
people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:

(1) In your application use either find_package(Qt5) or 
find_package(Qt6)
(2) Always use Qt::Core, Qt::Gui, etc. for linkage
(3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to Qt5's 
cmake support

* The script to converting .pro files to CMakeLists.txt is becoming really 
good. The goal is to convert all scopes and (source) file names correctly. 
Right now the repo contains incremental conversions with hand-edits.

* We're working on installing the latest cmake (as required) in the 
provisioning setup, so that we can get a building CI as soon as possible.

* We were able to verify that cross-compilation works well. The main 
challenge is ensuring that third-party libraries that used to be copied in 
src/3rdparty are either installed in the sysroot or can be found outside.

* We discussed and experimented with different ways of making static builds 
robust. So static builds themselves work already, but what we're looking into 
in particular is an automatic way of propagating Qt internal dependencies (such 
as double-conversion) correctly to the build process of the application that is 
not fragile.

* We added a lot more plugins and platform support libraries to the build 
process and did many improvements to the finding of external libraries.


Our overall next goal is completing the build on Linux, macOS and Windows, 
cross-compilation, static builds and basic CI build support.


Simon



___

Development mailing list

Development@qt-project.org

https://lists.qt-project.org/listinfo/development

--

Best Regards,



Fanaskov Vitaly

Senior Software Engineer



The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake Workshop Summary

[Stephen Kelly via Development]

> The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is 
> quite simple API wise:
>
> (1) In your application use either find_package(Qt5) or 
> find_package(Qt6)

Will this support COMPONENTS? I would never recommend using COMPONENTS because 
it can get odd in the case of multiple calls. Will there be a 
find_package(Qt6Core) etc too?

> (2) Always use Qt::Core, Qt::Gui, etc. for linkage
> (3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to 
> Qt5's cmake support

This is quite different to how the Qt4-to-5 transition was done. Is there any 
comparison of different approaches? Will Qt-users be able to have a single 
buildsystem with some targets linking to Qt 5 and others linking to Qt 6, as 
was possible in the 4-to-5 transition (because of the different target names)? 
As the Qt5:: prefixed names already exist those could be used in that case, but 
if there are no Qt6:: prefixed target names, then that won't be possible in Qt6 
to Qt7 transition?

Thanks,

Stephen.

From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday 13 February 2019 09:33
To: development@qt-project.org
Subject: [Development] CMake Workshop Summary

Hi,

On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the 
attempt of building Qt with CMake. I'd like to give a brief summary of this 
workshop.

Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.

A very early visible artifact was the creation of a wiki page (like all good 
workshops ;-)


https://wiki.qt.io/CMake_Port

With such a large group, we were able to make good progress:

* We were able to fix the artifacts of "make install" in qtbase to allow 
for building an external module (qtsvg) and sample apps. The plan for allowing 
people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:

(1) In your application use either find_package(Qt5) or 
find_package(Qt6)
(2) Always use Qt::Core, Qt::Gui, etc. for linkage
(3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to Qt5's 
cmake support

* The script to converting .pro files to CMakeLists.txt is becoming really 
good. The goal is to convert all scopes and (source) file names correctly. 
Right now the repo contains incremental conversions with hand-edits.

* We're working on installing the latest cmake (as required) in the 
provisioning setup, so that we can get a building CI as soon as possible.

* We were able to verify that cross-compilation works well. The main 
challenge is ensuring that third-party libraries that used to be copied in 
src/3rdparty are either installed in the sysroot or can be found outside.

* We discussed and experimented with different ways of making static builds 
robust. So static builds themselves work already, but what we're looking into 
in particular is an automatic way of propagating Qt internal dependencies (such 
as double-conversion) correctly to the build process of the application that is 
not fragile.

* We added a lot more plugins and platform support libraries to the build 
process and did many improvements to the finding of external libraries.


Our overall next goal is completing the build on Linux, macOS and Windows, 
cross-compilation, static builds and basic CI build support.


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

Re: [Development] CMake Workshop Summary

[Stephen Kelly via Development]

> Have a super-project that allows building all of Qt with one call to "cmake", 
> a call to "cmake --build" and finally "$maketool install".

Note that instead of "$maketool install" you could recommend the portable 
"cmake --build . --target install". I don't think msbuild accepts a 'install' 
argument for example :).

Thanks,

Stephen.


From: Development  On Behalf Of Simon 
Hausmann
Sent: Wednesday 13 February 2019 10:06
To: Alexandru Croitor ; development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary



We briefly discussed the topic and it's my understanding that an agreement 
exists to support two types of builds:

(1) Build a repo, install it, build the next repo, install it, etc.
(2) Have a super-project that allows building all of Qt with one call to 
"cmake", a call to "cmake --build" and finally "$maketool install".

The latter has not been "developed" yet but I think it's necessary to allow for 
a convenient transition for the users of Qt.

Simon

From: Alexandru Croitor
Sent: Wednesday, February 13, 2019 10:56
To: Simon Hausmann; 
development@qt-project.org
Subject: Re: CMake Workshop Summary


Hi,



Thanks for the write up and summary.



Do you know if there has been any discussion on separate module builds vs qt5 
builds?

aka

cd qtbase && cmake && make install && cd qtsvg && cmake && make install

vs

cd qt5 && cmake && make install

?


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Simon Hausmann mailto:simon.hausm...@qt.io>>
Sent: Wednesday, February 13, 2019 10:33:13 AM
To: development@qt-project.org
Subject: [Development] CMake Workshop Summary

Hi,

On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the 
attempt of building Qt with CMake. I'd like to give a brief summary of this 
workshop.

Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.

A very early visible artifact was the creation of a wiki page (like all good 
workshops ;-)


https://wiki.qt.io/CMake_Port

With such a large group, we were able to make good progress:

* We were able to fix the artifacts of "make install" in qtbase to allow 
for building an external module (qtsvg) and sample apps. The plan for allowing 
people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:

(1) In your application use either find_package(Qt5) or 
find_package(Qt6)
(2) Always use Qt::Core, Qt::Gui, etc. for linkage
(3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to Qt5's 
cmake support

* The script to converting .pro files to CMakeLists.txt is becoming really 
good. The goal is to convert all scopes and (source) file names correctly. 
Right now the repo contains incremental conversions with hand-edits.

* We're working on installing the latest cmake (as required) in the 
provisioning setup, so that we can get a building CI as soon as possible.

* We were able to verify that cross-compilation works well. The main 
challenge is ensuring that third-party libraries that used to be copied in 
src/3rdparty are either installed in the sysroot or can be found outside.

* We discussed and experimented with different ways of making static builds 
robust. So static builds themselves work already, but what we're looking into 
in particular is an automatic way of propagating Qt internal dependencies (such 
as double-conversion) correctly to the build process of the application that is 
not fragile.

* We added a lot more plugins and platform support libraries to the build 
process and did many improvements to the finding of external libraries.


Our overall next goal is completing the build on Linux, macOS and Windows, 
cross-compilation, static builds and basic CI build support.


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

Re: [Development] CMake Workshop Summary

[Stephen Kelly via Development]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Wednesday 13 February 2019 16:36
> To: development@qt-project.org
> Subject: Re: [Development] CMake Workshop Summary
> 
> On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development
> wrote:
> > The problem is, besides the reasons Simon mentioned, that just using
> > "Qt" as the package prefix will make it more difficult for distros to
> > co-install the CMake config files for different Qt versions.
> >
> > Still all up for discussions though. Happy to get more people involved.
> 
> Is it possible to use Qt6 and make the system export "Qt::" as an alias,
> possibly behind an extra option passed in find_package()? 

I think Kevin was talking about the cmake package file names.

> If an alias is not
> possible, is it possible to make find_package() set variables like ${QTCORE}
> that will be either Qt5::Core or Qt6::Core, depending on the one found?

The problem with variables is they can be empty and it is not an error 
condition:

# CMake issues no error:
target_link_libraries(mything PRIVATE 
${OOPS_SOMETHING_WAS_NOT_FOUND}
${OOPS_TYPO}
)

Eg if you write this:

find_package(Qt6)

target_link_libraries(mything PRIVATE 
${QtCore_LIBRARY}
${QTCore_LIBRARY}
${QtCore_LIBRARIES}
# etc
)

Cmake will issue no error even if Qt6 is not found. 

CMake treats explicitly written targets with '::' in their name in a special 
way. It ensures that they exist

# CMake errors if the Qt5::Core target is not available (either because 
# someone wrote a typo, or because someone forgot to call 
# find_package(), or the find_package() call is there but Qt5 
# was not found)
target_link_libraries(mything PRIVATE Qt5::Core)

Of course it is easy to create a `Qt5or6::Core` target for transitional use and 
get all the benefits.

target_link_libraries(mything PRIVATE Qt5or6::Core)

Thanks,

Stephen.

> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> qt-
> project.org%2Flistinfo%2Fdevelopmentdata=02%7C01%7Cstkelly%40
> microsoft.com%7Ce621428df88a451491a908d691d18d1a%7C72f988bf86f141
> af91ab2d7cd011db47%7C1%7C0%7C636856726536013190sdata=UwtI
> yJIQOkx%2FVpXirw6yFeUqoQOaYGC3oOUrlNNZ4O4%3Dreserved=0
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake Workshop Summary

[Stephen Kelly via Development]

> I think the ability to compile an application with Qt 5 or 6 and the same 
> build system is of critical importance for the success of Qt 6.

Certainly. We had the same requirement with Qt 4+5 and had a solution for it. 
I'm wondering if you considered alternatives to what you're going to do and 
what the trade offs were.

User code will use both

find_package(Qt5)

and

find_package(Qt6)

in the same buildsystem. Having multiple packages (Qt5 and Qt6) which provide 
targets of the same name is sure to lead to new classes of user errors. Perhaps 
you need to make that an error condition?

Also, anyone providing support to users won't be able to tell whether someone 
using `Qt::Gui` is using Qt 5 or 6.

Anyway I suppose if you only provide `Qt::` prefixed targets now you can 
provide `Qt6::` prefixed targets in the future easily enough.

Thanks,

Stephen.


From: Simon Hausmann 
Sent: Wednesday 13 February 2019 12:53
To: Stephen Kelly ; Vitaly Fanaskov 
; development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary


I think the deliberate design choice to separate Qt4 and 5 visibly in the "API" 
(targets) was a wise choice at that point.

For the future and with Qt 6 in mind, I think we should do it differently. I 
think the ability to compile an application with Qt 5 or 6 and the same build 
system is of critical importance for the success of Qt 6. Today's distribution 
of Qt versions and scale of users IMHO justifies the effort required. I think 
the number of people benefiting from such a design largely exceeds the users 
who want to use one build system to link two binaries against different major 
Qt versions "from within".

That is why I didn't pursue trying to modify FindQt.cmake in cmake upstream 
myself. I think just solving this for 5/6 would be sufficient to achieve the 
goal.


Simon

From: Stephen Kelly mailto:stke...@microsoft.com>>
Sent: Wednesday, February 13, 2019 12:32
To: Simon Hausmann; Vitaly Fanaskov; 
development@qt-project.org
Subject: RE: [Development] CMake Workshop Summary




As a deliberate design choice years ago, we put the major version in the 
package name because it avoids a class of user errors and confusion, and 
because it allows a single buildsystem with targets linking to either Qt 4 or 
Qt 5 (CMake ensures that nothing attempts to link to both).



Thanks,



Stephen.



From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Simon Hausmann
Sent: Wednesday 13 February 2019 10:47
To: Vitaly Fanaskov mailto:vitaly.fanas...@qt.io>>; 
development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary





That may be possible to implement. It requires the work to be done upstream in 
cmake's FindQt.cmake. It also requires maintaining compatibility with Qt 3 and 
4. See




https://devdocs.io/cmake~3.12/module/findqt



I suggest for you to get in touch with the CMake developers to see what they 
think about it.



Simon



From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Vitaly Fanaskov 
mailto:vitaly.fanas...@qt.io>>
Sent: Wednesday, February 13, 2019 11:22
To: development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary



Hi Simon,



Thank you for the update.



It's not clear why you included version to a package name (e.g. Qt5/Qt6). With 
CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)

Perhaps it would be better, what do you think?



On 2/13/19 10:33 AM, Simon Hausmann wrote:

Hi,



On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the 
attempt of building Qt with CMake. I'd like to give a brief summary of this 
workshop.



Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.



A very early visible artifact was the creation of a wiki page (like all good 
workshops ;-)




https://wiki.qt.io/CMake_Port



With such a large group, we were able to make good progress:



* We were able to fix the artifacts of "make install" in qtbase to allow 
for building an external module (qtsvg) and sample apps. The plan for allowing 
people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:



(1) In your application use either