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

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

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

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

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

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.

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

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

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