Re: [Development] 5.12.5 and wasm-emscripten

2019-09-25 Thread Martin Koller 
Hi Lorn,

On Donnerstag, 26. September 2019 03:32:24 CEST Lorn Potter wrote:
> Hi Martin,
> 
> 
> On 26/9/19 3:18 AM, Martin Koller wrote:
> > Hi,
> > 
> > just trying to compile Qt 5.12.5 for wasm-emscripten (on openSuse 15.0) and 
> > it fails.
> > Is this known or do I have a local problem ?
> 
> I haven't seen this error. I tried to reproduce this with suse 15.
> with this configure line:
> 
> -xplatform wasm-emscripten -developer-build -nomake tests -nomake 
> examples -opensource -confirm-license -verbose -compile-examples 
> -no-warnings-are-errors -release
> 
> What configure line are you using? Are you trying to use -shared ?

${QTDIR}/configure -xplatform wasm-emscripten -nomake examples \
-prefix ${dir}/qt5-installed -opensource -confirm-license \
-openssl-linked 
OPENSSL_INCDIR=/home/pvss/branch_3x/build/emscripten/ExternLibs/openssl/include 
\
OPENSSL_LIBDIR=/home/pvss/branch_3x/build/emscripten/ExternLibs/openssl/lib \
-skip qtscxml \
-skip qtdeclarative

It seems it has to do with openssl.
Should it be possible to configure with openssl ?

> > /home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h:45:1:
> >  error:
> >static_assert failed due to requirement 'bool(-1 == 1)' "Required 
> > feature library for file
> >
> > /home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h
> >  not available."
> > QT_REQUIRE_CONFIG(library);
> > ^~
> > /home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:87:36:
> >  note: expanded from
> >macro 'QT_REQUIRE_CONFIG'
> >...Q_STATIC_ASSERT_X(QT_FEATURE_##feature == 1, "Required feature " 
> > #feature " for file " __FILE__ " not available.")
> >   
> > ^~
> > /home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:121:49:
> >  note: expanded
> >from macro 'Q_STATIC_ASSERT_X'
> > #  define Q_STATIC_ASSERT_X(Condition, Message) 
> > static_assert(bool(Condition), Message)
> >  ^ 
> > ~~~
> > 1 error generated.
> > 
> 
> 


-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


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

Re: [Development] 5.12.5 and wasm-emscripten

2019-09-25 Thread Thiago Macieira 
On Wednesday, 25 September 2019 10:18:29 PDT Martin Koller wrote:
> just trying to compile Qt 5.12.5 for wasm-emscripten (on openSuse 15.0) and
> it fails. Is this known or do I have a local problem ?

Did you pass any -no-feature flags to configure? Remember: disabling features 
voids your warranty :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

2019-09-25 Thread Thiago Macieira 
On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote:
> Large parts of the world did not grow up with inches. I know I'd have
> a hard time to hold up my fingers to show an inch...

For most people, "DPI" is an arbitrary number ranging from 72 to 288...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

2019-09-25 Thread Thiago Macieira 
On Wednesday, 25 September 2019 05:54:20 PDT Morten Sørvig wrote:
> I see two differences between setting the DPI vs a factor:
> 
> - You set one value per screen (DPI) instead of two (DPI & factor)
> 
> - Qt can compute the factor, according to policy set by the application (as
> mentioned above)

Assume no one will ever call that function. What's the outcome?

Also, DPIs are a physical property of the monitor, but they don't account for 
my distance to it. Previously, I only needed one parameter to toggle, which 
was either 1 or 2. Now, in order to properly configure, I need to find out 
what the current DPI is and then update it.

Moreover, I can have two different monitors connected to the same output (at 
different times, of course). Since they have different DPI, the multiplicative 
factor allows me to set it once for both, but if I set a DPI setting, it'll 
likely be wrong for at least one of them.

> > Anyway, what's the correct way to specify now that one of my external
> > monitors  is highdpi but the other isn’t?
> 
> 
> The correct way would be to configure the windowing system. Qt would then
> pick up the configuration via the platform plugin.

Agreed, but for those of us still on X11, that's not na option.
 
> In practice, the environment variables you are currently using may be your
> best option on X11. 

Ok, thanks. This becomes the recommendation for KDE Plasma Shell configuration 
for X11 then: continue using the variables as they are.
 
> If possible, I’d like us to move away from relying on setting environment
> variables, and/or switch to specifying per-screen DPI instead of a scale
> factor.

Sure, but where, on X11?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] 5.12.5 and wasm-emscripten

