Re: [Development] Moving Qt's undo framework out of Qt Widgets

[Morten Sørvig]

> On 5 Apr 2017, at 12:37, Oswald Buddenhagen  wrote:
> 
> On Wed, Apr 05, 2017 at 09:24:15AM +, Mitch Curtis wrote:
>> So, should this get its own module, and if so, can widgets depend on
>> it?
>> 
> an own module just for that seems over the top - i don't think we want
> to end up with 100 micro-libraries.
> 
> however, splitting up qtcore has been raised multiple times, and
> putting this into one of the resulting libs would seem reasonable. for
> example, this seems conceptually quite related to item models. possibly
> also state machine. and animation. these are all things which initially
> elicit a "huh, this is core?" response, until you think a bit about it.
> GuiSupport may be a better name for it (i'm sure some will disagree).

So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”;

QtCoreCoreQtGuiCore
QtCoreSinkQtGuiSink

QtWidgets and QtDeclarative would depend on all of these; are we gaining
anything? Well:

1) The “Core” versions will be satisfyingly uncluttered.
2) Those who do not use QtWidgets or QtDeclarative can possibly depend
   on smaller libraries.

> 
> also, a plan for splitting up qtbase wouldn't be entirely off the mark.
> untangling tests and examples would be the major effort here.

(At the risk of derailing the discussion (sorry Mitch)) No, we should
follow Google and Facebook’s lead: large monolithic repos (as large as
the infrastructure can handle), which can be updated atomically.

Morten


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

Re: [Development] State of 5.9 and dev branches

[Morten Sørvig]

Thanks for cleaning this up quickly!

When it comes to testing, do we want to go one step further and 
make the tests be completely independent of the current time? We would
like to avoid time bombs like these, and if something _is_ going to
fail at some future date we would like to know so right away.

I coded up a strawman proposal here: 
https://codereview.qt-project.org/201989

It adds a RAII class to QTestLib that allows setting the datetime
(as returned by QDateTime) for the duration of a test function:

QTestTimeFixer fixedTime(QDateTime(QDate(2015, 1, 1)).toMSecsSinceEpoch());

This is then used to set the date time to sometime in the past for
tst_qnetworkcookiejar, which makes the unpatched version of it pass.
Going further we could set the time to the future and verify that
the cookies expire as expected.

Morten


> On 8 Aug 2017, at 09:40, Simon Hausmann  wrote:
> 
> 
> Thank you Thiago, Sergio and Lars!
> 
> qtbase 5.6 and 5.9 are good again.
> 
> Simon
> From: Development  
> on behalf of Thiago Macieira 
> Sent: Monday, August 7, 2017 10:54:22 PM
> To: development@qt-project.org
> Subject: Re: [Development] State of 5.9 and dev branches
>  
> On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote:
> > Hi,
> > 
> > The 5.9 fix went in. Would be most grateful if somebody could do the cherry
> > pick and merge. I won't have a keyboard until tomorrow late morning.
>  
> 5.6: https://codereview.qt-project.org/201945
> dev: https://codereview.qt-project.org/201946
> 
> -- 
> 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 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] QUIP 8: High-DPI Support

[Morten Sørvig]

Hi all,

A draft of QUIP 8: High-DPI Support is now available:

https://codereview.qt-project.org/#/c/194524

Comments are welcome! Either here or on codereview.

The plan is to write this up in there parts:

1) High-DPI terms and overview of other platforms
2) High-DPI support rationale for Qt
3) Documentation for the devicePixelRatio implementation

The first part is available as a draft now and is intended to be a fairly
neutral overview. Following parts will have increasing opinionatedness towards
a specific approach and implementation.

Morten

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

Re: [Development] Flaky auto tests on macOS 10.12

[Morten Sørvig]

> On 19 Jun 2017, at 08:34, J-P Nurmi  wrote:
> 
> Hi all,
> 
> After a few successful qt5.git CI rounds, auto tests were enabled for macOS 
> 10.12 in the CI last week. [*] Even though many flaky auto tests had been 
> already blacklisted on macOS 10.12 earlier 
> (https://bugreports.qt.io/browse/QTBUG-58968), it became nearly impossible to 
> integrate any qtbase patch due to random timer/eventloop/animation related 
> auto test failures on macOS 10.12. As agreed earlier 
> (http://lists.qt-project.org/pipermail/development/2017-February/028715.html),
>  an action was taken to blacklist/skip several more auto tests on macOS 10.12:

I went through the list and most of these are not reproducible locally. (see
list below for details). This matches the pattern we’ve been seeing for some
time with CI-only failures.

So I think the priority for the reports should be reduced once the tests have
been blacklisted and they are no longer blocking development, due to them being
hard to reproduce as well as being less likely to be hit by users.

Morten


> 
> Extend blacklisting of tst_QElapsedTimer::elapsed to cover macOS 10.12
> - https://bugreports.qt.io/browse/QTBUG-58713
> - https://codereview.qt-project.org/#/c/195625/

Not reproducible.

> 
> Blacklist tst_QGuiEventLoop::processEvents in macOS 10.12
> - https://bugreports.qt.io/browse/QTBUG-61131
> - https://codereview.qt-project.org/#/c/196087/

Reproducible. Looks like 10.12 is sending an extra event at startup
which the test fails to account for (see QTBUG-61131 for details).

> 
> Blacklist flaky tst_QTimeLine tests on macOS 10.12
> - https://bugreports.qt.io/browse/QTBUG-61037
> - https://codereview.qt-project.org/#/c/195608/

Not reproducible.

> 
> Skip unreliable tst_QTimer::moveToThread() on macOS 10.12
> - https://bugreports.qt.io/browse/QTBUG-59679
> - https://codereview.qt-project.org/#/c/197769/

Not reproducible (however, warnings).
QWARN  : tst_QTimer::moveToThread() QObject::killTimer: Timers cannot be 
stopped from another thread
QWARN  : tst_QTimer::moveToThread() QObject::~QObject: Timers cannot be stopped 
from another thread

> 
> Blacklist flaky tst_QGuiEventLoop::testQuitLock() on macOS 10.12
> - https://bugreports.qt.io/browse/QTBUG-61499
> - https://codereview.qt-project.org/#/c/197791/

Not reproducible.

> 
> Blacklist tst_QParallelAnimationGroup::deleteChildrenWithRunningGroup()
> - https://bugreports.qt.io/browse/QTBUG-61500
> - https://codereview.qt-project.org/#/c/197792/

Not reproducible.


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

Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail?

[Morten Sørvig]

> On 16 Jun 2017, at 23:21, Thiago Macieira  wrote:
> 
> On Friday, 16 June 2017 13:23:07 PDT Thiago Macieira wrote:
>> QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy)
>> QHostAddress("fe80::250:56ff:feab:4818%eth1")
>> FAIL!  : tst_QUdpSocket::linkLocalIPv6(WithoutProxy)
>> '(neutralReadSpy.count()
>>> 0)' returned FALSE. ()
>> 
>>Loc: [../tst_qudpsocket.cpp(1600)]
> 
> Emergency workaround: https://codereview.qt-project.org/197753 
> (compiles and works for me on bare metal, no test on a VM)
> 
> This commit basically disables the test entirely on virtual machines. If any 
> QtNetwork developers use virtual machines, please make sure you get 
> bare-metal 
> hardware for all three platforms. You won't be doing your job if you continue 
> with VMs.


This does seem a bit heavy-handed to me.

 - Can we self-test the network interface and QSKIP if it’s not in working 
order?

 - We can blacklist on CI only: https://codereview.qt-project.org/#/c/197692/
   (modifying that patch to blacklist all Linux CI if needed.)

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

Re: [Development] Flaky auto tests on macOS 10.12

[Morten Sørvig]

> On 19 Jun 2017, at 13:09, Tony Sarajärvi  wrote:
> 
> It is the intention that we do this. But we're constantly running, not beside 
> our horse, but after it. We have just begun activating ourselves to discuss 
> about 5.10 platforms and we have FF coming up in two weeks (counting out July 
> here).
> It took months to blacklist all the cases for 10.12 alone. So yes, I agree 
> that how we do this is not good, but at some point we find it good enough. I 
> ran qt5 builds through twice without failures and deemed it fit. Before that 
> I kept blacklisting everything I saw (which actually isn't good either).
> 
> Dev branch is actually the place where they should be put yes. Unfortunately 
> we are too late for that. We need 10.12 in 5.9, and for it to still be in dev 
> branch, we should have put it in January. We were still working with our 5.8 
> platforms at that time. As I said...the horse is running away from us 


The process could be (using the current branches and os versions as examples):

- Add 10.12 to dev.
- Stabilize/fix/blacklist (backport changes to 5.9)
- Qt is now tested on 10.12. Also the 5.9 codebase, since it is similar to dev.

- Then add 10.12 to 5.9
- With less disruption since Qt already has been stabilized.

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

Re: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed

[Morten Sørvig]

Hi,

Not sure if I can be of much help, but:

- This thread discusses and solves a similar problem: 
https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application

- If this could be reduced to a simple sandboxed-app-with-helper-process test 
case (no QtWebEngine usage), that that’s something I could look at, and 
something we could eventually add an autotest for.


Morten


> On 28 Apr 2017, at 18:49, Adalid Claure  wrote:
> 
> I have a desktop app that I have been trying to get onto the Mac App store 
> but I have been having problems getting it to run in sandbox mode. For 
> context I am (preferably) using Qt 5.8 running on macOS 10.11.6.
> 
> The crux seems to be QtWebEngineProcess.app refuses to run after I codesign 
> the bundle. As a result, my QtWebEngine component doesn't load. I am using 
> this QtWebEngine component as part of my app's UI.
> 
> When the app starts I see the following errors in Console:
> 
> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup 
> org.chromium.Chromium.rohitfork.20763
> kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup 
> org.chromium.Chromium.rohitfork.20763
> QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
> bootstrap_look_up: Permission denied (1100)
> QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
> bootstrap_look_up: Permission denied (1100)
> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit
> 
> My build process is pretty straight forward:
> 
> 1. Run macdeployqt on the app, using the -appstore-compliant.
> 2. Sign all of the Qt Frameworks and PlugIns individually with my app's 
> entitlement file.
> 3. Sign QtWebEngineProcess.app with the following entitlements file:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> 
> com.apple.security.app-sandbox
> 
> com.apple.security.inherit
> 
> 
> 
> 
> 4. Call codesign on the overall MyProgram.app bundle with the entitlements 
> file from Step 2.
> 
> I have tried numerous things all in combination with one another, including:
> 
> a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per 
> the notes here: 
> https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility)
> b. use macdeployqt's -codesign, even though the binarys have to be signed a 
> second time after this in order to apply the entitlements
> c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 
> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID.
> d. tried linking with Qt 5.7
> e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by 
> Apple because:
> 
> ---
> Your app uses or references the following non-public API(s):
> 
> framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit'
> : NSAccessibilityUnregisterUniqueIdForUIElement
> : _NSAppendToKillRing
> : _NSDrawCarbonThemeBezel
> : _NSDrawCarbonThemeListBox
> : _NSInitializeKillRing
> : _NSNewKillRingSequence
> : _NSPrependToKillRing
> : _NSSetKillRingToYankedState
> : _NSYankFromKillRing
> 
> framework: 
> '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
> : CGSSetDenyWindowServerConnections
> : CGSShutdownServerConnections
> : CTFontCopyDefaultCascadeList
> 
> The use of non-public APIs is not permitted on the App Store as it can lead 
> to a poor user experience should these APIs change.
> ---
> 
> I have chronicled a lot of this in this thread here 
> (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess)
>  but the problem persists. 
> 
> Does anyone have any suggestions? Does anyone know of any apps on the Mac App 
> Store that use QtWebEngine?
> 
> Thanks.
> ___
> 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] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[Morten Sørvig]

