Re: [Development] Revisiting high-DPI configuration options

[Randall O'Reilly]

I migrated to Qt from InterViews: 
http://www.ivtools.org/ivtools/doc/refman3.1/index.html  which used 
floating-point units that could be arbitrarily rescaled, but default to points, 
like many other standards (e.g., SVG, Postscript).  I always found it strange 
that Qt used integer pixel coords.  Seemed like a very time-limited solution 
even back in the day in terms of rendering to a printer vs. a screen, and 
anticipated increases in screen resolution which are now (finally) happening.

Seems like it might be time to do a global replace int -> float and just fix 
the “standard” meaning of the coordinate system in terms of points, given that 
it is probably pretty close to the pixel density of the “classic” displays that 
Qt was developed on, and it is used in these other standards, and existing apps 
should probably perform reasonably well with such a definition.  But internally 
support an arbitrary floating-point scaling factor so people can use whatever 
coordinate system they want going forward.  It just seems like any other 
solution is going to end up being a dead-end for future displays, and rather 
ugly in any case (as the current solution is demonstrating).

Also, another nice thing that InterViews got right was a multi-pass layout 
algorithm that “just worked” to best fit elements in available display spaces — 
including the option of using a LaTeX-inspired layout algorithm.  You specify 
“natural” sizes and flexibility factors, and the algorithm optimizes from 
there.  This works well when moving away from having to do precise layouts in 
pixel coordinates.. 

- Randy

> On Jul 26, 2016, at 8:56 PM, Nikita Krupenko  wrote:
> 
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira :
>> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
>> escreveu:
>>> In Material Design guidelines [1] all font sizes are in scaleable
>>> pixels (sp). So this size could be multiplied by some factor and all
>>> fonts should scale equally.
>> 
>> Maybe we should instead use a size calculated in physical units, like 1/72th
>> of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

On quarta-feira, 27 de julho de 2016 05:56:52 PDT Nikita Krupenko wrote:
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira :
> > Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> > 
> > escreveu:
> >> In Material Design guidelines [1] all font sizes are in scaleable
> >> pixels (sp). So this size could be multiplied by some factor and all
> >> fonts should scale equally.
> > 
> > Maybe we should instead use a size calculated in physical units, like
> > 1/72th of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.

My point is that we already have such a unit. Instead of inventing a new one 
that didn't exist before, then use it in a context where a unit was already 
proper, why not use the proper unit for everything? Measure images in points 
too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Revisiting high-DPI configuration options

[Nikita Krupenko]

2016-07-27 4:02 GMT+03:00 Thiago Macieira :
> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> escreveu:
>> In Material Design guidelines [1] all font sizes are in scaleable
>> pixels (sp). So this size could be multiplied by some factor and all
>> fonts should scale equally.
>
> Maybe we should instead use a size calculated in physical units, like 1/72th
> of an inch. Oh, we have such a unit: points.

The idea of scaleable pixels is somewhat different: user can select
big/small fonts in the OS/application settings and font sizes would be
multiplied by some factor, for example 1.5.

BTW, why use font size in points? As other elements, like widgets,
images, etc has size in pixels, it's better to use pixels for fonts
too. Auto HiDPI scaling in Qt works for font sizes in pixels.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Thiago Macieira]

Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko 
escreveu:
> In Material Design guidelines [1] all font sizes are in scaleable
> pixels (sp). So this size could be multiplied by some factor and all
> fonts should scale equally.

Maybe we should instead use a size calculated in physical units, like 1/72th 
of an inch. Oh, we have such a unit: points.

> I think, it's worth to add the support of the font scale factor to the
> Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
> plugin could try to get font scale factor from the OS settings and use
> it by default.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Revisiting high-DPI configuration options

[Nikita Krupenko]

2016-07-19 15:58 GMT+03:00 Shawn Rutledge :
>> App should remember of couse this setting to restore it back at restart
>
> How should Qt encourage this?  So far we have QSettings, but you need to 
> define your own setting.  And we have not made it easy to scale all fonts 
> simultaneously, interactively.  Bindings are too cumbersome and expensive to 
> be the universal solution.  To avoid setting the font on every individual 
> Text item in a QtQuick app, for example, you can use 
> QGuiApplication::setFont().  But that’s just for the default.  Maybe there 
> should be an event of some sort when you do that at runtime, which every Text 
> will react to, and which will then trigger the necessary layout changes.  But 
> that would only take care of Text which uses the default font, so we need 
> that unit support in QML (which has been discussed for years but not done 
> yet) to be able to have a unit which represents the default font size, so 
> that larger text could have a size 1.2x as big as the default instead of an 
> actual point size.  Or maybe the event should be sent when you do 
> QHighDpiScaling::setScreenFactor(), but that’s private API so far, and it’s 
> still not clear to me which of those Qt high dpi-things are intended to 
> affect only or mainly font sizes, and which of them demand everything to be 
> scaled even if it will cause crappy results (scaling up pixmaps or 
> pre-rendered widgets by non-integral ratios).  The prototype zoom-slider is 
> in qtbase/tests/manual/highdpi, but you can see what goes wrong with that.  
> We need a similar test for QtQuick to see what goes wrong with dynamic 
> scaling there.

