Re: [Development] Qt modules, API changes and Qt 6

[Simon Hausmann]

Hi,

I would like to provide an update to this (old) thread based on the 
development in the past months and weeks.

Am 15.02.19 um 10:30 schrieb Frederik Gladhorn:
> Hi,
>
> On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote:
>> Summing up the discussion here. It looks like people overall agree that the
>> pinned dependency approach (option 3) sounds better than what we currently
>> have. The main concern was CI capacity, but Frederik believes that with
>> enough storage capacity for build artefacts this will not be worse than
>> what we have today with all the failed qt5.git integrations.
>   
>> The only other option that was seriously considered was a more monolithic
>> repo (option 4). Disadvantages here are that it would require more work on
>> the CI front to make testing times bearable, and it doesn’t give us a very
>> flexible approach with regards to adding/removing modules. This is
>> something that option 3 will nicely give us, as it treats all repositories
>> the same way. Option 3 does btw not exclude that we later on merge some
>> repositories if we feel that makes sense.
>   
>> So let’s go with option 3. Frederik will be leading the work to get this
>> implemented.
>   
>> As far as I can see, it requires some changes to CI so that we have the
>> dependencies encoded in each repository, a bot to automatically push sha1’s
>> of dependencies forward and some monitoring to alert us if modules get left
>> behind.
>
> I have indeed been playing with this, and I think I have an implementation
> that works when it comes to resolving dependencies based on the idea.
>
> After some pondering and starting with ini files, I settled on yaml, since we
> probably want to extend the data later on and I would like this to be easily
> human and machine read- and writable.
>
> My current files look like this:
>   dependencies:
>   qt/qtbase:
>   ref: 698078680fc5a6870177af285fa50c0d8a7c0bc3
>   url: code.qt.io
>   qt/qtsvg:
>   ref: 2ae3c52fc061f574c9582bf58963fb3996724fbf
>   url: code.qt.io
>
>
> This is for qt/qtdeclarative, sha1's taken from qt5.git at some point.
> Then there is the question of what the file name should be. Should it be at
> the top-level or in a coin subdirectory? dependencies.yaml?
>
>
> I have not yet worked on the bot doing the module updates (which may turn out
> to be the harder part).
> I don't think this can go live before we have that written as well.

Thanks to Frederik and Aapo, Coin has learned to read and utilize the 
dependencies.yaml files in repositories when present. This permits 
pinning dependencies to specific sha1s.


The second part was a tool to maintain these permanent pinnings, by 
posting updates to Gerrit through the graph of dependencies. This tool 
is now ready for use and is based on a fairly simple algorithm. I'd like 
to put this tool into Gerrit in the near future. Meanwhile, here's a 
description of how it works from the README:

## Algorithm

The process of updating dependencies starts by collecting a list of all 
repositories and determining the root of the graph. That's typically 
qtbase. From there one, updates to all repositories are posted that only 
depend on the root. All other repositories remain in a "todo" list. The 
root is remembered in a "done" list and all repositories that we are 
currently trying to bring up-to-date are in a "pending" list. Once this 
process is started, the program saves its state in a ```.json``` file 
and terminates.

The next time the Qt Module Updater is started, it resumes the state and 
begins checking the state of all pending updates. If an update 
succeeded, then the corresponding repository is added to the "done" list 
and we can prepare updates for repositories that have now their 
dependencies satisfied by picking them from the "todo" list. If the 
update failed, the repository is dropped from the batch of updates and 
all other repositories that directly or indirectly depend on the failed 
one are also removed. After every such iteration of processing pending 
updates and pushing new ones to Gerrit, the process terminates and saves 
its state.

When the todo list is empty and there are no more pending updates, the 
batch update is complete. If during that update there were no failures, 
the Qt Module Updater will also push a change to qt5.git with an update 
to all submodule sha1s of the new consistent set of modules.


Since this is needed to facilitate private API changes in Qt 6, the 
objective is to take this into production in either the wip/qt6 branch 
or dev in the coming days. If you see these files appearing, then you 
know why :-)

There is no immediate plan to take this into use for Qt 5 development. 
That's not a "never ever!" statement though, more an expression of 
"let's try this in Qt 6 first".



Simon

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

Re: [Development] Extending moc to generate easily accessible metatype descriptions

[Ulf Hermann]

> Well, unfortunetely, even moc doesn't know about all the metatypes.
> Many types don't need registration, and moc is not always aware of the 
> Q_DECLARE_METATYPE declaration (but it actually should still work for 
> most types)
> 
> There are also all the custom QMetaObject (thinking of stuff like DBus, 
> ActiveQt or other language bindings, or the ones created by Verdigris)