> On 30 Aug 2017, at 09:30, Olivier Goffart  wrote:
> 
> Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
>> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
>>> Which we just rediscovered :) Funny though, apparently 1 misdirected
>>> startTimer() call can turn any application in a CPU hog that burns cycles
>>> without ever doing anything. Wouldn't it be safer for
>>> QObject::timerEvent()
>>> to kill any timer that triggers it, possibly even do an abort if it can do
>>> some kind of runtime debug mode detection? At least then it's set to a 0
>>> (zero) interval?
>> 
>> Sure. Please tell that to Eirik and Håvard back in the early 90s when
>> they're designing Qt.
>>  http://doc.qt.io/archives/2.3/qobject.html#4c6b67
>>  (Qt 1 docs not online)
>> 
>> Unfortunately, we can't change anymore.
> 
> We can change the documentation and recommend against using killTimer and 
> startTimer. QBasicTimer should be used instead. This would have probably 
> avoided the problem in this case (as one would have called stop instead of 
> m_updateTimer = 0). And in general is easier to use for 0 overhead.

There is also the option of creating new API that better covers the use case of
running a pice of code once when control returns to the event loop. In use this
could look something like this:

QCocoaMenu::scheduleUpdate()
{
if (m_updateScheduled)
   return;
m_updateScheduled = true;

this->QObject::schedule([_updateScheduled, m_nativeMenu](){
m_updateScheduled = false;
[m_nativeMenu update];   
});
}

or even:

QCocoaMenu::scheduleUpdate()
{
this->QObject::scheduleOnce(_updateScheduled, [m_nativeMenu](){
[m_nativeMenu update];   
});
}

Morten





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

Re: [Development] Apple officially deprecates OpenGL

[Morten Sørvig]

> On 4 Jun 2018, at 22:20, Walter Purvis  wrote:
> 
> Is this going to cause issues with Qt Quick applications? I.e., will Qt Quick 
> apps be broken or unacceptably slow in future versions of macOS? (The next 
> version of macOS merely deprecates OpenGL, but it raises the question of when 
> it might be removed from macOS altogether.)
> 
> 
> https://developer.apple.com/macos/whats-new/
> 
> "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but 
> these legacy technologies are deprecated in macOS 10.14. Games and 
> graphics-intensive apps that use OpenGL should now adopt Metal.”

From the platform side, we’ve recently (dev/5.12) added support for 
QSurface:MetalSurface and also QSurface::VulkanSurface (via MoltenVK) on macOS. 
So this opens the door for developing new Qt Quick backends.

Morten

> ___
> 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] QTest qWaitForWindowExposed and qWaitForWindowActive (was: Consistently flaky test QTabWidget test)

[Morten Sørvig]

> On 2 May 2018, at 09:29, Thiago Macieira  wrote:
> 
> FAIL!  : tst_QTabWidget::paintEventCount() Compared values are not the same
>Actual   (tab2->count): 2
>Expected (1)  : 1
>Loc: [tst_qtabwidget.cpp(573)]
> [on macOS 10.12]

Hi,

I recently investigated a similar issue as to the one described here, where
tests where failing due to extra paint events. This resulted in a couple of
patches to stabilize tests, and discussions on how to proceed, all of which
is documented on QTBUG-61967. (I unfortunately failed to share the outcome of 
the discussions beyond posting on that bug, which I’m rectifying now).

To recap:

* WindowExposed occurs when the window becomes visible on screen and is
  about to draw the first frame.

* WindowActive occurs if/when the platform makes the window active, which
  may trigger a repaint to make widgets etc have the “active” styling.

WindowActive may occur either before or after Exposed, depending on
platform (plugin) implementation and/or platform timing outside of our
control. This means that a test that waits for Exposed before starting
to count paint events may have the count erroneously increased when the
Active event arrives.

It could be argued that WindowActive a sub-state of WindowExposed and that
the platform plugin should enforce the ordering, but in the end we settled
on keeping them separate. This means tests might want to wait for both:

QTest::qWaitForWindowExposed(window);
QTest::qWaitForWindowActive(window);
// Now count paint events.

This is obviously a bit unwieldy so we want to improve the API as well:
watch QTBUG-61967 for updates.

Morten



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

Re: [Development] Mismatch of display resolutions and window sizes in Android applications

[Morten Sørvig]

This is by design for Qt::AA_EnableHighDpiScaling: you get the logical window 
size. The 
physical size can be computed by multiplying with 
QQuickWindow::effectiveDevicePixelRatio().

For QtLocation it looks like you have to enable high-dpi tiles by setting 
“osm.mapping.highdpi_tiles"
(or a similar option, depending on which tile provider you are using).

Morten


> On 13 Jan 2018, at 19:27, Denis Shienkov  wrote:
> 
> The problem was in Qt::AA_EnableHighDpiScaling option.
> 
> 13.01.2018 19:34, Denis Shienkov пишет:
>> Hi all.
>> 
>> Rigth now I faced with the strange issue is that the QML 
>> window size (screen) does not correspond to the display 
>> resolution.
>> 
>> For example, I have the "ASUS ZenFone 4 Max ZC554KL" 
>> smartphone which has display resolution as 1280x720 pixels.
>> 
>> But if I run there the QML application and try to print out
>> the ApplicationWindow size, then it is 360x568 or 640x288
>> pixels, depends on orientation. O_o
>> 
>> I have checked the same and on other smartphones, and see
>> that there the situation is similar. E.g. for the 
>> "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got
>> 320x460 or 533x247 pixels of my ApplicationWindow. 
>> 
>> For example if try to use the QtLocation module, then any
>> maps looks ugly. 
>> 
>> It is very bad surprise for me... Because, seems, now I can
>> not write any applications with high resolusion (or, at least
>> to operate with a real resolutions from my QML code).
>> 
>> Is there are any tricks to fix it?
>> 
>> PS: Some Android's firmwares (e.g. Cyanogen)  allows to change
>> the DPI, and with the minimum DPI the ApplicationWindow size
>> increases a bit.. But it is not an option anyway.
>> 
>> BR,
>> Denis
> 
> ___
> 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] Using Native web view on OS X

[Morten Sørvig]

> On 25 Jan 2018, at 21:05, Steve Schilz  wrote:
> 
>> 22.01.2018, 18:37, "Alberto Mardegan" :
>>  Hi all!
>>  ??I've developed a desktop application which uses the WebView QML
>>  module, with the hope of publishing it in the Apple store. However,
>>  unless I am seriously mistaken, this is just not possible (or maybe the
>>  documentation needs some serious love).
>> 
>>  No matter what I try, it seems that QtWebEngine is always required!
>> 
>>  If I simply remove QtWebEngine from my Qt installation, building the
>>  application succeeds but then when I run it I get the same error as in
>>  https://bugreports.qt.io/browse/QTBUG-63107
>> 
>>  If I look at src/webview/qtwebviewfunctions.cpp it looks like the
>>  decision to use the native webview vs QtWebEngine is done at runtime,
>>  but for some reason it looks like one still needs to have QtWebEngine
>>  available in order for QtWebView to build successfully. With the obvious
>>  consequence that one won't be able to publish one's app into the Apple
>>  store.
>> 
>>  Is there some reason why the QtWebEngine support library isn't dlopen'ed
>>  at runtime? Can I file a bug about that?
>> 
>>  From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable
>>  is required to use native backend.
>> 
>>  [1] https://codereview.qt-project.org/#/c/162337/
>> 
>> 
>> Ciao,
> ? ?Alberto
> 
>   ?On 22/01/2018 18:49, Konstantin Tokarev wrote:
>   ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment 
> variable is required to use native backend.
>   
>   ?[1] https://codereview.qt-project.org/#/c/162337/
> 
>   Regards,
>   Konstantin
> 
 ?On 22 Jan 2018, at 18:22, Alberto Mardegan 
  wrote:
?Yes, but still QtWebEngine is required, as QtWebView is 
 linking to it.
?I've now removed a few lines of code here and there and got a 
 version of
?QtWebView which builds fine under macos without being linked 
 to QtWebEngine.
>>> ?I'll soon try to see if it actually works.
 
?Ciao,
??Alberto
 
> 
>>> >> 23.01.2018, 17:09, "Morten S?rvig" :
>>> The QtWebEngine requirement does seem to run counter to the 
>>> purpose of the QtWebView module.
>>> 
>>> It?s not really clear from the history what happened, but I 
>>> think we can restore the original behavior:
>>> 
>>> https://codereview.qt-project.org/#/c/217706/
>>> 
>>> There was a discussion about run-time plugins in QtWebView, if 
>>> they were implemented it won't be
>>> a problem to load and use QtWebEngine backend if it is really 
>>> needed, and avoid it otherwise
>>> 
>>> 
>>> Morten
>>> 
> 
>>  23.01.2018, 17:09, "Morten S?rvig" :
>>  In the end we decided to go with this approach and finalize the 
>> plugin patch for dev. The other branches
>>  will be left as-is. In the mean time it's possible is to build 
>> QtWebView from source with the above patch
>>  If you want to avoid the QtWebEngine requirement.
>>  
>>   Morten
>> 
> Apologies in advance if this comes off in any way as rude, I love Qt, and 
> respect everyone here greatly.
> 
> Am I correct in understanding that you are saying that prebuilt Qt packages 
> cannot be used to submit to the app store,
> And that anyone who wishes to use Qt to develop an app on OSX and submit to 
> the app store must be savvy enough to
> Build from source, and locate this thread in the dev newsgroup, and then 
> apply the patch specified? 