2019-09-25 Thread Lorn Potter 

Hi Martin,


On 26/9/19 3:18 AM, Martin Koller wrote:

Hi,

just trying to compile Qt 5.12.5 for wasm-emscripten (on openSuse 15.0) and it 
fails.
Is this known or do I have a local problem ?


I haven't seen this error. I tried to reproduce this with suse 15.
with this configure line:

-xplatform wasm-emscripten -developer-build -nomake tests -nomake 
examples -opensource -confirm-license -verbose -compile-examples 
-no-warnings-are-errors -release


What configure line are you using? Are you trying to use -shared ?




/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h:45:1:
 error:
   static_assert failed due to requirement 'bool(-1 == 1)' "Required 
feature library for file
   
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h
 not available."
QT_REQUIRE_CONFIG(library);
^~
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:87:36:
 note: expanded from
   macro 'QT_REQUIRE_CONFIG'
   ...Q_STATIC_ASSERT_X(QT_FEATURE_##feature == 1, "Required feature " #feature " for file 
" __FILE__ " not available.")
  
^~
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:121:49:
 note: expanded
   from macro 'Q_STATIC_ASSERT_X'
#  define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), 
Message)
 ^ ~~~
1 error generated.



--
Lorn Potter
Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly

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

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

2019-09-25 Thread Elvis Stansvik 
Den ons 25 sep. 2019 kl 20:51 skrev Kai Pastor, DG0YT :
>
> Am 25.09.19 um 20:08 schrieb Elvis Stansvik:
> > Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke
> > :
> >> On 25/09/2019 08.54, Morten Sørvig wrote:
> >>> I see two differences between setting the DPI vs a factor:
> >>>
> >>> - You set one value per screen (DPI) instead of two (DPI & factor)
> >>>
> >>> - Qt can compute the factor, according to policy set by the
> >>> application (as mentioned above)
> >>>
> >>> [...]
> >>>
> >>> If possible, I’d like us to move away from relying on setting
> >>> environment variables, and/or switch to specifying per-screen DPI
> >>> instead of a scale factor.
> >> Has anyone considered whether or not this is *user* friendly?
> >>
> >> As a user, I don't want to have to know/measure/compute the DPI of my
> >> display device. I just want to make "stuff" bigger or smaller. I *also*
> >> don't necessarily want the same physical size of "stuff" across devices.
> >> On my phone, I may want smaller "stuff", because my phone is usually
> >> quite close to my eyes. On my 4K 75" television, I may want larger
> >> "stuff" because I'm sitting 10' to 15' away. Maybe I have really good
> >> (or really bad) eyesight.
> >>
> >> Fiddling with "fake DPI" as a way of adjusting things has always felt
> >> like a hack. Setting display scaling "just makes sense". From a user
> >> perspective, it's obvious that scaling is also going to affect icons,
> >> style margins, frame thicknesses... basically, *everything*. DPI,
> >> historically, only affected font sizes and *maybe* some margins. If the
> >> only knob I have is DPI, how do I know (or control) what size my icons
> >> will be? How am I supposed to guess what will be the relation between
> >> "virtual" pixels and physical pixels, keeping in mind that I, as a user,
> >> am trying to achieve a particular value for that?
> >>
> >> There are a few instances, such as when representing physical objects,
> >> when it makes sense to try to achieve a particular physical size. In
> >> almost *every other case*, which is to say *always* for interface
> >> elements, there is no fixed correlation between "desirable" size and
> >> actual physical size, and anyone that designs their application
> >> otherwise is doing their users a disservice.
> > Agree 100%. There's no reason for a user to have to fiddle around with
> > a strange number like 192, 96, or whatever.
> >
> > As a user I want 2 things:
> >
> > - Sane defaults and good autodetection, so a hopefully good automatic
> > scale factor that makes things reasonably sized given the physical
> > dimensions of the output device and its intended viewing distance
> > - ..but if I want to tune the size for whatever reason, I want to do
> > that in percentages of what it is *now*.
> >
> > It's easy enough for most folks to judge what % of the current size
> > that would get them where they want to be. It's not friendly to
> > present them with say 192 DPI, and when they want say 80% of that,
> > leave them to do the math. Or even asking them to relate the DPI to
> > physical inches (though I guess the DPI we're talking about here is
> > some intermediate virtual one?).
> >
> > Large parts of the world did not grow up with inches. I know I'd have
> > a hard time to hold up my fingers to show an inch...
> >
> > Elvis
> >
> > PS. Nevermind that in the KDE version I'm using, it's actually not
> > possible to tweak the scale factor per screen under X11 in the kscreen
> > KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to
> > dabble with that. But if I do want to dabble, I want to dabble in
> > percent. DS.
>
> There is nothing wrong with preferring simplicity for the most common
> case. But please provide a clear way how to get accurate sizes when
> desired, e.g. for 1:1 drawing or for print preview. With "clear"
> including uniform cross-platform.