We can add something like the QML_FOREIGN declarations introduced in 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/248475 on the 
metaobject level. A dummy struct with some macros that would tell moc 
"there is a metaobject you cannot see and it has these properties".

Or we can live with the fact that we don't have all metatypes in the 
json files. If you want your types to appear there you have to follow 
some conventions.

> But this post-processing of the .json files is not necessarily something 
> for moc. It could be in a separate tool.  (But I realize that you can 
> just add the option to the moc binary to avoid creating another small 
> tool just for that.)

Yes, I can move it into an extra tool if necessary, but as that is still 
part of some kind of "meta object compilation" and it's not a lot of 
code, I would actually prefer to keep it inside moc.

> The question is also how does it fits in the build system? How do you 
> know which .json to collect and at what stage do you do that?

moc already creates a number of files called moc_.cpp. The build 
system has to deal with that already. Now it also creates files 
moc_.cpp.json. The handling of those should be equivalent on a 
build system level. The way it's done in qmake right now is that we 
create a fake rule for the json file that depends on the moc rule but 
doesn't do anything by itself. It just declares that it "creates" the 
json file. I'm sure you can phrase something similar in other build systems.

> Is this going to add some burden for people using custom build systems?

You can either ignore it and live without automatic generation of 
qmltypes files (and automatic registration of QML types, see 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/271876 for a 
rough sketch), or you can adapt your build system. So, either you keep 
the burden you already have, or you replace it with a different and 
hopefully smaller one. The trade-off depends on the properties of your 
build system.

> And how mandatory will it be?  Is it ok if this does not work?

If it doesn't work you have to write your qmltypes files manually or use 
qmlplugindump (although I would like to deprecate the latter, eventually).

> Also I would need to find a solution for Verdigris.  (Was thinking about 
> generating the json at compile time in a constexpr string put in a 
> specific section of the binary,  but how does it ends up in a qmltypes 
> then?)

That sounds like a good idea. We can probably write a qmltyperegistrar 
variant that pulls its input from some ELF section instead of a separate 
json file.

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

Re: [Development] Extending moc to generate easily accessible metatype descriptions

[Olivier Goffart]

On 16.09.19 12:32, Ulf Hermann wrote:
> [...]

The place where all the metatypes are known at compile time is inside
moc. 


Well, unfortunetely, even moc doesn't know about all the metatypes.
Many types don't need registration, and moc is not always aware of the 
Q_DECLARE_METATYPE declaration (but it actually should still work for most types)


There are also all the custom QMetaObject (thinking of stuff like DBus, 
ActiveQt or other language bindings, or the ones created by Verdigris)



Therefore I propose an additional parameter "--json" for moc that would
generate just such files, in JSON format, to be processed by further
tools. 


Sounds like a good idea.


In addition, moc should also gain the ability to collect multiple
such per-C++-file JSON files into one per-module JSON file. The latter
is a pure JSON transformation and doesn't require any insight about the
actual types.


But this post-processing of the .json files is not necessarily something for 
moc. It could be in a separate tool.  (But I realize that you can just add the 
option to the moc binary to avoid creating another small tool just for that.)



The proposed change to moc is
https://codereview.qt-project.org/c/qt/qtbase/+/248470 and a proposed
qmltyperegistrar which would use the metatype information to generate
plugins.qmltypes files at compile time can be seen at
https://codereview.qt-project.org/c/qt/qtdeclarative/+/248471 (mind the
dependency chain).


The question is also how does it fits in the build system? How do you know 
which .json to collect and at what stage do you do that?

Is this going to add some burden for people using custom build systems?

And how mandatory will it be?  Is it ok if this does not work?

Also I would need to find a solution for Verdigris.  (Was thinking about 
generating the json at compile time in a constexpr string put in a specific 
section of the binary,  but how does it ends up in a qmltypes then?)


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

Re: [Development] 5.14 API change reviews

[Edward Welbourne]

Jani Heikkinen (16 September 2019 12:32)
> It seems this is still badly ongoing. Even Alpha isn't out yet we
> should be able to finalize these as soon as possible. So please do
> reviews now & get reviews approved as soon as possible.

It seems I managed to start the initial review before the final
downmerge completed, so there are some changes to APIs that landed with
that.  I've now updated all the reviews to current 5.14, picking up any
API change review fixes that have been done in the mean time.

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

Re: [Development] Updated high-DPI support for Qt 5.14

[Paul Tvete]