I agree with this point, but as I said we concluded with not changing the 
current Qt versions. Order
will be restored once the plugin patch is released. I’m not sure what the 
default plugin will be yet, but at
the very least you can select the native plugin by not building QWebEngine or 
not deploying the QWebEngine
plugin (e.g. with macdeployqt -appstore-compliant).

Morten



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

Re: [Development] Using native webview on OS X

[Morten Sørvig]

> On 23 Jan 2018, at 15:11, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 23.01.2018, 17:09, "Morten Sørvig" <morten.sor...@qt.io>:
>> 
>> The QtWebEngine requirement does seem to run counter to the purpose of the 
>> QtWebView module.
>> 
>> It’s not really clear from the history what happened, but I think we can 
>> restore the original behavior:
>> 
>> https://codereview.qt-project.org/#/c/217706/
> 
> There was a discussion about run-time plugins in QtWebView, if they were 
> implemented it won't be
> a problem to load and use QtWebEngine backend if it is really needed, and 
> avoid it otherwise
> 

In the end we decided to go with this approach and finalize the plugin patch 
for dev. The other branches
will be left as-is. In the mean time it's possible is to build QtWebView from 
source with the above patch
if you want to avoid the QtWebEngine requirement.

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

Re: [Development] LLVM and Qt

[Morten Sørvig]

> On 30 Jul 2018, at 06:00, Thiago Macieira  wrote:
> 
> On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> It would also be pretty nice to know if there is a policy with respect the
>> llvm supported version. As they do not keep ABI compatibility distros
>> normally are forced to ship from two to three versions. As I understand the
>> idea in Debian testing/unstable is to have the latest two always available,
>> sometimes three of them. That already created some issues for us with Qt
>> Creator, as at some point it required a version which was about to be
>> removed.
> 
> Same policy for third-party libraries: we work with the latest, unless that 
> release happened too late in our own release cycle.
> 
> But where do we get LLVM from on a Mac? Is it from Apple? If so, we may need 
> to keep things working with an old, patched version, in addition to the 
> latest. Or we require an upgrade with Homebrew.

For dev/5.12 we’re going to default to LLVM from homebrew if LLVM_INSTALL_DIR
is not set.

The Xcode toolchain does actually contain a libclang.dylib, but as far as I can
see llvm-config and the clang-c/Index.h header are not included, which means we
can’t use it for qdoc.

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

Re: [Development] LLVM and Qt

[Morten Sørvig]

> On 30 Jul 2018, at 06:00, Thiago Macieira  wrote:
> 
> On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> It would also be pretty nice to know if there is a policy with respect the
>> llvm supported version. As they do not keep ABI compatibility distros
>> normally are forced to ship from two to three versions. As I understand the
>> idea in Debian testing/unstable is to have the latest two always available,
>> sometimes three of them. That already created some issues for us with Qt
>> Creator, as at some point it required a version which was about to be
>> removed.
> 
> Same policy for third-party libraries: we work with the latest, unless that 
> release happened too late in our own release cycle.
> 
> But where do we get LLVM from on a Mac? Is it from Apple? If so, we may need 
> to keep things working with an old, patched version, in addition to the 
> latest. Or we require an upgrade with Homebrew.

For dev/5.12 we’re going to default to LLVM from homebrew if LLVM_INSTALL_DIR
is not set.

The Xcode toolchain does actually contain a libclang.dylib, but as far as I can
see llvm-config and the clang-c/Index.h header are not included, which means we
can’t use it for qdoc.

Morten

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

Re: [Development] Upgrade the XCode running in the CI's macOS 10.11

[Morten Sørvig]

> On 9 Jul 2018, at 02:15, Thiago Macieira  wrote:
> 
> This is the second time I've run into a compiler bug with that XCode's 
> ancient 
> Clang.
> 
> Can we please upgrade the XCode installation there to the latest available 
> for 
> macOS 10.11? 
> 
> If that's the latest, can we declare that building Qt on 10.11 is no longer 
> supported for Qt 5.12? I'm not asking about deployment, only building.


Yes, let’s drop support for the older clang versions. 

There are some other aspects to take into account as well:

- As mentioned above, we want to drop support for outdated compilers for new Qt 
releases.

- We want to deploy to a relativly wide range of macOS platforms. Current - 2. 
If the minimum deployment target for the LTS releases is fixed, then older 
macOS versions stay relevant.

- We can require that developers stay reasonably up to date: current +/- 1.

- We are now seeing that older Qt versions are not going to support newer SDKs, 
since Apple is using the build SDK version to enable new behaviors (for example 
dark mode and CA layers on 10.14). This means the max supported SDK version for 
e.g. Qt 5.9 is the 10.13 SDK.

- On the other hand we would like to build the 5.12 binary package with the 
10.14 SDK in order to make use of new API.

- Can we mix and match compiler and SDK versions? Empiricism shows that it’s 
the final app link SDK that gates the enabled features, so it might not matter 
exactly which SDK the Qt binary package is built against for this purpose.

- CI system support for building on one platform version and deploying/testing 
on others is still on the wish list :)


Morten

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

Re: [Development] Using native webview on OS X

[Morten Sørvig]

> On 22 Jan 2018, at 18:22, Alberto Mardegan  
> wrote:
> 
> On 22/01/2018 18:49, Konstantin Tokarev wrote:
>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable
>> is required to use native backend.
>> 
>> [1] https://codereview.qt-project.org/#/c/162337/
> 
> Yes, but still QtWebEngine is required, as QtWebView is linking to it.
> I've now removed a few lines of code here and there and got a version of
> QtWebView which builds fine under macos without being linked to QtWebEngine.
> I'll soon try to see if it actually works.
> 
> Ciao,
>  Alberto


The QtWebEngine requirement does seem to run counter to the purpose of the 
QtWebView module.

It’s not really clear from the history what happened, but I think we can 
restore the original behavior:

https://codereview.qt-project.org/#/c/217706/

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

Re: [Development] Qt for WebAssembly

[Morten Sørvig]

> On 9 Mar 2018, at 19:09, Tim Murison  wrote:
> I'd also like to echo and hopefully amplify what Jason H said about
> qmlweb. IMO, this is the solution that Qt should be embracing and
> integrating upstream. qmlweb aims to do what Qt has always done, make
> cross-platform development easy, efficient and indistinguishable from
> native development.


I think qmlweb and Qt for wasm are fundamentally different enough
(reimplementing Qt Quick vs recompiling it for a new platform) that they
are not mutually exclusive. We could accept either or both upstream,

It could be interesting to make them API-compatible so that users can
move between them with minimal effort. For example by providing a 
“QtQuick.QMLEngine()”
Javascript API that can be used interchangeably with “QmlWeb.QMLEngine()”.

  var div = document.getElementById('embed');
  var engine = new QmlWeb.QMLEngine(div);
  engine.loadFile('qml/main.qml');
  engine.start();

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

Re: [Development] Qt for WebAssembly

[Morten Sørvig]

> On 9 Mar 2018, at 15:53, Jason H  wrote:
> 
> 
> I don't want to steal your thunder, but what is fundamentally different about 
> this approach this time? Why will the results be any different?


Oh, who knows what will happen. But there are indicators that this time
may be different:

   * WebAssembly is a web standard
   * General support for web applications is getting better (e.g. service 
workers)
   * Canvas-rendering web apps now exist (Google Sheets)
   * Better connectivity makes “large” web apps more feasible.

The project _may_ end up providing limited value to Qt users, but I think
it would be a mistake to conclude so up front,

Morten

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

Re: [Development] Qt for WebAssembly

[Morten Sørvig]

> On 13 Mar 2018, at 02:15, Jason H  wrote:
> 
>> On 03/12/2018 11:42 PM, Jason H wrote:
>>> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js 
>>> less so. I can't really argue much difference between WebAssembly and 
>>> asm.js though, given asm.js's previous performance claims.
>> 
>> In my experience WebAssembly is much more performant than asmjs, wasm
>> also creates binaries that are at least 10x less huge than asmjs.
> 
> Active Qt was about 12mb IIRC for Tetris or samegame we're not we're still 
> looking at the same sizes. 

The download size for the current build of samegamne.wasm is 4.4mb. (compressed 
with brotli)

Morten

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

Re: [Development] Qt for WebAssembly

[Morten Sørvig]

> On 13 Mar 2018, at 15:27, Svenn-Arne Dragly  wrote:
> 
> I also think Qt for WebAssembly is exciting because it opens up the 
> possibility to show a minimal demo of a full application in the browser. 
> Instead of showing a video of the application on a product page, a small demo 
> with limited features can be presented. Sure, it might not be as fast and 
> doesn't have the same features as the full application (after all, you want 
> to keep the download size to a minimum for the demo), but it will give the 
> user a much better idea of what your application really is like. And the best 
> part is that you can create the demo from the same code base as you used in 
> the full application.

I also see this demo use case as a realistic short/medium term goal, where we 
can provide value for current Qt users.

Morten

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

Re: [Development] Qt for WebAssembly

[Morten Sørvig]

> On 9 Mar 2018, at 13:57, Morten Sørvig <morten.sor...@qt.io> wrote:
> 
> * (No) thread support
> 
>  Wasm and Emscripten do have pthreads support. However this requires 
> SharedArrayBuffer, 
>  which has been disabled in all major browser after recent security incidents.
> 
>  So we are looking to upstream a no-thread configure option, and modules that
>  want to work on the web should support it. It’s still possible to develop 
> with
>  pthreads enabled by enabling SharedArrayBuffer for your browser.


It was pointed out to me that we already have pending patches in this area:

https://codereview.qt-project.org/181112
https://codereview.qt-project.org/180973
https://codereview.qt-project.org/180971
https://codereview.qt-project.org/180972
https://codereview.qt-project.org/177459

I suggest we restore and merge those since we now have an additional use
case in the form of a platform requirement.

(The alternative would be to wait it out - perhaps threading support will be
enabled and stable in all browsers before we get to merge wip/webassembly).

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

[Development] Qt for WebAssembly

[Morten Sørvig]

Hi all,

As you may have noticed work on Qt for WebAssembly is underway. With the
recent updates the wip/webassembly branches are now based on Qt 5.11, which
they will continue to be while we work on bringing up Qt Quick. The tracking
bug for the project is QTBUG-63917 (with subtasks). This is a continuation of
the initial port at https://codereview.qt-project.org/#/c/178543/

I think this may be a good time to discuss how we want to support Qt for
WebAssembly and what direction the project should take. I’ll start out
by describing some recent developments:

* We are targeting WebAssembly using Emscripten as the SDK. The platform plugin
  is implemented (mainly) using the html5.h API from emscripten.

  The platform define is Q_OS_HTML5. We have wip branches for qtbase and
  qtdeclarative. If (minor) adjustments are needed in other modules then
  those could be submitted to the 5.11 branch under the Q_OS_HTML5 define.
  