Yes, absolutely, I want that use case to just work too of course. I
was speaking only of the "i want to change the size of buttons and
text on my computer" use case, not about print preview / desktop
publishing types of use cases (those are important too of course, and
should just work, irregardless of the user's desktop screen scaling
settings).

Elvis

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

2019-09-25 Thread Kai Pastor, DG0YT 

Am 25.09.19 um 20:08 schrieb Elvis Stansvik:
Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke 
:

On 25/09/2019 08.54, Morten Sørvig wrote:

I see two differences between setting the DPI vs a factor:

- You set one value per screen (DPI) instead of two (DPI & factor)

- Qt can compute the factor, according to policy set by the 
application (as mentioned above)


[...]

If possible, I’d like us to move away from relying on setting
environment variables, and/or switch to specifying per-screen DPI
instead of a scale factor.

Has anyone considered whether or not this is *user* friendly?

As a user, I don't want to have to know/measure/compute the DPI of my
display device. I just want to make "stuff" bigger or smaller. I *also*
don't necessarily want the same physical size of "stuff" across devices.
On my phone, I may want smaller "stuff", because my phone is usually
quite close to my eyes. On my 4K 75" television, I may want larger
"stuff" because I'm sitting 10' to 15' away. Maybe I have really good
(or really bad) eyesight.

Fiddling with "fake DPI" as a way of adjusting things has always felt
like a hack. Setting display scaling "just makes sense". From a user
perspective, it's obvious that scaling is also going to affect icons,
style margins, frame thicknesses... basically, *everything*. DPI,
historically, only affected font sizes and *maybe* some margins. If the
only knob I have is DPI, how do I know (or control) what size my icons
will be? How am I supposed to guess what will be the relation between
"virtual" pixels and physical pixels, keeping in mind that I, as a user,
am trying to achieve a particular value for that?

There are a few instances, such as when representing physical objects,
when it makes sense to try to achieve a particular physical size. In
almost *every other case*, which is to say *always* for interface
elements, there is no fixed correlation between "desirable" size and
actual physical size, and anyone that designs their application
otherwise is doing their users a disservice.

Agree 100%. There's no reason for a user to have to fiddle around with
a strange number like 192, 96, or whatever.

As a user I want 2 things:

- Sane defaults and good autodetection, so a hopefully good automatic
scale factor that makes things reasonably sized given the physical
dimensions of the output device and its intended viewing distance
- ..but if I want to tune the size for whatever reason, I want to do
that in percentages of what it is *now*.

It's easy enough for most folks to judge what % of the current size
that would get them where they want to be. It's not friendly to
present them with say 192 DPI, and when they want say 80% of that,
leave them to do the math. Or even asking them to relate the DPI to
physical inches (though I guess the DPI we're talking about here is
some intermediate virtual one?).

Large parts of the world did not grow up with inches. I know I'd have
a hard time to hold up my fingers to show an inch...

Elvis

PS. Nevermind that in the KDE version I'm using, it's actually not
possible to tweak the scale factor per screen under X11 in the kscreen
KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to
dabble with that. But if I do want to dabble, I want to dabble in
percent. DS.


There is nothing wrong with preferring simplicity for the most common 
case. But please provide a clear way how to get accurate sizes when 
desired, e.g. for 1:1 drawing or for print preview. With "clear" 
including uniform cross-platform.


Kai


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

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