On Monday, 16 September 2019 15:21:38 CEST Florian Bruhin wrote:
> I guess with "in 2016" you mean the change this email is talking about:
> https://codereview.qt-project.org/c/qt/qtbase/+/176381
> 
> That commit was merged for Qt 5.14 a couple of weeks ago, not in 2016:

Oops! Yes, that's the change. Sorry for causing confusion.

- Paul



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

Re: [Development] Updated high-DPI support for Qt 5.14

[Florian Bruhin]

Hey,

On Mon, Sep 16, 2019 at 07:43:29AM +, Paul Tvete wrote:
> On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote:
> 
> > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?
> 
> QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended 
> replacement is QT_ENABLE_HIGHDPI_SCALING. 

Huh? How come the documentation (even for 5.14) still mentions that and doesn't
mention QT_ENABLE_HIGHDPI_SCALING at all then?

https://doc-snapshots.qt.io/qt5-5.14/highdpi.html

I guess with "in 2016" you mean the change this email is talking about:
https://codereview.qt-project.org/c/qt/qtbase/+/176381

That commit was merged for Qt 5.14 a couple of weeks ago, not in 2016:

  commit 1de8b01d2b6db8a4fe2eddd0c595d9e680964db5
  Author: Morten Johan Sørvig 
  AuthorDate: Thu Nov 10 14:17:53 2016 +0100
  Commit: Morten Johan Sørvig 
  CommitDate: Fri Aug 23 03:41:14 2019 +0200

Looks like that change didn't add a changelog entry and didn't bother to update
the documentation at all...

Florian

-- 
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

> On 13 Sep 2019, at 17:50, Thiago Macieira  wrote:
> 
> On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote:
>>> What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?
>> 
>> I wonder too. I assume they've not been removed? The latter is the one that
>> KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command
>> line for testing. What would be the new way to set per-screen scale factors?
> 
> I'm going to make a different request: unless the meaning has changed, keep 
> the same names. We already went through a round of having people migrate 
> their 
> variables from the old names to those I listed. Let's not do it again without 
> strong reason.


Yep, nobody likes API churn. They are not going away, but do not fit well with
the API structure or the way the implementation works any more, so I did not
emphasize them in my email.

Long term I think the migration path should be off of Qt-specific high-dpi
config options, in favor of windowing system API. Which in this case probably
means using Wayland instead of X11.

Could KDE possibly set per-screen DPI instead of a scale factor? Applications
can now use the QGuiApplication::setHighDpiScaleFactorRoundingPolicy() API to
decide wether or not they accept fractional devicePixelRatios (in the cases
where Qt implements the scaling), which does not match well with having a 
directly
set scale factor.

- Morten



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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Lars Knoll]

On 16 Sep 2019, at 13:26, Albert Astals Cid via Development 
mailto:development@qt-project.org>> wrote:

El dilluns, 16 de setembre de 2019, a les 13:22:22 CEST, Frederik Gladhorn va
escriure:
On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
Albert Astals Cid (16 September 2019 11:33) wrote:
If i do

 git clone ssh://myu...@codereview.qt-project.org/qt/qtbase

I get branch 5.12

Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
sense to default to branch 5.13?

We have a history of setting a release branch (stable, I think; perhaps
LTS) as the default branch in our repositories.  This means that anyone
who mirrors our repositories gets that as their default branch (unless /
until they update it).  I don't see this as a good choice: getting dev
on the branches that have it would make more sense.

IIUC, the rationale for the present practice is that we want to make it
easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
having fixes sent to us on dev a bit more often (and other changes, that
*do* belong on dev, being sent first to another branch would surely
happen less often); reviewers can surely help the contributor get it
onto the right branch, if there's a good reason why dev isn't good
enough.

... now, where have I met this discussion recently ?
I'm quite sure I have, but can't remember where ...

I also had a chat about this recently and the Gerrit admins in general don't
really fell like constantly changing the default branch, so I'd be much in
favor of just moving all default branches to dev.

Same here, i think dev makes sense too, but didn't want to propose something
so radical myself ^_^

+1 for having it pointing to dev and never changing it again. It’s also more in 
line with most other git repos out there :)

Cheers,
Lars


Cheers,
 Albert


In my opinion we should mostly care about the dev branch, since that's where
all future development needs to happen. Moving changes back into older
releases can of course be important, but that's not what most people should
have to worry about.

Cheers,
Frederik

Eddy.

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


--
Albert Astals Cid | 
albert.astals@kdab.com | Senior Software 
Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Albert Astals Cid via Development]