* Binary sizes: We are using static builds. The minimal Qt demos (QtCore + 
QtGui) come
  out at 2.1M compressed. The SensorTag demo (QtCore + QtGui + QtWidgets + 
QtQuick + QtCharts)
  (as seen on Embedded World) is 6.3M.

  In the end it may be that application assets will contribute significantly to
  the overall application size. We can look into building an asset download
  pipeline using web service workers. 

* Load times: In addition to the network connection this depends on the browser
  wasm implementation, Firefox has recently gotten very fast and can download 
and 
  instantiate the small Qt demos in a couple of seconds.

* Qt Applications as web page components
   
  Qt for WebAssembly draws to a HTML  element. The default Qt html 
template
  makes the canvas cover the entire browser viewport, but any layout is 
possible.
  The size and position of the canvas may very well be outside of the 
applications
  control. Multiple canvases per “process” is possible but not yet supported.

  On the Qt side each canvas corresponds to a QScreen. The application is 
responsible
  for positioning windows on the screen(s). Qt::WindowFullScreen windows fill 
the entire
  canvas area with application content, normal windows get window decorations.

  We provide a Javascript API (qtloader.js) for managing the application 
process.
  (Here we have the luxury of using modern JS features due to the natural 
selection
  of browsers that the wasm requirement provides.)

* Fonts

  We don’t have access to system font files. This means fonts must me embedded 
in
  the application binary or downloaded on demand.

  Exact font style matches with “native” system fonts will probably remain out 
of
  scope, but should still be able to match the font size setting. Page zoom is
  handled via the high-dpi implementation.

* (No) thread support

  Wasm and Emscripten do have pthreads support. However this requires 
SharedArrayBuffer, 
  which has been disabled in all major browser after recent security incidents.

  So we are looking to upstream a no-thread configure option, and modules that
  want to work on the web should support it. It’s still possible to develop with
  pthreads enabled by enabling SharedArrayBuffer for your browser.

  No-thread could be implemented either by removing QThread (and friends), or by
  making QThread::start() a no-op.

* QML interpretation vs compilation

  We’re currently using the QML interpreter, which is working reasonably well
  for development purposes. The end state is to compile to wasm, ahead of time.

  There has been some discussion on whether compilation should be implemented
  before anything is merged to the main Qt branches, or be handled later on.

* Networking

  We are looking there approaches: (not mutually exclusive)

  - A QNetworkAccessManager backend implemented using XMLHttpRequest/Fetch.

This allows making HTTP REST requests back to the origin server, or to 
other servers 
by using CORS.
  
  - A QWebSocket (client) backend implemented using HTML5 WebSocket

This would allow making websocket connections to any server.

  - Using the emscripten sockets implementation and websockify.

This is a tunneling solution where the server runs e.g. websockify and will 
forward
to a pre-determined target. Supports (unix) TCP and UDP sockets, so no work
is needed in Qt.

* QtMultimedia
  
   Very open for contributions :)

Further information including getting started instructions is available on 
QTBUG-63917,
and also or on QTBUG-65198 (platform documentation).

Thanks for reading!
Morten

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

Re: [Development] should 5.12 build on iOS ?

[Morten Sørvig]