In Material Design guidelines [1] all font sizes are in scaleable
pixels (sp). So this size could be multiplied by some factor and all
fonts should scale equally.

I think, it's worth to add the support of the font scale factor to the
Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
plugin could try to get font scale factor from the OS settings and use
it by default.

[1] 
https://material.google.com/layout/units-measurements.html#units-measurements-scaleable-pixels-sp-
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Thiago Macieira]

Em terça-feira, 26 de julho de 2016, às 23:24:21 PDT, Giuseppe D'Angelo 
escreveu:
> On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
> 
>  wrote:
> > Let's pay attention of what crashes and where. But we'll need to reproduce
> > this in order to debug it.
> 
> It just happened again:
> 
> http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db9
> 8fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndR
> elease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

This is a crash on Linux, with "core dumped", albeit in a unit test, not moc:

http://testresults.qt.io/logs/qt/qtbase/
47fa5811ef59b06d8d512b565db856c5c3bc5478/
LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCqtci-linux-Ubuntu-14.04-
x86_64-be23deNoWidgets_ForceDebugInfo/
85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1469528656/testlog.txt.gz

Any chance we can get the backtrace of that crash?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Programs crashing left and right in the CI

[Henry Skoglund]

Hi, most likely I've had too much coffee, but has anyone checked if 
these intermittent crashes are due to outside DDOS/some trying to 
introduce a race condition and injecting new code into Qt's codebase?


Rgrds Henry


On 2016-07-26 23:24, Giuseppe D'Angelo wrote:

On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
 wrote:


Let's pay attention of what crashes and where. But we'll need to reproduce
this in order to debug it.


It just happened again:

http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz




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

Re: [Development] Programs crashing left and right in the CI

[Giuseppe D'Angelo]

On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
 wrote:
>
> Let's pay attention of what crashes and where. But we'll need to reproduce
> this in order to debug it.

It just happened again:

http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[Thiago Macieira]

Em terça-feira, 26 de julho de 2016, às 20:08:30 PDT, BogDan Vatra escreveu:
> scoped enums are declared differenty : enum *class* MyEnum :) 
> Even more, scoped enums in C++ must me used with fully qualified name
> *MyEnum a  = MyEnum.Val1* not *MyEnum a = Val1*, so a scoped enum is not
> exacly an enum
> :)

The point is that given "MyEnum", you can't tell whether it's scoped or not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8

[Andrea Bernabei]

2016-07-26 18:42 GMT+01:00 Alexander Nassian :

> Hi Andrea,
>
> Good proposal! But one little hint: The current behavior is not that
> confusing as you describe. On iOS and OS X for example the current behavior
> is normal.
>
>
Thanks Alexander!

And thanks for your input, that's exactly the kind of info I'm looking for
:) Let's hear some more opinions :)


