Re: [Development] CMake Workshop Summary

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

Re: [Development] CMake Workshop Summary

> 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

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,

Re: [Development] CMake Workshop Summary

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

Re: [Development] CMake Workshop Summary

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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:

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

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:

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

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

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

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:

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

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:

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

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

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

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

Re: [Development] ListView and spaces QTBUG-46488

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

Re: [Development] ListView and spaces QTBUG-46488

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