> On 28 Dec 2018, at 17:19, Martin Koller  wrote:
> 
> A colleague built 5.12 for iOS but got linker errors:
> 
> Undefined symbols for architecture arm64:
>  "_CGImageDestinationCreateWithData", referenced from:
>  QMacPasteboardMimeTiff::convertFromMime(QString const&, QVariant, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_CGImageDestinationAddImage", referenced from:
>  QMacPasteboardMimeTiff::convertFromMime(QString const&, QVariant, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_CGImageDestinationFinalize", referenced from:
>  QMacPasteboardMimeTiff::convertFromMime(QString const&, QVariant, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_CGImageSourceCreateWithData", referenced from:
>  QMacPasteboardMimeTiff::convertToMime(QString const&, QList, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_kCGImagePropertyPixelWidth", referenced from:
>  QMacPasteboardMimeTiff::convertFromMime(QString const&, QVariant, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_kCGImagePropertyPixelHeight", referenced from:
>  QMacPasteboardMimeTiff::convertFromMime(QString const&, QVariant, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
>  "_CGImageSourceCreateImageAtIndex", referenced from:
>  QMacPasteboardMimeTiff::convertToMime(QString const&, QList, 
> QString) in libQt5ClipboardSupport.a(qmacmime.o)
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> He says it's due to the Cocoa Framework no existing on iOS
> 
> is this known or a problem with our local build ?

Hi,

This *should* work, since the CGImage functions lives in the ImageIO framework, 
which is available on both iOS and macOS, and is included by 
qtbase/src/platformsupport/clipboard/clipboard.pro,

I have not tried a 5.12 iOS build myself though.

Morten





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

[Development] Qt for WebAssembly 5.13

[Morten Sørvig]

Hi all,

Qt for WebAssembly shipped as a tech preview for 5.12, and for 5,13 we want to 
fill in some of the missing pieces, and also make Q_OS_WASM a supported 
platform. Supported here does not mean that everything that does not work today 
will work, but rather that what we claim will work actually will work. And also 
that the Qt Company supports Qt on this platform, like Qt on the other 
platforms.

The planned list of improvements includes:
- Multithreading support (most likely opt-in)
- System clipboard access
- Local file access
- Binary packages
- Platform documentation

This is mostly platform implementation work. We are looking to add new public 
API for the file access part, see https://codereview.qt-project.org/#/c/250462/

And finally a question for this list: What would you like to see be implemented 
for Qt for WebAssembly?

Cheers,
Morten



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

Re: [Development] QTBUG-61258 and Qt3D status

[Morten Sørvig]

Hi,

> On 14 Dec 2018, at 14:07, Massimo Callegari  wrote:

> (also cause of broken video playback on core context QTBUG-51064)

I was able to spend some time looking at the related QTBUG-62694, and:

- The fault appears to be that the implementation in  
AVFVideoFrameRenderer::renderLayerToFBO() uses the native [CARenderer 
rendererWithCGLContext] API, which expects that the caller sets up global 
OpenGL state (projection/modelview matrices). This not supported by the OpenGL 
Core profiles, and given that OpenGL is deprecated on macOS it is unlikely that 
we’ll see a new OpenGL API here.

- There is a Metal replacement API: [CARenderer rendererWithMTLTexture] (macOS 
10.13+). I was not immediately able to get it to work, but we should be able to 
produce both OpenGL textures and QImages from the Metal texture (as required by 
the AVFVideoFrameRenderer API).

So as it stands, QtMultimedia is unfortunately caught up in the OpenGL -> Metal 
transition and does not support OpenGL Core profiles.

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

Re: [Development] Orphan modules

[Morten Sørvig]

> On 12 Sep 2018, at 11:02, Edward Welbourne  wrote:
> 
> Tor Arne Vestbø (12 September 2018 10:25)
>> I think the qtmacextras module should be maintained by the same
>> [maintainer] as macOS, Morten.
> 
> That would depend on - Morten: are you willing to take it on ?

To be honest I assumed that I already was, so that’s a yes :)

Not that there as been much activity on the module. I agree that the best way 
forward is to move it to a deprecated ands/or done state, for the reasons 
outlined earlier in this thread.

Morten

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

Re: [Development] Assistant WebKit/WebEngine support

[Morten Sørvig]

> On 24 Jun 2019, at 22:44, Lars Knoll  wrote:
> 
> 
>> On 24 Jun 2019, at 21:54, Tor Arne Vestbø  wrote:
>> 
>> 
>> 
>>> On 24 Jun 2019, at 14:43, Simon Hausmann  wrote:
>>> 
>>> I have two more numbers to add: Compressed (7z) the download size would 
>>> be around ~44 MB. I measured on Windows with a Qt Creator built with 
>>> WebEngine support and surfed a little through the docs. The memory 
>>> consumption of the web engine process weighed in between 14-20 MB of RAM.
>>> 
>>> So it looks like this AFAICS:
>>> 
>>>   * We would be adding 145 MB of additional disk usage
>>> 
>>>   * We would add ~44 MB to the download size of Qt Creator
>>> 
>>>   * We would eat ~14-20 MB of additional RAM (not quite fair though, 
>>> as we'd have to subtract the QTextDocument memory usage for a diff).
>>> 
>>> 
>>> I don't quite share the opinion that these are "beastly" numbers for 
>>> desktop machines running C++ development environments. I think that they 
>>> are worth it. In exchange we can show external content like cppreference 
>>> or cmake docs without having to worry about their rendering, we can get 
>>> rid of our separate style sheets and workarounds and we can render the 
>>> Qt documentation the same way as on the website. We can eliminate an 
>>> entire class of problems, and we can still prevent such content from 
>>> accessing remote websites.
>>> 
>>> 
>>> We've had this situation for a long time now and I think that we should 
>>> finally move forward and give our users better quality at the expense of 
>>> their disk space, memory consumption and download size.
>>> 
>> 
>> I fully agree with this. Thanks for the numbers Simon!
> 
> Another +1 from me. Let’s stop fighting this. We need something that can 
> properly display any HTML content (and maybe PDF and things as well) that we 
> throw at it.
> 

I’m not sure if it has been mentioned; we have another option which is to use 
the OS web browser component via the Qt WebView module.

The benefits would be

* up-to-date web browser (and someone else keeps it up to date for us)
* insignificant additional download size
* no trouble with restricted platforms where shipping a full web browser is not 
feasible (but then maybe creator isn’t going to run on those platforms, anyway)

QWebView’s platform coverage may be insufficient for Creator, which means

* no html docs on those platforms :(
* or, we expand QWebView platform coverage
* or, QT WebView does have a WebEngine backend

Cheers,
Morten







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

Re: [Development] Qt Static Package

[Morten Sørvig]

We’re successfully building Qt Quick Controls 2 statically for the WebAssembly 
target, so it should be possible. I don’t think we’re doing anything special. 
The test cases include the “gallery” example.

The generated qml_plugin_import.cpp file has the style plugins as well:

   Q_IMPORT_PLUGIN(QtQuickControls2Plugin)
   Q_IMPORT_PLUGIN(QtQuickControls2MaterialStylePlugin)
   Q_IMPORT_PLUGIN(QtQuickControls2UniversalStylePlugin)

Morten

> On 20 Apr 2019, at 02:56, Carlos Enrique Pérez Sánchez 
>  wrote:
> 
> I invited Mitch Curtis to join the discussion. He may have a word on this 
> since he is actively working on the Qt Quick Controls 2 module. Hope he can 
> help us here. Making a working static build of Qt Quick Controls 2 can push 
> forward the release of static packages.
> 
> El vie., 19 abr. 2019 a las 20:31, Carlos Enrique Pérez Sánchez 
> () escribió:
> By the way. I have made no changes to my .pro file after build my static 
> version of Qt. The reason is that the Qt Doc says 
> (https://doc.qt.io/qt-5/plugins-howto.html#static-plugins):
> Plugins can be linked statically into your application. If you build the 
> static version of Qt, this is the only option for including Qt's predefined 
> plugins. Using static plugins makes the deployment less error-prone, but has 
> the disadvantage that no functionality from plugins can be added without a 
> complete rebuild and redistribution of the application.
> To link plugins statically, you need to add the required plugins to your 
> build using QTPLUGIN.
> 
> In the .pro file for your application, you need the following entry:
> 
> 
>   QTPLUGIN += qjpeg \
>qgif \
>qkrcodecs
> 
> qmake automatically adds the plugins to QTPLUGIN that are typically needed by 
> the Qt modules used (see QT), while more specialized plugins need to be added 
> manually.
> 
> So, according with this, I have no need of importing Qt plugind related to Qt 
> Quick Controls 2. Also, I have checked that the qmlimportscanner works 
> appropriatelly. 
> 
> The page Deploying Qt Quick Controls 2 Applications says the following about 
> static linking:
> For dynamically built applications, it is not necessary to import a specific 
> style that should be usable by that application. For statically built 
> applications, Qt's build system must be involved to ensure that QML plugins 
> function as expected. Specifically, qmake uses qmlimportscanner to scan the 
> QML files in your application for import statements. For this reason, any 
> styles that should be usable by a statically built application must 
> explicitly import that style. Where the import occurs is up to the developer, 
> but it is recommended to follow the approach mentioned in the Deploying an 
> Application with Several Styles section, so that only the minimum set of 
> files that are necessary for a particular device are deployed.
> 
> So, they should be built QQC2 statically before (because if not, document 
> that makes no sense) and they says that the only requirement is explicitly 
> importing the style plugin. Sadly, that does not work for me.
> 
> El vie., 19 abr. 2019 a las 19:45, Carlos Enrique Pérez Sánchez 
> () escribió:
> Thanks, Thiago. I will build Qt statically today on Windows, and I will try 
> using the system version. Same with Linux. However, I really don't think that 
> doing that solves the problem with the static linking of QtQuick Controls 2 
> module. Thanks in advance.
> 
> El jue., 18 abr. 2019 a las 23:23, Thiago Macieira 
> () escribió:
> On Friday, 19 April 2019 08:11:41 +08 Carlos Enrique Pérez Sánchez wrote:
> > ```
> > ./configure -prefix "/somePath/Qt512Static" -static -release -opensource
> > -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -fontconfig
> > -qt-xcb -opengl desktop -sql-sqlite -make libs -make tools -nomake examples
> > -nomake tests -skip qtwebengine
> > ```
> 
> Please note the -qt-zlib option and family: if you choose to use the bundled 
> versions from Qt, you'll need to monitor those upstreams for security issues 
> and, if any is found, rebuild your application after applying the fix to the 
> sources bundled in Qt.
> 
> Far better to use -system-zlib and family.
> 
> -- 
> 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

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

[Development] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

Hi all,

We’ve recently merged several patches which improves Qt’s high-DPI support. The 
changes include:

* Support for fractional device pixel ratios (e.g. Windows 150%)
* Support per-screen DPI in more places like QStyle
* Cleanup of configuration API and options.

These fixes applies mostly to the AA_EnableHighDpiScaling type of high-DPI 
support where 
the device independent coordinate system is set up by QtGui. Relevant platforms 
include Windows,
X11, and Android. The new code and and config options are cross-platform 
though; it should be
possible to develop and test on any platform (as long as you are not working on 
platform plugins).

The following is a summary of the most relevant configuration options and API,
ignoring some of the more obscure, and now deprecated options:

* Platform plugins: 

Scale factor computation has been moved to cross-platform code in order to 
support rounding
policy options. Platforms now provide per-screen DPI values and any natively 
applied scale factor:

- QPlatformScreen::logicalBaseDpi()  [new] : the base DPI on the system (e.g. 
96 on Windows, 72 on macOS)
- QPlatformScreen::logicalDpi(): the logical DPI of the screen 
(e.g. 144 on Windows 150%)
- QPlatformScreen::devicePixelRatio()  : the scale factor applied by the 
OS/Windowing system (e.g. 1 or 2)

[QPlatformScreen::pixelDensity() will no longer be called]


* Environment variables for development and testing:

- QT_SCALE_FACTOR  : enables devicePixelRatio scaling in QtGui, 
applies a global scale factor.
- QT_ENABLE_HIGHDPI_SCALING [new]  : enables devicePixelRatio scaling in QtGui; 
applies per-screen
 scale factors computed from on screen DPI.
- QT_FONT_DPI [now x-platform] : overrides the DPI for all screens

QT_FONT_DPI was previously x11 only, and is now cross-platform. 
QT_ENABLE_HIGHDPI_SCALING corresponds to
Qt::AA_EnableHighDpiScaling.


* Scale factor rounding policy

Today, Qt rounds scale factors which can result in mismatched UI sizes. We’ve 
now added API for setting the rounding policy:

- QT_SCALE_FACTOR_ROUNDING_POLICY=Round|Ceil|Floor|RoundPreferFloor|PassThrough
- 
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy)

Where the PassThrough option results in no scale factor rounding, which means 
that the visual UI size
will match font sizes and also the UI sizes of other applications. Note that 
this policy applies only when
computing a scale factor from screen DPI in QtGui; scale factors from 
QPlatformScreen::devicePixelRatio() or
QT_SCALE_FACTOR are used as-is.


* Manual test

tests/manual/highdpi/highdpi —metrics 

This test app displays a summary of the screen/DPI/DPR configuration. Also 
lists relevant
environment variables.


No changes to Qt’s high-dpi support goes without follow-up work, so please
let me know if there are regressions, or contact me if you have questions.

Cheers,
Morten


___
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] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

> On 27 Sep 2019, at 17:04, Thiago Macieira  wrote:
> 
> On Friday, 27 September 2019 03:56:44 PDT Morten Sørvig wrote:
>> Configuring Windows is a good example here: you set the slider to one of
>> 100% - 125% - 150% - 175% - 200% depending on monitor pixel density and
>> viewing distance. There’s then a single value to configure.
> 
> Well, that's a good example: setting a factor, not the absolute value.

Yes, agreed. A factor is better UI than an absolute value. We are talking
about DPI at lest partly for historical reasons: the windows percentage setting
has always been reported as logical DPI by QPlatformScreen::logicalDpi(), and
that has not changed. 

> 
>>> 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.
>> 
>> Yes, we need per-monitor settings (DPI or scale).
> 
> The problem on that one is that you're forcing me to keep a value per each 
> individual monitor I connect to regularly. With the laptop's display panel, 
> that's 4 or 5. Since they are different actual monitors, each has their own 
> DPI value, which is obtained by Qt. And some monitors report wildly incorrect 
> DPI values, like a 27" monitor saying it's 160x90mm in size. So what's the 
> policy for a brand new monitor we connect to (say, a projector in a 
> conference 
> room)? Does it: 
> a) keep the physical one from the monitor? 
> b) use 96x96? 
> c) use one of the other monitor's settings? 
> (hint: a, b and c are wrong)
> 
> Right now, I need exactly two values: the display panel's multiplicative 
> factor of 2 and the external output's multiplicative factor of 2.

Right, I think I see what you are doing now (maybe). But what about non-Qt 
apps? Do
you configure them manually as well?

If this logic could be contained within the XCB platform plugin, and the result
reported to QtGui via QPlatformScreen::logicalDpi(), then I would be happy. 
(And,
setHighDpiScaleFactorRoundingPolicy could work as documented, too).

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] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

> On 16 Sep 2019, at 15:21, Florian Bruhin  wrote:
> 
> Looks like that change didn't add a changelog entry and didn't bother to 
> update
> the documentation at all…

I’ve updated https://wiki.qt.io/New_Features_in_Qt_5.14 . We’ll add similar 
content to the change log once it gets posted.

The documentation (https://doc.qt.io/qt-5/highdpi.html) is in practice 
append-only at this point and needs a ground-up rewrite. I’ve pushed a minimal 
update with the new options here: 
https://codereview.qt-project.org/c/qt/qtdoc/+/275028


(Does anyone want to help updating the high-dpi docs? Let me know.)

Morten
___
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 26 Sep 2019, at 04:48, Thiago Macieira  wrote:
> 
> 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?

We use the default policy: RoundPreferFloor in Qt 5, PassThrough in Qt 6 
(if/when
https://codereview.qt-project.org/c/qt/qtbase/+/273956 lands)

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

Some displays like projectors don’t have well-defined physical DPI though. In
some cases like macOS configured for “more/less space” the relationship between
frame buffer pixels and display pixels is not 1:1, which makes physical DPI less
useful.

The DPI we are using in Qt is the logical DPI; it need not correspond to any
physical measurement of the monitor.

Configuring Windows is a good example here: you set the slider to one of 100% -
125% - 150% - 175% - 200% depending on monitor pixel density and viewing 
distance.
There’s then a single value to configure.


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

Yes, we need per-monitor settings (DPI or scale).


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

I don’t know. That’s the $1M question.

Morten


___
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 3 Oct 2019, at 09:44, Mark De Wit  wrote:
> 
> Is there a chance that the high-dpi work will fix the dpi-awareness of the 
> Fusion theme as reported in https://bugreports.qt.io/browse/QTBUG-74100 ?

Yes, looks like an easy fix: 
https://codereview.qt-project.org/c/qt/qtbase/+/276261

> 
> Last time I checked there was a fair amount of drawing code that didn't check 
> what screen a widget was on, and hence used "global" scaling (if any).

QPainter picks up the correct factor via the paint device, so the 
draw-on-widget case should work without checking the screen. But there might be 
other cases such as painting on a intermediate pixmap which needs fixing.

Morten

> 
> Mark
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Christoph Cullmann
>> Sent: 01 October 2019 22:19
>> To: development@qt-project.org
>> Subject: Re: [Development] Updated high-DPI support for Qt 5.14
>> 
>> Hi,
>> 
>> actually, unrelated to how one can configure the stuff, at the moment, I see
>> still a lot of Qt internal rendering artifacts for fractional scaling.
>> 
>> See https://bugreports.qt.io/browse/QTBUG-66036
>> 
>> For some I made now hacky workarounds in KTextEditor, see
>> https://bugs.kde.org/show_bug.cgi?id=390451
>> 
>> Some still remain for factors like 1.1 and text selections...
>> 
>> And one should think about if it is really a good idea to accept factors 
>> like 1.1
>> and not round them to some at least 1 / 2^x factor that doesn't lead to
>> interesting accumulating rounding errors. (in addition to the opt-out of
>> fractional scaling at all)
>> 
>> Greetings
>> Christoph
>> 
>> --
>> Ignorance is bliss...
>> https://cullmann.io | https://kate-editor.org
>> ___
>> 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] Stepping down as Qt for macOS maintainer (but don't worry)

[Morten Sørvig]

Hello all,

I’d like to formally step down as Qt for macOS maintainer, and suggest that Tor 
Arne Vestbø takes over in my place. He’s already maintaining Qt for iOS (and 
QPA), and has done a lot of good work on macOS over the past couple of years.

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

Re: [Development] Please remove this warning: Warning: QT_AUTO_SCREEN_SCALE_FACTOR is deprecated. Instead use: QT_ENABLE_HIGHDPI_SCALING to enable platform plugin controlled per-screen factors.

[Morten Sørvig]

> On 15 Nov 2019, at 20:54, Thiago Macieira  wrote:
> 
> Just remove it. Make it work with the current settings, despite there being a 
> better way.
> -- 


Yep, this did turn out to be a bit spammy. How about this:

 - QT_AUTO_SCREEN_SCALE_FACTOR is Done on X11, and will continue to work as-is.
 - QT_AUTO_SCREEN_SCALE_FACTOR is Deprecated outside of X11.

We then remove the warning: 
https://codereview.qt-project.org/c/qt/qtbase/+/282055

Morten


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

[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] Updated high-DPI support for Qt 5.14

[Morten Sørvig]

> On 1 Oct 2019, at 23:18, Christoph Cullmann  wrote:
> 
> Hi,
> 
> actually, unrelated to how one can configure the stuff, at the moment,
> I see still a lot of Qt internal rendering artifacts for fractional scaling.
> 
> See https://bugreports.qt.io/browse/QTBUG-66036
> 
> For some I made now hacky workarounds in KTextEditor, see 
> https://bugs.kde.org/show_bug.cgi?id=390451
> 
> Some still remain for factors like 1.1 and text selections...
> 
> And one should think about if it is really a good idea to accept factors like 
> 1.1
> and not round them to some at least 1 / 2^x factor that doesn't lead to 
> interesting
> accumulating rounding errors. (in addition to the opt-out of fractional 
> scaling at all)

I think we can do so, if needed. Which factor, and what is the trade-off 
between a small
or large factor?

Morten


> 
> Greetings
> Christoph
> 
> -- 
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
> ___
> 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] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Morten Sørvig]

> On 27 Jan 2020, at 20:16, Thiago Macieira  wrote:
> 
> I had fixed this prior to 5.13 but the patch was never accepted:
> https://codereview.qt-project.org/c/qt/qtbase/+/188493
> https://bugreports.qt.io/browse/QTBUG-58329
> https://build.opensuse.org/package/view_file/
> home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase/0001-HighDpi-Fix-
> handling-of-the-screen-origin-point.patch?expand=1
> 
> The problem is that Qt is adding device-independent pixels to 
> device-dependent 
> ones when calculating the positions of anything outside the first screen and 
> coming up with nonsense. This can be seen from these lines in qtdiag:
> 
>  Geometry: 1920x1080+3200+0 (native: 3840x2160+3200+0) Available: 
> 1920x1080+3200+0
>  Virtual geometry: 5120x1080+0+0 Available: 5120x1080+0+0

This is by design: the scale factor for screen positions is always 1. So we’re
arguably not mixing coordinate systems here. Is it a design bug? There are 
several
possible solutions:

1) The scale factor for screen positions is 1: [the current choice]
  Simple to implement. Device-independent virtual geometry may now have
  “gaps”, unoccupied by any actual screen. This may come as as surprise
  but is not completely unprecedented: you can create gaps also by arranging
  screens diagonally.

2) The scale factor for screen positions is the screen’s scale factor:
  Simple to implement, but unfortunately completely wrong, as was also concluded
  in qtbase/+/188493. This can cause overlapping screen geometry, if for example
  the position of an 2x screen is moved over an 1x screen closer to the origin.