El dilluns, 16 de setembre de 2019, a les 13:22:22 CEST, Frederik Gladhorn va 
escriure:
> On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
> > Albert Astals Cid (16 September 2019 11:33) wrote:
> > > If i do
> > > 
> > >   git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
> > > 
> > > I get branch 5.12
> > > 
> > > Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> > > sense to default to branch 5.13?
> > 
> > We have a history of setting a release branch (stable, I think; perhaps
> > LTS) as the default branch in our repositories.  This means that anyone
> > who mirrors our repositories gets that as their default branch (unless /
> > until they update it).  I don't see this as a good choice: getting dev
> > on the branches that have it would make more sense.
> > 
> > IIUC, the rationale for the present practice is that we want to make it
> > easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
> > having fixes sent to us on dev a bit more often (and other changes, that
> > *do* belong on dev, being sent first to another branch would surely
> > happen less often); reviewers can surely help the contributor get it
> > onto the right branch, if there's a good reason why dev isn't good
> > enough.
> > 
> > ... now, where have I met this discussion recently ?
> > I'm quite sure I have, but can't remember where ...
> 
> I also had a chat about this recently and the Gerrit admins in general don't
> really fell like constantly changing the default branch, so I'd be much in
> favor of just moving all default branches to dev.

Same here, i think dev makes sense too, but didn't want to propose something 
so radical myself ^_^

Cheers,
  Albert

> 
> In my opinion we should mostly care about the dev branch, since that's where
> all future development needs to happen. Moving changes back into older
> releases can of course be important, but that's not what most people should
> have to worry about.
> 
> Cheers,
> Frederik
> 
> > Eddy.
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Frederik Gladhorn]

On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
> Albert Astals Cid (16 September 2019 11:33) wrote:
> > If i do
> > 
> >   git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
> > 
> > I get branch 5.12
> > 
> > Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> > sense to default to branch 5.13?
> 
> We have a history of setting a release branch (stable, I think; perhaps
> LTS) as the default branch in our repositories.  This means that anyone
> who mirrors our repositories gets that as their default branch (unless /
> until they update it).  I don't see this as a good choice: getting dev
> on the branches that have it would make more sense.
> 
> IIUC, the rationale for the present practice is that we want to make it
> easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
> having fixes sent to us on dev a bit more often (and other changes, that
> *do* belong on dev, being sent first to another branch would surely
> happen less often); reviewers can surely help the contributor get it
> onto the right branch, if there's a good reason why dev isn't good
> enough.
> 
> ... now, where have I met this discussion recently ?
> I'm quite sure I have, but can't remember where ...

I also had a chat about this recently and the Gerrit admins in general don't 
really fell like constantly changing the default branch, so I'd be much in 
favor of just moving all default branches to dev.

In my opinion we should mostly care about the dev branch, since that's where 
all future development needs to happen. Moving changes back into older 
releases can of course be important, but that's not what most people should 
have to worry about.

Cheers,
Frederik


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




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

[Development] Extending moc to generate easily accessible metatype descriptions

[Ulf Hermann]

Hi,

in an effort to enable better tooling for QML, it would be of great 
value to have easily accessible per-module descriptions of our meta 
types available. This would allow us to analyze the availability of 
properties, signals, enums, invokable methods, and slots statically at 
compile time. In turn, we could use this information to write a better 
QML linter, a QML language server, and an improved QML code model for Qt 
Creator. The information would also be helpful for a QML compiler that 
compiles QML to C++.

We need not only metatype information from types introduces in modules 
that define QML types, but also metatype information for types those QML 
types derive from because all the properties etc are inherited. In 
addition, some modules and plugins register "foreign" types under their 
own QML type URI, such as the state machine plugin registering 
QHistoryState (for example). Therefore a proper solution to the problem 
needs to be applied at least to QtCore and QtGui, in addition to the 
modules in qtdeclarative.



The way type information is passed to any tools right now is via files 
called "plugins.qmltypes" places alongside QML plugins in Qt's plugin 
directories. These are generated by running the "qmlplugindump" tool on 
the plugins in question. qmlplugindump loads the plugins and examines 
the run time QMetaObject instances to retrieve the required information. 
There are some downsides to this approach:

1. It does not work for cross-compiled Qt builds. Obviously we cannot 
load plugins for a different architecture on the host system at build time.

2. Loading the plugins executes unrelated code in the plugins. For our 
own plugins we can keep the side effects under control. However, we want 
to be able to generate type descriptions also for custom types 
introduced by application developers, and we don't know what happens if 
we load their plugins with qmlplugindump.

3. It only works for plugins. You can call qmlRegisterType() directly in 
main() and qmlplugindump will never see that. Having to refactor your 
application into plugins just to have the type descriptions available is 
a burden.

4. It does not work for static builds. Obviously qmlplugindump cannot 
load static plugins.



