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

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