>
> Beste Grüße / Best regards,
> Alexander Nassian
> http://www.bitshift-dynamics.de
>
> Am 26.07.2016 um 16:12 schrieb Andrea Bernabei :
>
> Hello everyone,
>
> I'd like to propose changing the default value of QML Flickable's
> flickableDirection in Qt 5.8.
>
> The current default value is Flickable.AutoFlickDirection
> The description is: it "allows flicking vertically if the *contentHeight*
> is not equal to the *height* of the Flickable. Allows flicking
> horizontally if the *contentWidth* is not equal to the *width* of the
> Flickable."
>
> It seems to me like the current default was chosen to make it so that the
> surface is always draggable except for things like vertical ListViews
> (where contentWidth==width, or the same for height in the case of
> horizontal lists).
>
> I propose we should change the default value to
> Flickable.AutoFlickIfNeeded (added by Shawn, Flickable's maintainer, in 5.7
> https://codereview.qt-project.org/#/c/150388/ ).
>
> I'll try using bullet points to avoid a wall of text.
>
> Proposal:
> Change default Flickable's flickableDirection to AutoFlickIfNeeded in
> Qt5.8, and only available when importing QtQuick >= 2.8
>
> Why:
> The current behaviour is a bit confusing. If we only take the horizontal
> dimension into account:
> - content narrower than Flickable --> content IS draggable (why?)
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable  --> content IS draggable
>
> While with the proposed change:
> - content narrower than Flickable --> content NOT draggable
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable  --> content IS draggable
>
> I believe the new behaviour is better, the content is only draggable when
> dragging "makes sense", i.e. when dragging would reveal additional content
> that would otherwise be hidden.
>
> What do you guys think?
>
> Cheers,
> Andrea (faenil)
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Revisiting high-DPI configuration options

[Stephen Chu]

On 7/20/16, 5:12 AM, "Development on behalf of Edward Welbourne" 
 wrote:

>
>Then again, our SVG support is embarrassingly poor,

Especially when it doesn’t support clip path. Which I imagine will be vital for 
icon designs.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[Olivier Goffart]

On Dienstag, 26. Juli 2016 08:33:31 CEST Thiago Macieira wrote:
> Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> > Hi,
> > 
> > Is there any reason why C++11 scoped enums are not scoped in QML ?
> 
> There's no trait to tell apart a scoped enum from an unscoped one. An enum
> is en enum, that's all.
> 
> If you want a given enum to be scoped in QML, it should be a QML engine
> feature and should be available to any C++ enum, whether it's scoped or not.
> > If I have something like the following code in C++
> 
> [cut]
> 
> >  Q_ENUM(MyEnum)
> 
> This is all the engine sees. It's an enum.


It's trivial to let QMetaEnum know about scoped enum:

https://codereview.qt-project.org/166136/


That said, it would be a behavior change not to allow anymore the previous 
(unscoped) syntax to work with QML

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org

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

Re: [Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8

[Alexander Nassian]

Hi Andrea,

Good proposal! But one little hint: The current behavior is not that confusing 
as you describe. On iOS and OS X for example the current behavior is normal.


Beste Grüße / Best regards,
Alexander Nassian
http://www.bitshift-dynamics.de

> Am 26.07.2016 um 16:12 schrieb Andrea Bernabei :
> 
> Hello everyone,
> 
> I'd like to propose changing the default value of QML Flickable's 
> flickableDirection in Qt 5.8.
> 
> The current default value is Flickable.AutoFlickDirection
> The description is: it "allows flicking vertically if the contentHeight is 
> not equal to the height of the Flickable. Allows flicking horizontally if the 
> contentWidth is not equal to the width of the Flickable."
> 
> It seems to me like the current default was chosen to make it so that the 
> surface is always draggable except for things like vertical ListViews (where 
> contentWidth==width, or the same for height in the case of horizontal lists).
> 
> I propose we should change the default value to Flickable.AutoFlickIfNeeded 
> (added by Shawn, Flickable's maintainer, in 5.7 
> https://codereview.qt-project.org/#/c/150388/ ).
> 
> I'll try using bullet points to avoid a wall of text.
> 
> Proposal:
> Change default Flickable's flickableDirection to AutoFlickIfNeeded in Qt5.8, 
> and only available when importing QtQuick >= 2.8
> 
> Why:
> The current behaviour is a bit confusing. If we only take the horizontal 
> dimension into account:
> - content narrower than Flickable --> content IS draggable (why?)
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable  --> content IS draggable
> 
> While with the proposed change:
> - content narrower than Flickable --> content NOT draggable
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable  --> content IS draggable
> 
> I believe the new behaviour is better, the content is only draggable when 
> dragging "makes sense", i.e. when dragging would reveal additional content 
> that would otherwise be hidden. 
> 
> What do you guys think? 
> 
> Cheers,
> Andrea (faenil)
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[BogDan Vatra]

On marți, 26 iulie 2016 08:33:31 EEST Thiago Macieira wrote:
> Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> > Hi,
> > 
> > Is there any reason why C++11 scoped enums are not scoped in QML ?
> 
> There's no trait to tell apart a scoped enum from an unscoped one. An enum
> is en enum, that's all.
> 

scoped enums are declared differenty : enum *class* MyEnum :) 
Even more, scoped enums in C++ must me used with fully qualified name *MyEnum a 
= MyEnum.Val1* not *MyEnum a = Val1*, so a scoped enum is not exacly an enum 
:)

> If you want a given enum to be scoped in QML, it should be a QML engine
> feature and should be available to any C++ enum, whether it's scoped or not.

> > If I have something like the following code in C++
> 
> [cut]
> 
> >  Q_ENUM(MyEnum)
> 
> This is all the engine sees. It's an enum.

Well, that's all the *moc* sees and I'm pretty sure it knows also the *class* 
keyword, otherwise it can't skip it properly...

Cheers,
BogDan.

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[Thiago Macieira]

Em terça-feira, 26 de julho de 2016, às 17:41:01 PDT, Giuseppe D'Angelo 
escreveu:
> On Tue, Jul 26, 2016 at 5:33 PM, Thiago Macieira
> 
>  wrote:
> > This is all the engine sees. It's an enum.
> 
> But moc might help in this, extracting the relevant information
> alongside the enum's metadata.
> 
> Also if std::is_enum::value is true and std::is_convertible typename std::underlying_type::type>::value is false, then the enum
> is scoped. (Surely in C++something this might break if user-provided
> conversions get allowed, but for now it's enough).

I'd still say this should be an opt-in feature for the QML engine that should 
not be required to depend on the type of C++ enum used to back it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

[Giuseppe D'Angelo]

On Tue, Jul 26, 2016 at 5:33 PM, Thiago Macieira
 wrote:
> This is all the engine sees. It's an enum.

But moc might help in this, extracting the relevant information
alongside the enum's metadata.

Also if std::is_enum::value is true and std::is_convertible::value is false, then the enum
is scoped. (Surely in C++something this might break if user-provided
conversions get allowed, but for now it's enough).

My 2 c,

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

Re: [Development] [QML]: Why can't create Q_GADGETs from QML ?

[Simon Hausmann]

Hi,


No objection per-se, but we'd have to figure out some details. For example 
declarative instantiation is

not an object, as the ownership rules do not comply with QObject. That would 
leave us with a JavaScript

constructor function, replacing Qt.point(...) for example. But then we'd have 
to comply with the namespace

rules, so we'd have


qmlRegisterGadget("MyModule", "ThatName", 1, 0);


and then


import MyModule 1.0


and in expressions we'd have


var g = new ThatName();


and the same for a namespaced import:


import MyModule 1.0 as Foo


var g = new Foo.ThatName();


It's a bit of work to do, but I don't see a problem in principle.


Simon


From: Development  on 
behalf of BogDan Vatra 
Sent: Tuesday, July 26, 2016 5:28:35 PM
To: development@qt-project.org
Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?

Hi,

Is there any reason why I can only use Q_GADGETs objects in QML, but not to
create them?

It will be nice if we can register Q_GADGETs  as qml creatable types too.

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

[Thiago Macieira]

Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> Hi,
> 
> Is there any reason why C++11 scoped enums are not scoped in QML ?

There's no trait to tell apart a scoped enum from an unscoped one. An enum is 
en enum, that's all.

If you want a given enum to be scoped in QML, it should be a QML engine 
feature and should be available to any C++ enum, whether it's scoped or not.

> If I have something like the following code in C++
> 
[cut]
>  Q_ENUM(MyEnum)

This is all the engine sees. It's an enum.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Development] [QML]: Why can't create Q_GADGETs from QML ?

[BogDan Vatra]

Hi,

Is there any reason why I can only use Q_GADGETs objects in QML, but not to 
create them?

It will be nice if we can register Q_GADGETs  as qml creatable types too.

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

Re: [Development] Programs crashing left and right in the CI

[Thiago Macieira]

Em terça-feira, 26 de julho de 2016, às 11:22:04 PDT, Jędrzej Nowacki 
escreveu:
> > # 11: DllUnregisterServer() - 0x7FF8DB7097B0
> > # 12: DllUnregisterServer() - 0x7FF8DB7097B0
> > # 13: DllUnregisterServer() - 0x7FF8DB7097B0
> > # 14: DllGetActivationFactory() - 0x7FF8DC9D1860
> > # 15: DllGetActivationFactory() - 0x7FF8DC9D1860
> > # 16: DllGetActivationFactory() - 0x7FF8DC9D1860
> > # 17: DllGetActivationFactory() - 0x7FF8DC9D1860
> > # 18: DllGetActivationFactory() - 0x7FF8DC9D1860
> > # 19: SwMemFree() - 0x7FF8E3E29770
> > # 20: SwMemFree() - 0x7FF8E3E29770
> > # 21: QueryProtectedPolicy() - 0x7FF8E3F45C80
> > # 22: RtlGetActiveActivationContext() - 0x7FF8E6C1C6B0
> > # 23: RtlFreeUnicodeString() - 0x7FF8E6C37100
> > # 24: BaseThreadInitThunk() - 0x7FF8E44B13B0
> > # 25: RtlUserThreadStart() - 0x7FF8E6C15410
> > 
> > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/
> > 1469463068.thrift_bin
> 
> tst_qdir is known to be "ugly" it was backlisted for months and probably re-
> added https://bugreports.qt.io/browse/QTBUG-50835 recently. The bug
> mentioned CI load, we see increased failure rate when the machinery is over
> a bigger load (~140 vms), but there are always more or less the same tests
> failing. So my interpretation is that tests/qt has a race condition that is
> exposed if IO gets slower. CPU and RAM are reserved separately without
> overallocation for every machine, so they do not overlap too much*.

I'm not sure this one is Qt's fault. It seems to crash completely inside 
Windows code. tst_QDir doesn't start any threads, but it's possible that 
Windows itself does to accomplish some task.

It's also possible that the Windows code is simply recovering, and that 
QTest::toString is actually causing the crash. In other words, it's possible 
the code that deals with crashes in QtTest is causing the crash.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Development] [QML]: Register global enums/flags to QML ?

[BogDan Vatra]

Hello,

I'd like to be able to register some "global" enums/flags to QML. I checked a 
little bit how Qt does with all the enums from Qt namespace (qnamespace.h) and 
I end-up in qqmlbuiltinfunctions which does all the "magic" which can't be 
used by normal developers/libs.

Because I think having "global" enums is a very nice feature, I'd like to know 
if other people and QML maintainers agree with me :). 
If yes, then want to propose the followings:
 - add one more Q_OBJECT/Q_GADGET like macro for namespaces (Q_NAMESPACE?), 
which declares the mandatory "extern const QMetaObject staticMetaObject" ( or 
just "extern const QMetaEnum  staticMetaEnum" ? because in principle we'll 
only be able to declare enums/flags ?) into that namespace. Most probably moc 
will need some love to properly handle the new Q_magic_macro. If is too much 
trouble we can use the qnamespace.h hack.

 - add a helper macro/function to register the namespace enums/flags (i.e. 
qmlRegisterNamespace or even better qmlRegisterEnums(const QMetaEnum 
, ). 

I think it depends on QML c++11 scoped enums task, because most probably the 
enums enumerators names will clash.

Cheers,
BogDan.

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

[BogDan Vatra]

Hi,

Thanks for the super quick reply !

I created a bug report for you here https://bugreports.qt.io/browse/
QTBUG-54961 .

Cheers,
BogDan.

On marți, 26 iulie 2016 14:54:46 EEST Simon Hausmann wrote:
> Hi,
> 
> 
> By the time this aspect of the QML engine was implemented, C++11 scoped
> enums did not exist. I think it would be fine
> 
> to add this feature to the JavaScript bindings for C++ classes.
> 
> 
> Simon
> 
> 
> From: Development 
> on behalf of BogDan Vatra  Sent: Tuesday, July 26, 2016
> 4:50:38 PM
> To: development@qt-project.org
> Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML ?
> 
> Hi,
> 
> Is there any reason why C++11 scoped enums are not scoped in QML ?
> If I have something like the following code in C++
> 
> class MyClass : public QObject
> {
>  Q_OBJECT
> public:
>  enum class MyEnum : uint16_t {
>Val1,
>Val2,
>  }
>  Q_ENUM(MyEnum)
> );
> 
> // register the class
> 
> I'd like to use it in QML as:
> console.log(MyClass.MyEnum.Val1)
> not as
> console.log(MyClass.Val1)
> 
> Cheers,
> BogDan.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

[Simon Hausmann]

Hi,


By the time this aspect of the QML engine was implemented, C++11 scoped enums 
did not exist. I think it would be fine

to add this feature to the JavaScript bindings for C++ classes.


Simon


From: Development  on 
behalf of BogDan Vatra 
Sent: Tuesday, July 26, 2016 4:50:38 PM
To: development@qt-project.org
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

Hi,

Is there any reason why C++11 scoped enums are not scoped in QML ?
If I have something like the following code in C++

class MyClass : public QObject
{
 Q_OBJECT
public:
 enum class MyEnum : uint16_t {
   Val1,
   Val2,
 }
 Q_ENUM(MyEnum)
);

// register the class

I'd like to use it in QML as:
console.log(MyClass.MyEnum.Val1)
not as
console.log(MyClass.Val1)

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

[Development] QML: Why C++11 scoped enums are not scoped in QML ?

[BogDan Vatra]

Hi,

Is there any reason why C++11 scoped enums are not scoped in QML ?
If I have something like the following code in C++

class MyClass : public QObject
{
 Q_OBJECT
public:
 enum class MyEnum : uint16_t {
   Val1,
   Val2,
 }
 Q_ENUM(MyEnum)
);

// register the class 

I'd like to use it in QML as:
console.log(MyClass.MyEnum.Val1)
not as 
console.log(MyClass.Val1)

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

Re: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

[Laszlo Agocs]

Sure, you could add something like that on top once the basic multiple QScreen 
support is in place. (for HDMI at least, replicating more or less what 
'tvservice' does. Not sure what (if any) API you have for other type of 
displays, though.)

Laszlo


From: Development  on 
behalf of Dominik Holland 
Sent: Tuesday, July 26, 2016 4:00 PM
To: development@qt-project.org
Subject: Re: [Development] Are there any limitations on implementing the 
changing of the screen for a QWindow on systems using EGLFS?

Hi,

Am 07/26/2016 um 03:33 PM schrieb Laszlo Agocs:
> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
>

Can't we do something similar to QT_QPA_EGLFS_KMS_CONFIG and share the
json file setup here as well ? This would make it way more consistent.

Dominik

>
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
>
>
> Best regards,
>
> Laszlo
>
>
> 
>
> 
> *From:* Development
>  on behalf of
> Verebélyi Viktor 
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development@qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>
>
> I looked at the code for the EGLFS BRCM integration and the screen it
> uses is hard-coded. After trying some test code for Dispmanx it seems
> that it is fairly straight forward to change the screen it uses.
>
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
>
> The reason for why I'm asking is, because I'd like to implement this,
> but I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
>
>
>
> --
> - Viktor Verebelyi
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

--
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com

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

[Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8

[Andrea Bernabei]

Hello everyone,

I'd like to propose changing the default value of QML Flickable's
flickableDirection in Qt 5.8.

The current default value is Flickable.AutoFlickDirection
The description is: it "allows flicking vertically if the *contentHeight*
is not equal to the *height* of the Flickable. Allows flicking horizontally
if the *contentWidth* is not equal to the *width* of the Flickable."

It seems to me like the current default was chosen to make it so that the
surface is always draggable except for things like vertical ListViews
(where contentWidth==width, or the same for height in the case of
horizontal lists).

I propose we should change the default value to Flickable.AutoFlickIfNeeded
(added by Shawn, Flickable's maintainer, in 5.7
https://codereview.qt-project.org/#/c/150388/ ).

I'll try using bullet points to avoid a wall of text.

Proposal:
Change default Flickable's flickableDirection to AutoFlickIfNeeded in
Qt5.8, and only available when importing QtQuick >= 2.8

Why:
The current behaviour is a bit confusing. If we only take the horizontal
dimension into account:
- content narrower than Flickable --> content IS draggable (why?)
- content same size as Flickable --> content NOT draggable
- content wider than Flickable  --> content IS draggable

While with the proposed change:
- content narrower than Flickable --> content NOT draggable
- content same size as Flickable --> content NOT draggable
- content wider than Flickable  --> content IS draggable

I believe the new behaviour is better, the content is only draggable when
dragging "makes sense", i.e. when dragging would reveal additional content
that would otherwise be hidden.

What do you guys think?

Cheers,
Andrea (faenil)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

[Dominik Holland]

Hi,

Am 07/26/2016 um 03:33 PM schrieb Laszlo Agocs:
> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
> 

Can't we do something similar to QT_QPA_EGLFS_KMS_CONFIG and share the
json file setup here as well ? This would make it way more consistent.

Dominik

> 
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
> 
> 
> Best regards,
> 
> Laszlo
> 
> 
> 
> 
> 
> *From:* Development
>  on behalf of
> Verebélyi Viktor 
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development@qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>  
> 
> I looked at the code for the EGLFS BRCM integration and the screen it
> uses is hard-coded. After trying some test code for Dispmanx it seems
> that it is fairly straight forward to change the screen it uses.
> 
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
> 
> The reason for why I'm asking is, because I'd like to implement this,
> but I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
> 
> 
> 
> -- 
> - Viktor Verebelyi
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com

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

Re: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

[Laszlo Agocs]

Lack of contributions and suitable hardware setup. There was a patch for making 
the target screen configurable via an environment variable which never made it 
to integration. We are now reviving it for 5.6 at 
https://codereview.qt-project.org/#/c/166117/


Additional patches for discovering and exposing all available screens as 
separate QScreens are welcome. Not entirely sure about the feasibility, 
especially when it comes to discovering and monitoring the connected outputs, 
but it is definitely worth a try.


Best regards,

Laszlo





From: Development  on 
behalf of Verebélyi Viktor 
Sent: Sunday, July 24, 2016 8:28:15 AM
To: development@qt-project.org
Subject: [Development] Are there any limitations on implementing the changing 
of the screen for a QWindow on systems using EGLFS?


I looked at the code for the EGLFS BRCM integration and the screen it uses is 
hard-coded. After trying some test code for Dispmanx it seems that it is fairly 
straight forward to change the screen it uses.

My question is: Are there any limitations to implementing the functions that 
would allow us to change the screen using QWindows->setScreen()?

The reason for why I'm asking is, because I'd like to implement this, but I'd 
like to know whether if this is not implemented beacuse of some limitations or 
because of lack of intrest/contributors?


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

Re: [Development] Commits: Is it possible to add a missed "default" parameters of methods?

[Denis Shienkov]

Ok, many thanks.

2016-07-26 14:51 GMT+03:00 Marc Mutz :

> On Tuesday 26 July 2016 14:41:25 Denis Shienkov wrote:
> > Hi all, Thiago.
> >
> > Seems, we (I'am) have missed default parameters for the waitFor() methods
> > of QSerialPort:
> >
> > * https://codereview.qt-project.org/#/c/165583/
> >
> > So, my questions:
> >
> > 1. Is it possible just to add of a missed default params and to merge it?
>
> Yes. It's forward- and backwards-BC and backwards-SC.
>
> > 2. If yes, then, what of a branch is makes sense?
>
> dev, since it's not forward-SC (a call omitting the defaulted argument will
> not compile on a version without the default argument).
>
> > BR,
> > Denis
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Commits: Is it possible to add a missed "default" parameters of methods?

[Marc Mutz]

On Tuesday 26 July 2016 14:41:25 Denis Shienkov wrote:
> Hi all, Thiago.
> 
> Seems, we (I'am) have missed default parameters for the waitFor() methods
> of QSerialPort:
> 
> * https://codereview.qt-project.org/#/c/165583/
> 
> So, my questions:
> 
> 1. Is it possible just to add of a missed default params and to merge it?

Yes. It's forward- and backwards-BC and backwards-SC.

> 2. If yes, then, what of a branch is makes sense?

dev, since it's not forward-SC (a call omitting the defaulted argument will 
not compile on a version without the default argument).

> BR,
> Denis

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Commits: Is it possible to add a missed "default" parameters of methods?

[Denis Shienkov]

Hi all, Thiago.

Seems, we (I'am) have missed default parameters for the waitFor() methods
of QSerialPort:

* https://codereview.qt-project.org/#/c/165583/

So, my questions:

1. Is it possible just to add of a missed default params and to merge it?
2. If yes, then, what of a branch is makes sense?

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

Re: [Development] Error in running Qt3D app

[Svenn-Arne Dragly]

Hi,

Are you trying to run the example on Android? If so, try to make a 
simple Qt3D example with a QML Scene3D object, like this: 
https://doc.qt.io/qt-5/qt3d-scene3d-example.html


I have had some trouble with running the other Qt3D examples on Android, 
but I have not seen the same error message as you got. It has often 
helped to run it through a Scene3D object, however. This is of course 
only a long term solution if you are working on a QML project. But, 
testing the example will give you a good indication of whether Qt3D in 
general works on your device or not. If not, there might be some issue 
with getting access to an OpenGL context on your device. Then I would 
try to find a simple OpenGL example for Android in Java just to check.



Cheers,

Svenn-Arne

On 26. juli 2016 05:55, swarit wipra wrote:

Hi,
I am getting following error, when running Qt 3d app.

05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): 
Can't find surface 2
05-19 19:26:06.869   221   628 D AudioFlinger: mixer(0xab962fb0) 
throttle end: throttle time(3)
05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): 
Can't find surface 2
05-19 19:26:47.118   221   628 D audio_hw_primary: out_set_parameters: 
enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) 
adev->mode(0)
05-19 19:26:47.169 17339 17434 E libEGL  : call to OpenGL ES API with 
no current context (logged once per thread)
05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient : 
onPause
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): 
ClimateHmiIF :  NotifyOnPause  ---  0xf7452b34
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): 
UIClimateNotification :  NotifyOnPause  --- 0xf7452b34
05-19 19:26:47.290 17339 17405 W art : Native thread exiting 
without having called DetachCurrentThread (maybe it's going to use a 
pthread_key_create destructor?): 
Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"]


Please guide me to fix it.
Best Regards


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


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

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Monday 25 of July 2016 10:27:30 Thiago Macieira wrote:
> On segunda-feira, 25 de julho de 2016 08:51:36 PDT Thiago Macieira wrote:
> > On segunda-feira, 25 de julho de 2016 14:07:04 PDT Jędrzej Nowacki wrote:
> > > Ugh I haven't seen link.exe crashing, but in case of moc I have
> > > impression
> > > that it is a software problem. I remember that first time I have seen it
> > > I
> > > was  quite surprised, but now it is quite common and it happens mostly
> > > (only) on OSX (Clang miss-compilation?). If it would be memory then I
> > > would
> > > expect to see compiler crashing more often and I have experienced it
> > > maybe
> > > once...
> > > 
> > > Any other idea what can go wrong or what can be checked?
> > 
> > The fact that it is consitently crashing on moc indicates the problem is
> > actually moc or the compiler. You're also right that most of the crashes
> > are on macOS. I can't remember if I've seen it on other OSes. This
> > link.exe crash is a one-off and I haven't seen others.
> > 
> > Let's pay attention of what crashes and where. But we'll need to reproduce
> > this in order to debug it.
> 
> tst_qdir.exe crashed on Windows, on Qt 5.6:
> 
> A crash occurred in C:\Users\qt\work\qt\qtbase\tests\auto\corelib\io\qdir
> \release\tst_qdir.exe.
>  Function time: 2728ms Total time: 2731ms
> 
>  Exception address: 0x7FF8DB7367B4
>  Exception code   : 0xc005
>  PASS   : tst_QDir::entryList(Sorting QDir::Type | QDir::DirsFirst)
>  PASS   : tst_QDir::entryList(Sorting QDir::Size)
>  PASS   : tst_QDir::entryList(Sorting QDir::Size | QDir::Reversed)
>  SKIP   : tst_QDir::entryListTimedSort() /bin/touch not found
>  tst_qdir.cpp(869) : failure location
>  PASS   : tst_QDir::entryListSimple(data2)
>  PASS   : tst_QDir::entryListSimple(simple dir)
>  PASS   : tst_QDir::entryListSimple(simple dir with slash)
>  Nearby symbol: DllUnregisterServer
> 
>  Stack:
>  #  1: QTest::toString() - 0x7FF8DEC08CD0
>  #  2: UnhandledExceptionFilter() - 0x7FF8E4001AD0
>  #  3: TpDbgDumpHeapUsage() - 0x7FF8E6D01BE0
>  #  4: TpDbgDumpHeapUsage() - 0x7FF8E6D01BE0
>  #  5: memset() - 0x7FF8E6C95140
>  #  6: _C_specific_handler() - 0x7FF8E6C82800
>  #  7: wcstok_s() - 0x7FF8E6C8D8C0
>  #  8: _chkstk() - 0x7FF8E6C93E70
>  #  9: RtlRaiseException() - 0x7FF8E6C53920
>  # 10: KiUserExceptionDispatcher() - 0x7FF8E6C93060
>  # 11: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 12: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 13: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 14: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 15: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 16: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 17: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 18: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 19: SwMemFree() - 0x7FF8E3E29770
>  # 20: SwMemFree() - 0x7FF8E3E29770
>  # 21: QueryProtectedPolicy() - 0x7FF8E3F45C80
>  # 22: RtlGetActiveActivationContext() - 0x7FF8E6C1C6B0
>  # 23: RtlFreeUnicodeString() - 0x7FF8E6C37100
>  # 24: BaseThreadInitThunk() - 0x7FF8E44B13B0
>  # 25: RtlUserThreadStart() - 0x7FF8E6C15410
> 
> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/
> 1469463068.thrift_bin

tst_qdir is known to be "ugly" it was backlisted for months and probably re-
added https://bugreports.qt.io/browse/QTBUG-50835 recently. The bug mentioned 
CI load, we see increased failure rate when the machinery is over a bigger 
load (~140 vms), but there are always more or less the same tests failing. So 
my interpretation is that tests/qt has a race condition that is exposed if IO 
gets slower. CPU and RAM are reserved separately without overallocation for 
every machine, so they do not overlap too much*.

So let's concentrate on code / apps that should be rock solid which are 
compilers, linkers and such.

Cheers,
 Jędrek

*CPU reservation is done in Mhz instead of cores, which may cause problems we 
try different tricks to enforce CPU affinity, but they are just "hints" to the 
VSphere scheduler.


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