3) Move the screen positions to create adjacent screens in device-independent 
space.
  Not-simple to implement: as pointed out on qtbase/+/188493 we need to
  implement heuristics which looks at screens closer to the origin. Can we make
  the heuristics accurate enough to support all possible screen configurations?

4) (Something else?)

I've so far been in favor of keeping the simple-and-predictable (once you know 
what’s
going on) 1) solution. However if there is a consensus for a different solution 
we
could start looking into that. I don’t think this will be a patch release type 
change,
though.


> 
> The number 5120 is 1920+3200, but 1920 is a scaled number and 3200 isn't. 
> That 
> means 5120 is a nonsensical result. The end result is that positioning of 
> many 
> things are off.
> 
> I've filed https://bugreports.qt.io/browse/QTBUG-81695, but I'm reporting 
> here 
> because this issue affects kmail majorly in 5.14 and thus makes it VERY 
> difficult for me to work. Please consider this bug a P0.

Something is clearly wrong with the menu positioning for kmail there. We should 
get
to the bottom of that, with P1 priority (not sure about P0 :)

I suggest we continue discussing the menu position bug on QTBUG-81695.

Cheers,
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] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Morten Sørvig]

> On 29 Jan 2020, at 04:14, Thiago Macieira  wrote:
> 
> On Tuesday, 28 January 2020 06:48:53 PST Morten Sørvig wrote:
>> There are several possible solutions:
>> 
>> 1) The scale factor for screen positions is 1: [the current choice]
>>  Simple to implement. Device-independent virtual geometry may now have
>>  “gaps”, unoccupied by any actual screen. This may come as as surprise
>>  but is not completely unprecedented: you can create gaps also by
>> arranging screens diagonally.
> 
> Indeed, there are some conditions that are impossible to implement if you 
> tried to scale differently when three or more monitors are present and not 
> arranged linearly. Like in the case:
> 
>  A   C
>  B
> 
> If A is scaled and B isn't, then where does C start?


Exactly. In my opinion the only workable solution to this is that the 
user (end-user) arranges the screens in device-independent pixel space,
using the dialog provided by the OS/desktop environment.

macOS works this way, Windows doesn’t. I think the linux desktop environments
could work this way when using Wayland, but I’m not sure what actually do.
(The test is; does a 2x screen show up as a very large screen, or not)

If this holds then solving the problem completely is out-of-scope for Qt,
and we can settle on choosing the least-worst workaround.

Morten


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

Re: [Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Morten Sørvig]

> On 14 Feb 2020, at 21:46, Thiago Macieira  wrote:
> 
> On Friday, 14 February 2020 07:18:10 PST Thiago Macieira wrote:
>> On Thursday, 13 February 2020 14:13:52 PST Christoph Cullmann wrote:
>>> I had in Kate/Konsole and Co. broken repainting as soon as winId() was
>>> called
>>> on any non-native widget, see:
>>> 
>>> https://bugs.kde.org/show_bug.cgi?id=411965
>>> 
>>> If this is unrelated, just ignore me ;=)
>> 
>> It's probably very related. Let me see if I can modify one of our examples
>> to cause this problem.
> 
> Confirmed with examples/widgets/mainwindows/sdi.
> 
> This shows *both* issues:
> 1) when you launch ./sdi and use the menu, it shows up in the wrong screen
> 2) when you resize the window to expand, it produces drawing artifacts

Thanks Christoph and Thiago; I can reproduce both issues.

Morten

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

Re: [Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Morten Sørvig]

> On 13 Feb 2020, at 18:53, Thiago Macieira  wrote:
> 
> On Tuesday, 28 January 2020 19:14:50 PST Thiago Macieira wrote:
>> I don't know what makes KMail different. I thought it was the use of a
>> qtwebengine window, but the qtwebengine examples seem to work fine.
>> 
>> My current theory is embedding of X11 content
>> (QWidget::createWindowContainer, use of QWindow::fromWinId, etc.). Which
>> example should I try?
> 
> I can confirm krdc is affected just the same way that KMail and VirtualBox 
> are: it works on screen 1, but fails to repaint on screen 2.
> 
> It's a much simpler application than KMail to debug. I can reproduce this by 
> using it to VNC into my Mac machine or to RDP into my Windows one. The trick 
> must be here somewhere:
> 
> https://github.com/KDE/krdc/tree/master


Thanks, I’ll see if I can get krdc running in a VM here.

Morten


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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Morten Sørvig]

> On 23 Apr 2020, at 11:30, Ville Voutilainen  
> wrote:
> 
> On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
>> 
>> Almost all the time I second your positions, but not this time ;)
>> 
>> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid 
>> of that.
> 
> Indeed. QList causes confusion for the uninitiated that are aware of
> the differences between std::vector and std::list
> (as in Why Do These People Use Lists Everywhere? Why don't they use
> Vectors?). Now we have papered over
> the problem, but the name remains problematic, because QList is not a
> list. In Qt5, QList is sometimes a list,
> sometimes a vector, but in Qt6 it's never a list.

Well at this point and on todays hardware the linked list has become a
very special-purpose container, so it might be reasonable to disambiguate
the other way: “list” is a sequential container but no longer implies “linked”.
It’s not a perfect naming, but we can get away with it :)

QList is our chameleon sequential container whose implementation we can change
to meet new requirements (to a certain degree), now and in the future.

> 
> Switching the QVector implementation over to a type called QList and
> aliasing QVector to that with the intent
> of getting rid of the QVector name seems exactly backwards to me. I
> would think the better approach would
> be to keep dev as it is, and deprecate and eventually remove QList.

QVector, on the other hand, guarantees contiguous storage and also has a place,
like for graphics API as pointed out elsewhere in this thread.

(We should then be careful about adding QList::constData() as public API, since
that will tie down the QList implementation).

- Morten
 


> ___
> 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 6 high-dpi support

[Morten Sørvig]

> 
> P.S. Consider a similar type of "technical debt" being settled by Qt: I'm 
> thinking of the "DPI awareness" setting in 5.14, i.e. for a default widgets 
> program, Qt nowadays tells WIndows that it's "DPI aware" and wants the truth 
> about screen coordinates, even on those portable PCs with high DPIs that have 
> Scale set to 125% or 150%.  On the Qt forum I've seen lot of heat/complaints 
> about QLabels being shoehorned in with the QLineEdits because the fonts are 
> too big for those 125% or 150% screens, I'd answer: create a qt.conf file 
> with the contents:
> [Platforms]
> WindowsArguments = dpiawareness=0
> 
> and your legacy widgets program will go back to display fine, albeit a bit 
> blurry and bloated.
> But! If you're asking (with that qt.conf file present) what the screen size 
> is (e.g. QGuiApplication::screens(0)->geometry() etc.) Windows will lie to 
> you and scale "backwards" so that a normal 2560x1440 screen is reported as 
> "QRect(0,0,1707,960)". So using dpiawareness=0 is a bad long-term solution :-(

We are indeed planning to addreess high-DPI support for Qt 6. You can test the 
implementation on 
Qt 5.14+ today by setting

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);