The place where all the metatypes are known at compile time is inside 
moc. moc analyzes the headers for specific macros and transforms those 
into C++ representations. Those C++ representations are geared for 
run-time performance and rather hard to parse later on. However, it 
would be easy for moc to generate additional files with the same content 
in more easily accessible form.

Therefore I propose an additional parameter "--json" for moc that would 
generate just such files, in JSON format, to be processed by further 
tools. In addition, moc should also gain the ability to collect multiple 
such per-C++-file JSON files into one per-module JSON file. The latter 
is a pure JSON transformation and doesn't require any insight about the 
actual types.

The proposed change to moc is 
https://codereview.qt-project.org/c/qt/qtbase/+/248470 and a proposed 
qmltyperegistrar which would use the metatype information to generate 
plugins.qmltypes files at compile time can be seen at 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/248471 (mind the 
dependency chain).

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

Re: [Development] 5.14 API change reviews

[Jani Heikkinen]

Hi all,

It seems this is still badly ongoing. Even Alpha isn't out yet we should be 
able to finalize these as soon as possible. So please do reviews now & get 
reviews approved as soon as possible. 

br,
Jani


From: Development  on behalf of Edward 
Welbourne 
Sent: Monday, August 26, 2019 7:14 PM
To: development@qt-project.org
Subject: [Development] 5.14 API change reviews

Hi all,

As some have clearly noticed unprompted, I've now posted the first
drafts of the 5.14 API change reviews [0], in accordance with QUIP 10
[1].  Please file bugs in Jira for any changes you object to and link
those bugs to QTBUG-77839 [2], blocking it.  Please tag any changes you
make to fix issues noticed in review, either with Fixes: for such a bug
report or with a Task-number: QTBUG-77839 footer.

As ever, remember that these reviews filter out lots of trivial changes,
so check the actual 5.14 (and, where relevant, 5.13.1) sources if in
doubt about what's really there.  The boring changes filtered out of
qtbase totalled more than twice the residue presented for review.

[0] https://codereview.qt-project.org/q/topic:%2522api-change%2522+status:open
[1] https://quips-qt-io.herokuapp.com/quip-0010-API-review.html
[2] https://bugreports.qt.io/browse/QTBUG-77839

Feature freeze has happened, so please make no changes to 5.14's public
APIs other than fixes in response to these reviews.

If you know a module has had material changes requiring an update to the
review, please either read the commit message (it says how to update it)
or drop me a line,

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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Edward Welbourne]

Albert Astals Cid (16 September 2019 11:33) wrote:
> If i do
>   git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
>
> I get branch 5.12
>
> Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more sense to
> default to branch 5.13?

We have a history of setting a release branch (stable, I think; perhaps
LTS) as the default branch in our repositories.  This means that anyone
who mirrors our repositories gets that as their default branch (unless /
until they update it).  I don't see this as a good choice: getting dev
on the branches that have it would make more sense.

IIUC, the rationale for the present practice is that we want to make it
easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
having fixes sent to us on dev a bit more often (and other changes, that
*do* belong on dev, being sent first to another branch would surely
happen less often); reviewers can surely help the contributor get it
onto the right branch, if there's a good reason why dev isn't good
enough.

... now, where have I met this discussion recently ?
I'm quite sure I have, but can't remember where ...

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

[Development] Updating/changing "default" branch for qtbase repository

[Albert Astals Cid via Development]

If i do
  git clone ssh://myu...@codereview.qt-project.org/qt/qtbase

I get branch 5.12

Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more sense to 
default to branch 5.13? 

Cheers,
  Albert

P.S: I guess it's the same for the rest of the repos but I have not tried

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Updated high-DPI support for Qt 5.14

[Elvis Stansvik]

Den mån 16 sep. 2019 kl 09:44 skrev Paul Tvete :
>
> On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote:
>
> > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?
>
> QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended
> replacement is QT_ENABLE_HIGHDPI_SCALING.
>
> It looks like QT_SCREEN_SCALE_FACTORS was briefly broken, but I see there was
> a fix by David Faure that was merged last week: 
> https://codereview.qt-project.org/c/qt/qtbase/+/273182

Phew. Thanks!

Elvis

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

Re: [Development] Updated high-DPI support for Qt 5.14

[Paul Tvete]

On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote:

> What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?

QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended 
replacement is QT_ENABLE_HIGHDPI_SCALING. 

It looks like QT_SCREEN_SCALE_FACTORS was briefly broken, but I see there was 
a fix by David Faure that was merged last week: 
https://codereview.qt-project.org/c/qt/qtbase/+/273182

- Paul


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