2019-09-25 Thread Elvis Stansvik 
Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke :
>
> On 25/09/2019 08.54, Morten Sørvig wrote:
> > I see two differences between setting the DPI vs a factor:
> >
> > - You set one value per screen (DPI) instead of two (DPI & factor)
> >
> > - Qt can compute the factor, according to policy set by the application (as 
> > mentioned above)
> >
> > [...]
> >
> > If possible, I’d like us to move away from relying on setting
> > environment variables, and/or switch to specifying per-screen DPI
> > instead of a scale factor.
> Has anyone considered whether or not this is *user* friendly?
>
> As a user, I don't want to have to know/measure/compute the DPI of my
> display device. I just want to make "stuff" bigger or smaller. I *also*
> don't necessarily want the same physical size of "stuff" across devices.
> On my phone, I may want smaller "stuff", because my phone is usually
> quite close to my eyes. On my 4K 75" television, I may want larger
> "stuff" because I'm sitting 10' to 15' away. Maybe I have really good
> (or really bad) eyesight.
>
> Fiddling with "fake DPI" as a way of adjusting things has always felt
> like a hack. Setting display scaling "just makes sense". From a user
> perspective, it's obvious that scaling is also going to affect icons,
> style margins, frame thicknesses... basically, *everything*. DPI,
> historically, only affected font sizes and *maybe* some margins. If the
> only knob I have is DPI, how do I know (or control) what size my icons
> will be? How am I supposed to guess what will be the relation between
> "virtual" pixels and physical pixels, keeping in mind that I, as a user,
> am trying to achieve a particular value for that?
>
> There are a few instances, such as when representing physical objects,
> when it makes sense to try to achieve a particular physical size. In
> almost *every other case*, which is to say *always* for interface
> elements, there is no fixed correlation between "desirable" size and
> actual physical size, and anyone that designs their application
> otherwise is doing their users a disservice.

Agree 100%. There's no reason for a user to have to fiddle around with
a strange number like 192, 96, or whatever.

As a user I want 2 things:

- Sane defaults and good autodetection, so a hopefully good automatic
scale factor that makes things reasonably sized given the physical
dimensions of the output device and its intended viewing distance
- ..but if I want to tune the size for whatever reason, I want to do
that in percentages of what it is *now*.

It's easy enough for most folks to judge what % of the current size
that would get them where they want to be. It's not friendly to
present them with say 192 DPI, and when they want say 80% of that,
leave them to do the math. Or even asking them to relate the DPI to
physical inches (though I guess the DPI we're talking about here is
some intermediate virtual one?).

Large parts of the world did not grow up with inches. I know I'd have
a hard time to hold up my fingers to show an inch...

Elvis

PS. Nevermind that in the KDE version I'm using, it's actually not
possible to tweak the scale factor per screen under X11 in the kscreen
KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to
dabble with that. But if I do want to dabble, I want to dabble in
percent. DS.

>
> --
> Matthew
> ___
> 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] 5.12.5 and wasm-emscripten

2019-09-25 Thread Martin Koller 
Hi,

just trying to compile Qt 5.12.5 for wasm-emscripten (on openSuse 15.0) and it 
fails.
Is this known or do I have a local problem ?

/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h:45:1:
 error:
  static_assert failed due to requirement 'bool(-1 == 1)' "Required feature 
library for file
  
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/plugin/qlibrary.h
 not available."
QT_REQUIRE_CONFIG(library);
^~
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:87:36:
 note: expanded from
  macro 'QT_REQUIRE_CONFIG'
  ...Q_STATIC_ASSERT_X(QT_FEATURE_##feature == 1, "Required feature " #feature 
" for file " __FILE__ " not available.")
 
^~
/home/PACKAGES/qt/5.12.5/qt-everywhere-src-5.12.5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:121:49:
 note: expanded
  from macro 'Q_STATIC_ASSERT_X'
#  define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), 
Message)
^ ~~~
1 error generated.
-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


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

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

2019-09-25 Thread Matthew Woehlke 
On 25/09/2019 08.54, Morten Sørvig wrote:
> I see two differences between setting the DPI vs a factor:
> 
> - You set one value per screen (DPI) instead of two (DPI & factor)
> 
> - Qt can compute the factor, according to policy set by the application (as 
> mentioned above)
> 
> [...]
> 
> If possible, I’d like us to move away from relying on setting
> environment variables, and/or switch to specifying per-screen DPI
> instead of a scale factor.
Has anyone considered whether or not this is *user* friendly?

As a user, I don't want to have to know/measure/compute the DPI of my
display device. I just want to make "stuff" bigger or smaller. I *also*
don't necessarily want the same physical size of "stuff" across devices.
On my phone, I may want smaller "stuff", because my phone is usually
quite close to my eyes. On my 4K 75" television, I may want larger
"stuff" because I'm sitting 10' to 15' away. Maybe I have really good
(or really bad) eyesight.