This should make sure labels and line edits are correctly sized, also for 125% 
and 150%.

Interestingly, Qt will then “lie” about the about the screen size the same way 
that dpiawareness=0
does, although while rendering at the full resolution (so no blurriness).

Morten






> 
> ___
> 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] Windows maintainer change

[Morten Sørvig]

+1 from me as well, and I’d like to thank Friedemann for his work on Qt on 
Windows through the years.

Morten

> On 15 Jun 2021, at 11:13, Tor Arne Vestbø  wrote:
> 
> Hear hear! +1
> 
>> On 15 Jun 2021, at 11:05, Shawn Rutledge  wrote:
>> 
>> +1
>> 
>> Thanks for the work that all 3 of you have put into it over the years.
>> 
>>> On 15 Jun 2021, at 09:27, Oliver Wolff  wrote:
>>> 
>>> Hi all,
>>> 
>>> I would like to propose a change in Qt's Windows maintainership. I think 
>>> that everybody knows, that Friedemann has been doing a great job 
>>> maintaining the Windows platform specifics in Qt's code base. He wants to 
>>> focus on Qt for Python now so we have been looking for an alternative way 
>>> of maintenance.
>>> 
>>> I propose a shared maintenance between Andre de la Rocha and me for 
>>> Windows. Andre has been involved in Qt's Windows development for almost 4 
>>> years now. He is responsible for our accessibility backend on Windows and 
>>> rewrote mouse/touch/pen handling for that platform. He also wrote the 
>>> "win32" bluetooth backend and fixed bugs in various areas of Qt.
>>> 
>>> I have been part of the winrt maintainership and wrote and maintain the 
>>> "winrt" backend for Bluetooth (which is also used in Qt6 as the backend 
>>> also works for "desktop" applications on Windows 10).
>>> 
>>> Thanks again to Friedemann for all the work he put into the maintenance of 
>>> Qt. You have been doing a great job and I hope that we can ask for some 
>>> guidance now and then ;)
>> 
>> ___
>> 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

Re: [Development] Confused about HiDPI scaling and fonts

[Morten Sørvig]

Hello!

(This is mailing list is for discussing development _of_ Qt - 
inter...@qt-project.org is the correct list for Qt usage questions)

The setting looks correct and fonts should be resized. There is no need to set 
QT_ENABLE_HIGHDPI_SCALING on the environment when setting the 
AA_EnableHighDpiScaling app attribute.

It’s a bit hard to say what goes wrong. You could try running qtdiag or 
dprgadget from github.com/msorvig/qt-highdpi-manualtests/tree/master/dprgadget 
and check if the correct device pixel ratio is set. (1.5 for 150% etc.)

- Morten


> On 8 Feb 2021, at 10:17, Thomas Laguzzi  wrote:
> 
> Hello,
> 
> I'm trying to enable QT_ENABLE_HIGHDPI_SCALING=1  in a windows application. 
> It seems to work good in a multi-screen application even with different DPI 
> settings, but it only resizes the widgets.
> The fonts always remain the same size (100% scaling).
> Is there a way to use QT_ENABLE_HIGHDPI_SCALING and automatic font resize? 
> If I have to do manually, how to detect screen changes?
> 
> If I use QT_SCALE_FACTOR  it resizes correctly both the widgets and fonts, 
> but once the application is started it cannot be changed anymore.
> 
> I use something like:
>   qputenv("QT_ENABLE_HIGHDPI_SCALING","1");
>   
> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
> QApplication a(argc, argv);
> MainWindow w;
> w.show();
> 
> thanks for any hint!
> Thomas
> 
> ___
> 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] Confused about HiDPI scaling and fonts

[Morten Sørvig]

It may be easier to show the expected behaviour with a video:

https://www.youtube.com/watch?v=vgGnPTgQqjo

The important thing is that text visual size and window visual size is kept in 
sync as the system DPI changes. From the report I got the impression that this 
was maybe not the case - but that could be a misunderstanding.

From there it's possible to go into the details: there are multiple coordinate 
systems, window and text sizes are (approximately) constant in one coordinate 
system but changes in another. Long discussions can be had :)

But fortunately, Qt apps can for the most part ignore this and continue to 
assume a single coordinate system at 96DPI. 

- Morten


> On 9 Feb 2021, at 18:17, Friedemann Kleint  wrote:
> 
> Hi,
> 
> it seems there is a misunderstanding here: Qt High  DPI scaling preserves the 
>  point-size of the fonts; they are sized according to the system metrics.
> 
> All it does is pretend a lower resolution to the application so that apps 
> written for 96DPI continue to work.
> 
> It is not a means of zooming the application (as opposed to QT_SCALE_FACTOR ).
> 
> Regards, Friedemann
> 
> -- 
> 
> Friedemann Kleint
> The Qt Company GmbH
> 
> ___
> 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] Nominating David Skoland as approver

[Morten Sørvig]

I'd like to nominate David Skoland as approver for the Qt Project.

David is employed by the Qt company has been contributing to Qt since late 
2020, with patches and reviews to several modules. He has recently shifted 
focus to work on Qt for WebAssembly, where he’s already made several good 
contributions and is currently taking on getting auto-tests running in the CI 
system.

I trust him to be a good approver.

https://codereview.qt-project.org/q/owner:david.skoland%2540qt.io
https://codereview.qt-project.org/q/reviewer:david.skoland%2540qt.io

Best Regards,
Morten Sørvig


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

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Morten Sørvig]

On 19 May 2022, at 16:32, Ilya Fedin 
mailto:fedin-ilja2...@ya.ru>> wrote:

On Thu, 19 May 2022 14:20:05 +
Morten Sørvig mailto:morten.sor...@qt.io>> wrote:

Looks inconclusive to me - no clear consensus either way. (I’m also
not sure if it's a bug - it’s just "the current behavior")

However, we might be able to find a way forward: the rounding policy
is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY
environment variable. So users who wants no rounding at all (even for
apps which claim to not support fractional scale factors) can set it
to “Passthrough” to preserve the current behavior.

- Morten

It's a bug as it makes applications that clearly stated they don't
support fractional scaling render incorrectly. The only question what's
the bug: inconsistency in the QT_SCREEN_SCALE_FACTORS behavior or KDE
using wrong way to set the scaling. And the lack of consensus makes
it impossible to fix it on Qt side/report to KDE. :(

As a result, affected applciations are unusable for a long time.

That’s fair point. The QT_ environment variables are often sharp tools, and do 
make it possible to configure Qt in such a way that it appears broken.

I’m not sure I see what KDE could realistically change here - given that they 
want to continue to set QT_SCREEN_SCALE_FACTORS, also with fractional factors 
since that works for most/many apps. Did you have a specific solution in mind?

Continuing on the more pragmatic track, I’ve pushed a change to add rounding 
support, along with some additional testing: 
https://codereview.qt-project.org/c/qt/qtbase/+/412296

Morten


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

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Morten Sørvig]

On 17 May 2022, at 22:14, Ilya Fedin 
mailto:fedin-ilja2...@ya.ru>> wrote:

On Tue, 10 May 2022 19:40:02 +
Morten Sørvig mailto:morten.sor...@qt.io>> wrote:

On 9 May 2022, at 16:47, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:

On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote:
b) In practice, QT_SCREEN_SCALE_FACTORS has become a system
setting since it’s being set on behalf of the user. This means the
values should be subject to rounding according to
highDpiScaleFactorRoundingPolicy property, like with other system
DPI settings.

It it's a system setting, then one should assume it's been set to
the exact value that the system wanted it to be. So if they'd
wanted it rounded, they'd have rounded it.

That is true, however the purpose of highDpiScaleFactorRoundingPolicy
is override the system setting. For example, a Windows display can be
configured for 175%, but the app knows it does not support that and
has enabled rounding (to 200%).

So if QT_SCREEN_SCALE_FACTORS is considered a system setting then
this is an inconsistency in behavior.

So, what's the decision? Is it a bug in Qt or in KDE?

Looks inconclusive to me - no clear consensus either way. (I’m also not sure if 
it's a bug - it’s just "the current behavior")

However, we might be able to find a way forward: the rounding policy is also 
under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY environment 
variable. So users who wants no rounding at all (even for apps which claim to 
not support fractional scale factors) can set it to “Passthrough” to preserve 
the current behavior.

- Morten




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

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Morten Sørvig]

> On 9 May 2022, at 16:47, Thiago Macieira  wrote:
> 
> On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote:
>> b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since
>> it’s being set on behalf of the user. This means the values should be
>> subject to rounding according to highDpiScaleFactorRoundingPolicy property,
>> like with other system DPI settings.
> 
> It it's a system setting, then one should assume it's been set to the exact 
> value that the system wanted it to be. So if they'd wanted it rounded, they'd 
> have rounded it.

That is true, however the purpose of highDpiScaleFactorRoundingPolicy is 
override the system setting. For example, a Windows display can be configured 
for 175%,  but the app knows it does not support that and has enabled rounding 
(to 200%). 

So if QT_SCREEN_SCALE_FACTORS is considered a system setting then this is an 
inconsistency  in behavior.


Regards,
Morten




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

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Morten Sørvig]

On 8 May 2022, at 21:02, Ilya Fedin 
mailto:fedin-ilja2...@ya.ru>> wrote:

9 months has passed since the initial report and it's still in a state
where it's unknown is it a bug or an intended behavior. Would be nice


Thanks for the reminder! This is about the behaviour of the 
QT_SCREEN_SCALE_FACTORS environment variable, and if I recall correctly the 
current consensus there is “keep it working exactly as-is”, so the subject of 
changing its behavior is a good candidate for discussion on this list.

In short, the issue is with how QT_SCREEN_SCALE_FACTORS and 
QGuiApplication::highDpiScaleFactorRoundingPolicy should interact. 
HighDpiScaleFactorRoundingPolicy can be set to either round fractional scale 
factors (1.75 -> 2), like Qt 5 does by default, or to pass them through 
unmodified, like Qt 6 does by default.

As the bug states, QT_SCREEN_SCALE_FACTORS currently ignores this completely 
and there is never any rounding. The options are:

 a) This is intended behavior: Qt’s environment variables empowers users to 
override settings. If the user wants to use rounded scale factors then they can 
set QT_SCREEN_SCALE_FACTORS to a rounded value.

 b) In practice, QT_SCREEN_SCALE_FACTORS has become a system setting since it’s 