Fiddling with "fake DPI" as a way of adjusting things has always felt
like a hack. Setting display scaling "just makes sense". From a user
perspective, it's obvious that scaling is also going to affect icons,
style margins, frame thicknesses... basically, *everything*. DPI,
historically, only affected font sizes and *maybe* some margins. If the
only knob I have is DPI, how do I know (or control) what size my icons
will be? How am I supposed to guess what will be the relation between
"virtual" pixels and physical pixels, keeping in mind that I, as a user,
am trying to achieve a particular value for that?

There are a few instances, such as when representing physical objects,
when it makes sense to try to achieve a particular physical size. In
almost *every other case*, which is to say *always* for interface
elements, there is no fixed correlation between "desirable" size and
actual physical size, and anyone that designs their application
otherwise is doing their users a disservice.

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

[Development] Add functionality to QPdfWriter

2019-09-25 Thread Erik Janssens 
Hi,

We would like to add some functionality QPdfWriter to be able to
embed custom xmp metadata and attachments in the pdf files generated
by QPdfWriter.

This would improve the handling of pdf files created in Qt by other
applications, such as document managment systems.

The proposed changes are documented in :

QTBUG-78651
QTBUG-78764

Would such changes be welcome, and would a pull request with
such changes have a chance of being accepted ?

An alternative solution to the same problem would be change the API
somehow that the individual pdf objects generated by QPdfWriter can
be retrieved.
The developer would then be able to re-assemble his own pdf mixing
objects generated by Qt with other things.
Such an approach however seems much more work and more convoluted.

First time post, so any feedback is welcome.

Best regards,

Erik

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

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

2019-09-25 Thread Morten Sørvig 


> On 24 Sep 2019, at 17:54, Thiago Macieira  wrote:
> 
> On Monday, 16 September 2019 06:00:27 PDT Morten Sørvig wrote:
>> 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.
> 
> How is setting the DPI different than setting the multiplicative factor that 
> was applied to the DPI before? Are you expecting a lot of applications having 
> called that function above? Assume there's less than 0.1% of them doing that.

To start with setHighDpiScaleFactorRoundingPolicy: this function is new in 5.14 
so I don’t think it has many users right now. The corresponding QTBUG had a 
good number of votes and watchers though, so I expect it will be used.

I see two differences between setting the DPI vs a factor:

- You set one value per screen (DPI) instead of two (DPI & factor)

- Qt can compute the factor, according to policy set by the application (as 
mentioned above)

> 
> Anyway, what's the correct way to specify now that one of my external 
> monitors 
> is highdpi but the other isn’t?

The correct way would be to configure the windowing system. Qt would then pick 
up the configuration via the platform plugin.

In practice, the environment variables you are currently using may be your best 
option on X11. 

If possible, I’d like us to move away from relying on setting environment 
variables, and/or switch to specifying per-screen DPI instead of a scale factor.


- Morten

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> 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

2019-09-25 Thread Kari Oikarinen 


On 16.9.2019 15.10, Lars Knoll wrote:
> 
>> 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 :)

There doesn't seem to be opposition to this. Any single choice also can't always
be correct, because the right branch to target depends on what kind of change
you are working on.

I've gone ahead and changed the default branches to be dev.

-- 
Kari

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

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

[Development] Qt 5.14.0 Alpha released

2019-09-25 Thread Jani Heikkinen 
Hi all,

We have released Qt 5.14.0 Alpha today, see 
https://www.qt.io/blog/qt-5.14-alpha-released
Big thanks to everyone involved!

Br,
Jani Heikkinen
Release Manager



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

Re: [Development] Where to find development snapshots of Qt

2019-09-25 Thread Richard Weickelt 
> You can download snapshot via online installer. At the moment we don't publish
> separate src packages to download.qt.io

Thanks, but I can't see any Qt snapshots in the online installer. Some of the 
"preview" packages there are even outdated.
This is what I see: https://pasteboard.co/Iz16Exp.png
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Where to find development snapshots of Qt

2019-09-25 Thread Richard Weickelt 

> I guess that building Qbs in Coin is the only way to build against unreleased
> Qt versions.

How much effort would that be to set up and to maintain for an external
contributor? Any experiences?

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