being set on behalf of the user. This means the values should be subject to 
rounding according to highDpiScaleFactorRoundingPolicy property, like with 
other system DPI settings.

If we want to change, then we should also consider if we want to do that for 
5.15.x (which I think we can, If we consider it to be a bug-fix).

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

Re: [Development] Introducing: test batching

[Morten Sørvig]

> On 29 Aug 2022, at 13:48, Thiago Macieira  wrote:
> 
> On Monday, 29 August 2022 05:34:48 -03 Mikołaj Boć wrote:
>> We plan to enable the feature on CI for WASM. Since that has not yet been
>> done, breaking the tests unintentionally is possible. With CI on, it will
>> become everyone’s responsibility to keep them running (at least on WASM,
>> which will be checked by the CI). Following the guideline on symbol name
>> duplication will save us a considerable amount of work.
>> 
>> Batching tests for other platforms is an opt-in, please do check whether
>> that would simplify the testing pipeline on the platform you are proficient
>> with.
> 
> I'd recommend you consider enabling that for at least one of the fast 
> platforms that are in the minimal build set of the CI. WASM doesn't appear to 
> be a fast compile, so waiting 2 hours to find out that you've made a mistake 
> is 
> sub-optimal.

This was true until recently, but is now (6.4) only partially true.

Compiling individual translation units runs at the normal speed of clang/llvm, 
also for
the wasm target. Linking can still be slow, in some cases.

llvm links webassembly reasonably fast, on par with static builds on other 
platforms.
Emscripten has an extra wasm rewrite/optimization step which runs any one of 
these 
are true:

   - the WASM_BIGINT option is not set (Qt 6.4 sets it by default)
   - optimizations are enabled (I’m unsure of at which level it kicks in)
   - asyncify is used

This final step is what is causing the slowdown.

The plan for the auto tests is to run them with asyncify enabled, since the Qt 
test suite
makes frequent use of synchronous waitFor() and similar calls. This means 
linking will
be slow, which is why the batched test feature was introduced to incur the 
linking overhead
only a few times for the test suite.

So in the end we hope that wasm CI performance will similar to the other 
platforms,
at least as far as the building step goes. If not, then we can always enable 
batching on
another platform.

- Morten






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

[Development] Fixing the 6.5 build when cross-compiling (missing Qt6::qtprotobufgen)

[Morten Sørvig via Development]

Hi, I’m running into a configure error for a top-level Qt 6.5 wasm build. I use 
“init-repository --module-subset=all” to check out the Qt modules.

The host system does not have protobuf installed, which configure warns me 
about during the host tools build (this is fine):

-- Configuring submodule 'qtgrpc'
-- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Release'
-- [QtGrpc] CMAKE_STRIP (original): 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)

But then, during the target (wasm) build the warning gets upgraded to an error:

-- Configuring submodule 'qtgrpc'
-- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Debug'
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Running syncqt.cpp for module: QtProtobuf
-- [QtGrpc] Searching for tool 'Qt6::qtprotobufgen' in package Qt6ProtobufTools.
-- Could NOT find Qt6ProtobufTools (missing: Qt6ProtobufTools_DIR)
CMake Error at qtbase/cmake/QtToolHelpers.cmake:605 (message):
  Failed to find the host tool "Qt6::qtprotobufgen".  It is part of the
  Qt6ProtobufTools package, but the package could not be found.  Make sure
  you have built and installed the host Protobuf module, which will ensure
  the creation of the Qt6ProtobufTools package.
Call Stack (most recent call first):
  qtbase/cmake/QtToolHelpers.cmake:55 (qt_internal_find_tool)
  qtgrpc/src/tools/qtprotobufgen/CMakeLists.txt:9 (qt_internal_add_tool)


Could we find a different way to handle this where it does not become a 
configure error for the top-level Qt build? Especially if we continue to add 
special-purpose modules it can become difficult to satisfy all host 
requirements for all modules.


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

[Development] Qt for WebAssembly feature freeze exceptions

[Morten Sørvig via Development]

Hi all, 

We have two pending changes for the wasm platform which I'd like to request a 
feature freeze exception for:

* Adding the initial accessibility backend. This feature will initially 
be opt-in, and we are
  aiming to make it as non-disruptive as possible. A couple of details 
remains to be settled
 on the review.

* Updating the SDK to the latest Emcscripten version

(It’s a bit unclear which freeze policy (if any) applies to the SDK update. In 
any case it needs to be done.)

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

[Development] Nominating Mikołaj Boć as approver

[Morten Sørvig via Development]

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

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

Re: [Development] Nominating Mikołaj Boć as approver

[Morten Sørvig via Development]

Hello again,

Correct links to gerrit should be:

https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/owner:Mikolaj.Boc%40qt.io>
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%40qt.io>

(copy/paste error on my part :)

Morten

On 21 Dec 2022, at 15:21, Morten Sørvig via Development 
mailto:development@qt-project.org>> wrote:

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/owner:axel.spoerl%40qt.io>
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%40qt.io>

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

Regards,
Morten
___
Development mailing list
Development@qt-project.org<mailto: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] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid

[Morten Sørvig via Development]

> On 25 Jan 2023, at 14:39, Ilya Fedin  wrote:
> 
> 
> This is a follow-up to the thread I started a year ago. The fix was
> momentally reverted back then leading to me patching Qt all that time. I
> still get reports from users using distribution packages as I obviously
> can't patch their Qt. The application is just unusable for those users
> using KDE's fractional scaling. I believe another attempt to fix this
> should be made, I've re-reported the bug as
> https://bugreports.qt.io/browse/QTBUG-110626.

Thanks for following up!

> I copied the patch I
> proposed in the previous report, why not to take this approach? Unlike
> https://codereview.qt-project.org/c/qt/qtbase/+/412296, it doesn't
> change the setScreenFactor method and shouldn't lead to the problems it
> was reverted due to.

That’s an interesting point, but how does it avoid the problems?

The failing test was tst_QQmlPreview::zoom() (if I remember correctly), which 
sets a screen scale factor and then verifies by reading 
screen.devicePixelRatio. So if any rounding is applied for scale factors like 
1.5 may cause the test to fail.

(The test has other problems, for example macOS applies native scaling which 
will cause screen.devicePixelRatio to differ from the Qt scale factor, so maybe 
it should be rewritten as well)

Morten


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

Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid

[Morten Sørvig via Development]

On 27 Jan 2023, at 18:04, Ilya Fedin  wrote:



My patch doesn't modify setScreenFactor, so the rounding is applied
only to the variable value (and to the property on QScreen object, as
it's the only remaining source without rounding in
QHighDpiScaling::screenSubfactor), so the programmatic calls of
QHighDpiScaling::setScreenFactor are unaffected.

However, it still rounds the value when reading it, and so 
tst_QQmlPreview::zoom() gets
a rounded value and fails. At least that’s what I’m seeing.

Here’s a new attempt: round the value when applying from the env. variable,
outside of setScreenFactor() which now keeps its existing behavior:

https://codereview.qt-project.org/c/qt/qtbase/+/460566

Morten


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

[Development] Nominating Piotr Wierciński for approval status

[Morten Sørvig via Development]

I would like to nominate Piotr Wierciński for approver rights in the Qt project.

Piotr joined the Qt company early 2013 and has since then contributed to Qt for 
WebAssembly. This includes many bugfixes and also larger efforts such as 
getting tests running in the CI system.

Piotr is a pleasure to work with and I trust that he will make a good approver 
for the Qt project.

Changes:  https://codereview.qt-project.org/q/owner:piotr.wiercinski
Reviews:  https://codereview.qt-project.org/q/commentby:piotr.wiercinski 


Best regards,
Morten
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Trouble getting reviews in months and years

[Morten Sørvig via Development]

On Apr 12, 2024, at 11:51, Ilya Fedin  wrote:

On Thu, 11 Apr 2024 10:53:07 +
Morten Sørvig  wrote:

- Should Qt read Gdk settings? Should the XCB platform plugin read
Gdk settings? The current approach is that we stick to X11-level
settings, at least as far as DPI is concerned.

I hope the answer is yes. If it would be no, it would just block this
functionality without any good reason as there's no other API for this
on X11 (at least I'm not aware of).

It is the X11 platform plugin after all - which operates on the X11 level.  
Compare
with something like the gtkplatform plugin [1], which would definitively 
respond to
all GDK settings.

Going to reading private/undocumented GDK settings does look like a significant
change to me. I’m Ok with it if there is a consensus for going in that 
direction (the
patch is at +0 from my side right now).

I see the point about being pragmatic and behaving according to user preferences
though. Which Qt arguably already does to some degree since the text preference
is reflected in the Xft.dpi value.

Should this be up to the application (somehow)? There is more than one way to 
handle
DPI settings on X11, so we could enable apps to make choices which are different
from the Qt default.

- Morten


[1] https://github.com/CrimsonAS/gtkplatform


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

Re: [Development] Trouble getting reviews in months and years

[Morten Sørvig via Development]

Hello Ilya!

> On Apr 9, 2024, at 00:17, Ilya Fedin  wrote:
> 
> 
> 2. https://codereview.qt-project.org/c/qt/qtbase/+/444859 which is 1.5
> years old and no review
> 

This one could be candidate for discussion on the mailing list. There are two 
issues:

- Should Qt read Gdk settings? Should the XCB platform plugin read Gdk settings?
The current approach is that we stick to X11-level settings, at least as far as 
DPI is concerned.

- Should Qt support DPI-based text scaling? With Qt 6 we moved to uniform
scaling where the scale factor is applied to all UI elements. I think several
operating systems provide a “larger text” setting in some form, so this is 
something
we could look into if there is interest. But we have to make sure this does not
result in broken UI (clipped text etc), so I don’t think we should jump directly
to enabling it by default.

All in all I don’t think I’ll +2 this change as it stands.

> 
> 6. https://codereview.qt-project.org/c/qt/qtbase/+/519479 
> 
> 8. https://codereview.qt-project.org/c/qt/qtbase/+/528953 


These are of the “need to get around to it” category for my part. Adding new 
public
API can take a lot of time/effort. For 528953 we need to make sure we are not 
regressing
other platforms, and I have at least one related bug I’d like to take a look at 
at the
same time.

While we are on the topic - should we adopt a more structured approach to env 
variables
like QT_WIDGETS_HIGHDPI_DOWNSCALE? 

qputenv("QT_WIDGETS_HIGHDPI_DOWNSCALE", "1”) is the go-to approach for enabling
from application code, but as pointed out in 519479 that has the problem that 
the setting
is propagated to child processes, for example via QDesktopServices::openUrl(). 

This could be fixed by always having a corresponding “_q_foo” application 
attribute (or similar),
which would put environment variable users and source code users on equal 
footing.

- Morten


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