Re: [Interest] Qt uses fontconfig on Linux, but what about Windows?

[Allan Sandfeld Jensen]

On Montag, 18. Dezember 2023 05:14:38 CET Thomas Larsen Wessel wrote:
> Thanks :) In case others will be looking / googling for this, I will try to
> share what I found out in the meantime. Please correct me where I am wrong
> 
> :)
> 
> At first I thought fontconfig was more of a software library that should
> serve as an intermediate layer between OS and whatever piece of software
> one might build (in Qt or not). I thought it would serve as an abstraction
> so that I could query / access (and maybe even install) fonts on the OS, no
> matter if the OS is Windows, Linux, etc.
> 
> I think fontconfig is more like a service that is installed independently
> (ie not something that comes bundled with a piece of software that one
> installs) on the OS. It happens to be installed by default on at least most
> Linux distributions (and maybe also on FreeBSD? MacOS?). It is possible to
> install fontconfig on Windows (or at least it was at some point in the
> past), but it is generally not a used or recommended solution. If one
> Googles for this, the results are old and sparse.
> 
Fontconfig is a full fontdatabase system. It searches for and implements 
queries for fonts.  macOS and Windows already have system services for this, 
Linux does not, which makes fontconfig  the default. For Qt though we also 
have a system where Qt itself searches defined directories without fontconfig, 
but I think that is only for embedded Linux systems, or for applications that 
bundles their own fonts.

If you look in src/gui/text you can in new qt versions see multiple subdirs, 
coretext, freetype, unix and windows. They contain implementation of the Qt 
fontengine backends and fontdatabase backends. In the unix subdir is the 
fontconfig fontdatabaes backend, whiile coretext and windows dirs contain both 
fontengine and fontdatabse backends for the respective platforms.


> 
> So in short, if I want to find a generic way of getting / querying /
> installing fonts across OS'es (including Windows), fontconfig is probably
> not the way to go, though it may technically be possible.
> 
Yeah, that is complicated. I think you can do it with Qt APIs, but I wouldn't 
know how myself.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt uses fontconfig on Linux, but what about Windows?

[Allan Sandfeld Jensen]

On Samstag, 16. Dezember 2023 15:58:00 CET Thomas Larsen Wessel wrote:
> Quote from https://doc.qt.io/qt-6/qt-embedded-fonts.html:
> 
> *Qt normally uses fontconfig to provide access to system fonts*. If
> 
> > fontconfig is not available, e.g. in dedicated embedded systems where
> > space
> > is at a premium, Qt will fall back to using QBasicFontDatabase. In this
> > case, Qt applications will look for fonts in Qt's lib/fonts/ directory. Qt
> > will automatically detect prerendered fonts and TrueType fonts.
> 
> When a Qt application is running on Windows, does it also rely on
> fontconfig?


No, it uses Windowsø font system.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtCreator new C++ formatting is not good sometimes...

[Allan Sandfeld Jensen]

On Montag, 26. Juni 2023 18:11:55 CEST Alexander Dyagilev wrote:
> Hello,
> 
> Let's suppose I have this:
> 
> I always prefer a base class to be specified on the second line.
> 
> In older versions if I press Enter I was getting something like this:
> 
> Now I'm getting this:
> 
> This is neither nice nor practical...

You might get better result if you hit enter before the colon because that 
would me more 'Qt' style; but yes, the new behavior looks pointless - I would 
open a bug.

'Allan




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 6.5 Is Irrelevant...

[Allan Sandfeld Jensen]

On Montag, 19. Dezember 2022 16:59:41 CET Michael Jackson wrote:
> So not really a “jolt every 3 years”. You have had 3 _total_ jolts over the
> course of 30 years.
> 
Except them dropping support for pre-AVX, pre-AVX2 CPUs, constantly dropping 
support for GPUs older than 4 years all the bloody time with new software 
releases.

Apple is not good at maintaining backwards compatibility on the computer 
front, even if their 4-5 year support is the best of the best for phones, it 
is the worst of the worst in laptops and desktops.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Scripting within Qt6 and QJSEngine

[Allan Sandfeld Jensen]

On Mittwoch, 5. Oktober 2022 09:28:19 CEST Christian Kandeler via Interest 
wrote:
> On 9/26/22 17:47, Filippo Rusconi via Interest wrote:
> > Greetings,
> > my C++ software program (GUI) was scriptable using the QtScript module
> > of Qt5.
> > 
> > I now would like to build it using Qt6 and to take the opportunity of
> > the port
> > to transition towards QJSEngine (QtScript is being deprecated).
> > 
> > I searched around for a tutorial about converting a QtScript project to
> > QJSEngine but failed to find any.
> > 
> > For example, I was looking for the new class that would replace the
> > QScriptClass
> > class.
> > Are there any lessons about transitioning from QtScript to QJSEngine
> > that I
> > might have overlooked?
> 
> It's not a drop-in replacement. In particular, as far as I know, there's
> no QScriptClass equivalent.
> 
> See also https://bugreports.qt.io/browse/QTBUG-45248.
> 
I believe I worked around that by creating the array/object with JS and then 
filling it. Same with injecting function objects, you insert an object with a 
method, then use that method name as the function. Not the best looking but 
workingas replacements.

Best regards
Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] webenginewidgets (Win MinGw11.2.0)

[Allan Sandfeld Jensen]

On Mittwoch, 18. Mai 2022 08:58:20 CEST Alexander Carôt wrote:
> >>MinGW is unsupported in qtwebengine in the sense it doesn't work at all.
> 
> Understood – I wonder what would be required in order to make it support
> qtwebengine. It sounds not to be trivial.
> 
Well, technically it might not be that hard. It has just not been attempted. 
The code is already compilable with gcc, so most C++ code would be relatively 
fine, but there are many paths in the custom Chromium build system GN, which 
sets up MSVC/clang-cl switches for building on Windows, and they would all 
need to be fixed. 

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] webenginewidgets (Win MinGw11.2.0)

[Allan Sandfeld Jensen]

On Dienstag, 17. Mai 2022 18:47:03 CEST Thiago Macieira wrote:
> On Tuesday, 17 May 2022 01:33:16 PDT Allan Sandfeld Jensen wrote:
> > It is not supported for MinGW. Only MSVC, and clang-cl on windows.
> 
> And clang-cl is not supported for qtbase.

Not officially perhaps, but it works. MinGW is unsupported in qtwebengine in 
the sense it doesn't work at all.


Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] webenginewidgets (Win MinGw11.2.0)

[Allan Sandfeld Jensen]

On Dienstag, 17. Mai 2022 07:55:41 CEST Alexander Carôt wrote:
> Hello all,
> 
> after success on OSX I am now trying to get my code working with Windows
> (MinGw11.2.0).
> 
> I installed Qt6.3 including any other additional library but qmake tells me:
> 
> Project ERROR: Unknown module(s) in QT: webenginewidgets
> 
> Is it maybe not supported for MinGw or am I missing something else ?
> 
It is not supported for MinGW. Only MSVC, and clang-cl on windows.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qtwebbroser questions

[Allan Sandfeld Jensen]

On Montag, 11. April 2022 11:48:09 CEST Alexander Carôt wrote:
> Hej Allan,
> 
> thanks for the reply !
> 
> >> If you want a browser based on QtWebEngine I can recommend Falkon or
> >> Qutebrowser
> 
> Theoretically this is the best choice, however, I need to be on Qt6 and they
> all still seem to be Qt5 based, right ?
> 
I believe qutebrowser has a qt6 branch, but yeah none of them are done porting 
yet.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtWebEngine missing in Qt6.2.4 ?

[Allan Sandfeld Jensen]

On Freitag, 8. April 2022 16:38:51 CEST Sze Howe Koh wrote:
> It is now "QT += webenginequick" (in contrast to "QT +=
> webenginewidgets"):
> https://doc.qt.io/qt-6/qtwebenginequick-module.html
> 
> This is a kind of source compatibility break; it would be nice if
> there were deprecation warnings instead of an outright error.
> 
Not sure we can do that with qmake or most other build systems :/

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Reasons why deleteLater() might not work

[Allan Sandfeld Jensen]

On Freitag, 1. April 2022 15:17:59 CEST Michael Jackson wrote:
> I have a bit of code where in I am removing a QWidget from the UI and it
> needs to be truly cleaned up as its parent QObject is also being cleaned
> up. I thought I did the appropriate:
> 
> layout->removeWidget(widget);
> widget->setParent(nullptr);
> widget->deleteLater();
> 
> I put a "std::cout <<... " in the widget's destructor but I never see it
> printed. I put a break point in the destructor and the break point never
> gets hit. Looked around on the internet, various forums, double checked
> that the event loop is actually running, called
> qtapp->eventLoop()->processEvents() (or whatever that bit of code is) a few
> times. Nothing. Currently we are leaking memory because we are creating the
> widget but never deleting the widget when it is removed from the UI. I'll
> assume since I have complete control of the UI that the event loop is
> running. The last line in our main() is app.exec(); so I am assuming the
> event loop is running. This was originally with a self-built Qt 5.15.2 on
> macOS 10.15 (Catalina) but I installed the normal Qt 5.15.2 from www.qt.io
> and it behaves the same way. I have other applications where this does
> actually work so I am trying to figure out where in this new version of the
> application we messed up. If anyone has any thoughts on where to look I
> would really appreciate the sanity check.
> 
> If we are in the middle of a signal being fired would that stop the
> deleteLater() from working? Do I need to manually disconnect all
> signals/slots for deleteLater() to work? We have a mix of new style
> connects and old style connects? Is that messing with deleteLater()? --
> Mike Jackson
> 
> 
You have to make sure the event loop is running on the thread owning the 
QObject. Do you have more than one thread?

And remember that std::cout needs a std::endl to flush and print anything. I 
normally use qDebug() or qWarning() instead as a safer logging tool, since I 
often forget the std::endl myself.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Build Issues with QT 6.2.3

[Allan Sandfeld Jensen]

On Sonntag, 6. Februar 2022 00:15:54 CET BeneschTech LLC wrote:
> OS: Ubuntu 20.04 LTS
> Compiler Suite: clang 15 (from git)
> 
> In the webengine build, a file fails because of -Werror.  Maybe we need to
> take that off of the build flags?
> 
Did you build with the warning-are-errors feature flag on, or did this come in 
anyway with the feature off?

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What's up with Qt's graphic stack (6.2.1) (and WebEngine)?

[Allan Sandfeld Jensen]

On Mittwoch, 24. November 2021 18:40:07 CET Nils Jeisecke wrote:
> Hi Allan,
> 
> > We are planning to do that, but it is somewhat complicated. The
> > QQuickWidget we use, only support OpenGL and Software in Qt 6.2, and
> > there is no other QRHIWidget available or planned. We will be trying with
> > a QWindow approach for 6.3 or 6.4.
> 
> I see. Could you elaborate on the relation between QtQuick's
> WebEngineView component and QQuickWidget? How does QQuickWidget come
> into play when WebEngineView is an object in a QtQuick scene inside a
> QQuickWindow? Just curious ;-)
> 
A QWebEngineView shows page content using QQuickWidgets. 

> >Perhaps we can run QtWebEngine under ANGLE and the rest of Qt under D3D
> 
> I assume the same problem exists with macOS/metal and Linux/Vulkan or
> any non-GL combination. Looks like a quite heavy task, indeed.
> 
Yes. Funny enough Vulkan is the easyist of the three. And we can make it work 
at least for the QML api easy enough, but it hits the limitations of 
QQuickWidget for the QtWidgets API.

Best regards
Allan




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What's up with Qt's graphic stack (6.2.1) (and WebEngine)?

[Allan Sandfeld Jensen]

On Mittwoch, 24. November 2021 12:24:23 CET Nils Jeisecke wrote:
> Thanks for your response Allan.
> 
> On Tue, Nov 23, 2021 at 4:28 PM Allan Sandfeld Jensen  
wrote:
> > We only support two backends in WebEngine currently, either WGL OpenGL or
> > the software backend. The software backend should work just fine though.
> > If you have any other QSG backend than OpenGL, it should automatically be
> > used, but you can also force it by selecting the software QSG backend or
> > using the chromium flag --disable-gpu.
> 
> Looks like overriding the renderer with
> QQuickWindow::setGraphicsApi(QSGRendererInterface::Software) *after*
> calling QtWebEngineQuick::initialize() seems to activate software
> rendering in Chromium. However, performance with Video (JITSI in my
> use case) is subpar :-( Any plans to enable Hardware Acceleration in
> Chromium with the "native" RHI backends (D3D11, metal)? Or is this
> technically imbossible (due to Chromium limitations)?
> 
We are planning to do that, but it is somewhat complicated. The QQuickWidget 
we use, only support OpenGL and Software in Qt 6.2, and there is no other 
QRHIWidget available or planned. We will be trying with a QWindow approach for 
6.3 or 6.4.

Another issue is that Chrome itself is still using OpenGL, on Windows using 
ANGLE, which Qt removed support for :/ 

Perhaps we can run QtWebEngine under ANGLE and the rest of Qt under D3D, but 
it is still at a research stage, and we are low on manpower.

So it is definitely something we would like to get working, but there are many 
pieces not fitting together at the moment.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What's up with Qt's graphic stack (6.2.1) (and WebEngine)?

[Allan Sandfeld Jensen]

On Dienstag, 23. November 2021 14:53:30 CET Nils Jeisecke via Interest wrote:
> Hi list,
> 
> while checking out the status of Qt's graphics stack with very basic
> QtQuick based applications I've made the following observations:
> 
> 1. Windows 10 in VMWare Fusion: No window content is rendered for a
> trivial QtQuick Hello World application. Running with
> QT_D3D_ADAPTER_INDEX=1 helps, but this seems to activate the WARP
> software renderer (QTBUG-78648).
> 
> 2. Any QtQuick application using WebEngineView (QtWebEngineQuick) will
> automatically select OpenGLRhi backend
> (678076faeabd7e827abe31f72f4220af8d8f95ac):
> QtWebEngineQuick::initialize does
> QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGLRhi);
> 
> I've not found this restriction to be documented. OpenGL is not
> available by default on Windows and drivers are notoriously bad.
> RHI/D3D11 was supposed to be the solution for this, wasn't it?
> 
> Software Rendering is no longer an option since Chromium dropped the
> old composer codepath (QTBUG-88695), at least if video rendering is
> required.
> 
> So is it possible at all to build a QtQuick application that is
> * running out-of-the-box in VMWare (Fusion) without relying on the
> hack to select WARP?
> * using hardware accelerated Chromium on Windows without OpenGL?
> 
We only support two backends in WebEngine currently, either WGL OpenGL or the 
software backend. The software backend should work just fine though. If you 
have any other QSG backend than OpenGL, it should automatically be used, but 
you can also force it by selecting the software QSG backend or using the 
chromium flag --disable-gpu.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] bulding Qt from git

[Allan Sandfeld Jensen]

On Montag, 25. Oktober 2021 17:27:38 CEST Alexander Carôt wrote:
> Final three conclusions of this resolved thread:
>  
> 1.) I learned that the dev branch is not necessarily stable. In this case Qt
> staff is working on qtpositioning and when trying to build the dev branch
> one needs to -skip qtpositioning in the confguation process. 
> 2.) cmake config messages are misleading and/or probably wrong:
> 2.1) Qt is now configured for building. Just run 'cmake --build .
> --parallel'   shows up even when errors have occurred
> 
> 2.2) configuration errors should be detected right from the immediate
> terminal output and not from CMakeError.log or CMakeOutput.log.   
> 3.) The last issue regarding "bad CPU type" occurred due to using another
> (outdated) Python installation on my machine – after removal it used the
> up2date Phython version and eventually compiled fine. 
> Thanks again to anyone who contributed,
> best
>  
Also you might get better results not using a top-level build, but instead 
build each module individually. That is how the CI runs and thus less likely 
to break.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Ashamed bug :)

[Allan Sandfeld Jensen]

On Samstag, 4. September 2021 09:23:45 CEST Ilya Diallo wrote:
> Le sam. 4 sept. 2021 à 00:14, Thiago Macieira  a
> 
> écrit :
> > On Friday, 3 September 2021 14:04:01 PDT David M. Cotter wrote:
> > > there's also the rather daunting barrier to entry for folks who COULD
> > > fix
> > > it:
> > > 
> > > getting the qt sources on your local computer, getting them to compile,
> > > getting your project to use the build libraries for testing, getting it
> > 
> > all
> > 
> > > connected to git so you can submit changes, actually submitting
> > 
> > changes...
> > 
> > > the above "simple" things are in fact very, very difficult if you've
> > 
> > never
> > 
> > > done it before. even for an expert.
> > 
> > You also forgot the need to write unit tests.
> > 
> > You're proving my point. It's not easy. If it were, anyone could do it.
> 
> He's not proving your point, he's describing the barrier to entry for a
> newcomer. The actual bug fix can be easy nonetheless.
> 
Compiling, writing tests, and testing takes time for experienced developers as 
well. Especially in a new module you haven't worked on before/recently, but 
also a few hours for those already familiar with the code. For a power user 
already familiar with the problem and having found the right part of the code, 
it might be almost as fast. This was actually how I originally got into Open 
Source in the first place :) 

Plus it makes for great demonstrations in CVs if you are a developer, and Qt's 
users usually are.

Regards
Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 6.2 vs. Qt 5.15 – The Feature Parity Comparison – QtPDF

[Allan Sandfeld Jensen]

On Freitag, 3. September 2021 09:52:04 CEST Heiko Gerdau wrote:
> Am 02.09.21 um 15:14 schrieb Benjamin TERRIER:
> > Hi
> > 
> > I just went through the latest news article:
> > https://www.qt.io/blog/qt-6.2-vs.-qt-5.15-the-feature-parity-comparison
> > 
> > 
> > And the linked feature comparison table:
> > https://www.qt.io/product/qt6/qt-5-15-vs-6-2-feature-comparison
> > 
> > 
> > And it states this about Qt PDF:
> > Due to its limited adoption in Qt 5, we are still studying whether
> > to port this add-on module to Qt 6. Please let us know whether and
> > how you are using this module. Existing projects can pull the
> > relevant code from the 5.15 branch into their project.
> > 
> > Qt PDF was added in Qt 5.14, so it has only been there since 2 minor
> > versions of Qt 5.
> > Since then we also had 2 minor versions of Qt 6 without this module.
> > Also the module was stripped from the open source online installer, and
> > open source users had to build it themselves or buy a $50 license on Qt
> > marketplace.
> > 
> > Given all of this I find weird to use Qt PDF adoption as an excuse for
> > dropping it. It basically never had a chance.
> > 
> > Regards
> > Benjamin
> 
> Hi,
> 
> I agree. Maybe it needs some promotion. QtPdf is a really nice module.
> It works on the desktop and with qml. We use it in both worlds and up to
> now we waited for that port to be able to move on to Qt6. Now I'm worried.
> Why is it so hard to keep it in Qt6? As far as I know it wasn't changed
> much since its birth in Qt5. It just works.
> How is the adoption measured? Downloads?
> Our main usecase is the quick display of stored external (and selfmade)
> PDF-documents without the need to start an external application. Is that
> so uncommon?
> 
It isn't removed really removed in Qt6. In Qt5 it was just a technical 
preview. You can build it for Qt 6.2 if you want to, but it is off by default 
since an API review hasn't been done. The maintainer just haven't had time.
Currently it is build by default in dev/6.3 but we waiting on feedback from 
the maintainer if we should leave it on.

Best regards
Allan




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Configuring Qt's built-in freetype ?

[Allan Sandfeld Jensen]

On Donnerstag, 26. August 2021 13:36:42 CEST Jean-Michaël Celerier wrote:
> Hi,
> 
> for consistency, I am shipping my app with freetype on all platforms.
> This looks "correct", definitely better than using macOS or Win32's font
> rendering, but ! Qt's built-in freetype does not look as good than my Linux
> system's finely-tuned freetype configuration which prompted some
> investigation.
> 
> It's very visible for instance in the menu bar:
> * Top one is my system freetype, notice how the fonts are crispy and
> beautiful.
> * Below one is using Qt's -qt-freetype: notice how the straight lines, like
> for the "t" in settings or the vertical bars in H are blurry.
> [image: here.png]
> 
> If you zoom you'll notice that the one below is missing sub-pixel AA:
> 
> [image: here-small.png]
> Thus my question: is there a way (even if that implies rebuilding Qt) to
> pass configuration options to freetype ? Surely that must be possible as
> it's able to do the correct thing with my distro (arch btw)'s Qt / freetype
> / fontconfig combo.
> 

Looks like your distro did something that enabled subpixel rendering. Maybe 
the old patented hinting algorithms?

You might get more consistent results if you use slight hinting.

Best regards
Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QJsonDocument::fromVariant failing with list

[Allan Sandfeld Jensen]

On Dienstag, 8. Juni 2021 23:47:50 CEST Thiago Macieira wrote:
> On Tuesday, 8 June 2021 13:57:53 PDT Jason H wrote:
> > Which is neiher what I acually had but performs the same bad conversion as
> > what I had. I am not sure why the QVariantList vs QList have different
> > fidelity - the one with more fidelity - QList - actually has has less
> > specificity.
> 
> Because that's how C++ works.
> 
> QList is not a type, it's a template. Neither QVariant nor QJsonDocument can
> know all possible QList instantiations. So they have coded only a few
> (QVariantList and QStringList only, possibly QVector and
> QVector in Qt 5 too, I don't remember).

I guess our system could detect QList as QVariantList and 
QList as QStringList. They should be binary identical anyway.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Futur of Qt Webengine in Qt 6

[Allan Sandfeld Jensen]

On Mittwoch, 14. April 2021 13:00:01 CEST Frank Hemer wrote:
> On Montag, 12. April 2021 17:35:43 CEST Allan Sandfeld Jensen wrote:
> > On Montag, 12. April 2021 13:20:36 CEST Frank Hemer wrote:
> > > Hi all,
> > > 
> > > i wonder what are the plans for Qt Webengine in Qt 6.
> > > 
> > > While webkit has been removed and replaced by webengine, there is still
> > > no
> > > replacement supported by the mingw compiler yet.
> > > As a commercial customer it was disappointing enought this happened
> > > within
> > > a minor release but even more to be told (by commercial support) that
> > > there currently is no replacement available - and no schedule for a
> > > replacement.
> > > 
> > > Does this mean we have to go back in time using com interfaces or are
> > > there
> > > other plans on this?
> > 
> > The plans for Qt WebEngine in Qt 6 does not include support for mingw. But
> > like Qt 5 we do support building with clang-cl, if you only need to avoid
> > MSVC.
> 
> Hmm - regarding qt5, webengine-platform-notes tells me vs2017 version 15.8
> or later is required.
> So i can't go w/o msvc, can i?
> 
Clang-cl uses the msvc standard library, but not the compiler itself. Perhaps 
we need to update the platform-notes.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Futur of Qt Webengine in Qt 6

[Allan Sandfeld Jensen]

On Montag, 12. April 2021 13:20:36 CEST Frank Hemer wrote:
> Hi all,
> 
> i wonder what are the plans for Qt Webengine in Qt 6.
> 
> While webkit has been removed and replaced by webengine, there is still no
> replacement supported by the mingw compiler yet.
> As a commercial customer it was disappointing enought this happened within a
> minor release but even more to be told (by commercial support) that there
> currently is no replacement available - and no schedule for a replacement.
> 
> Does this mean we have to go back in time using com interfaces or are there
> other plans on this?
> 
The plans for Qt WebEngine in Qt 6 does not include support for mingw. But 
like Qt 5 we do support building with clang-cl, if you only need to avoid 
MSVC.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Allan Sandfeld Jensen]

On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:
> On 3/22/21 4:07 AM, Bernhard Lindner wrote:
> >> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> >> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> >> customers-leaving
> > 
> > I wonder if the loss of confidence in the current Qt owners can ever be
> > compensated.
> > 
> > Even if TQC took back their critical decisions, I can't imagine that
> > people would ever trust them again. This could cause fatal damage to Qt
> > in the long run if they don't sell it to someone more responsible.
> 
> Dude,
> 
> Comcast, TimeWarner, and all of those other set-top box vendors formed
> an OpenSource project to create RDK so they could kick Qt to the curb.
> 
That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt WebEngine 5.15.3 tag

[Allan Sandfeld Jensen]

On Donnerstag, 4. März 2021 15:16:27 CET Benjamin TERRIER wrote:
> Hi,
> 
> Given that the Qt WebEngine module is an exception to the commercial only
> LTS support,
> could we have v5.15.3 tags for https://code.qt.io/cgit/qt/qtwebengine.git/
> and https://code.qt.io/cgit/qt/qtwebengine-chromium.git/ ?
> 
Just use the 5.15.3 branch in qtwebengine and git submodule update to get the 
right submodule sha, though at the moment that matches the head of 87-based.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] qmake bug. Any workaround?

[Allan Sandfeld Jensen]

On Freitag, 15. Januar 2021 15:54:25 CET Alexander Dyagilev wrote:
> Hello,
> 
> I am trying to create a .pro file to compile Microsoft Detours lib.
> 
> Failed, it generates linker error:
> 
> detours.obj:-1: error: LNK2019: unresolved external symbol
> DetourCopyInstruction referenced in function DetourAttachEx
> 
> This function is defined in disasm.cpp in case there are no special
> defines existing.
> 
> But, there are disolarm.cpp disolarm64.cpp disolia64.cpp disolx64.cpp
> disolx86.cpp sources which defines platform-depended definitions and
> then includes this disasm.cpp.
> 
> E.g. disolarm.cpp contains of only these 2 lines of code:
> #define DETOURS_ARM_OFFLINE_LIBRARY
> #include "disasm.cpp"
> 
> In this case disasm.cpp defines DetourCopyInstructionARM instead of
> DetourCopyInstruction.
> 
> Qmake has the bug (https://bugreports.qt.io/browse/QTBUG-24906) which
> causes qmake to DROP disasm.cpp from SOURCES because it's included in
> these source files . Thus plain DetourCopyInstruction is not defined
> anywhere.
> 
> If I replace #include "disasm.cpp" lines with file's content, all works
> fine. But this is not a workaround I want.
> 
Rename disarm.cpp to a header file, and include that in two different source 
files?

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 6.0 removed Xml Patterns

[Allan Sandfeld Jensen]

On Freitag, 11. Dezember 2020 10:53:03 CET Robert Hairgrove wrote:
> I cannot seem to find any articles about QXmlPatterns which would
> explain WHY this very useful module was deprecated in 5.13 (or 5.15?),
> then removed in 6.0?
> 
> Is it a licensing issue?
> 
No, it was just unmaintained. I think libxslt is the recommended replacement, 
though perhaps there are better C++ APIs out there.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[Allan Sandfeld Jensen]

On Donnerstag, 10. Dezember 2020 01:50:41 CET Sze Howe Koh wrote:
> On Wed, 9 Dec 2020 at 20:48, Tor Arne Vestbø  wrote:
> > > On 9 Dec 2020, at 13:16, Tor Arne Vestbø  wrote:
> > > 
> > > Hi Benjamin,
> > > 
> > > Qt 5 will officially support macOS 11 in upcoming 5.15 and 5.12 patch
> > > releases, but should work fine already. If you encounter issues with
> > > the current releases (or preferably after building from git), please
> > > let us know by filing bug reports. Thanks!> 
> > Correction, 5.15, not 5.12.
> > 
> > Cheers,
> > Tor Arne
> 
> Hi Tor Arne,
> 
> To clarify: Qt 5.15 will continue to receive patch releases under the
> open source licenses until all the planned Qt 5 add-on modules are
> migrated/supported in Qt 6, right?
> 
Patch releases during the LTS part of Qt 5.15's life will be opensourced a 
year after their release. With the exception of security fixes, and the entire 
module of QtWebEngine, which will remain open throughout.

Don't know about the other postponed modules, I don't think any exceptions has 
been made for them so far. You should direct such question at Qt management.

Best regards
Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Will a Qt 5.x release support macOS 11?

[Allan Sandfeld Jensen]

On Mittwoch, 9. Dezember 2020 08:07:45 CET Ben Haller via Interest wrote:
> Hi all.  Just wondering whether there is any plan for any Qt 5.x release to
> support macOS 11.  At present, Qt 5.15 supports only through macOS 10.15
> (https://doc.qt.io/qt-5/macos.html#supported-versions), as far as I can
> tell, and my app built on macOS 10.15 apparently does not run properly on
> macOS 11 (so my users inform me).  Since it looks like it will be a little
> while before a Qt 6 release is really solid (I just saw on the list that
> the first LTS release of Qt 6 is expected in September 2021, almost a year
> from now), it would be really nice if macOS 11 were added to the list of
> supported releases for 5.15.  Any chance of that?  I have users who are
> already on macOS 11 now; I’d like to have a better story for them.  Thanks
> for any info!
> 
I can't say anything for the company at this point, but at least report any 
issues you encounter in JIRA.

Builds so far seems to work, though the build process does warn about building 
for an unsupported version.

Best regards
'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt WebEngine, MHTML and custom schemes

[Allan Sandfeld Jensen]

On Montag, 30. November 2020 15:00:10 CET Benjamin TERRIER wrote:
> Hi,
> 
> When accessing an MHTML file using a custom local scheme (either using
> 'qrc:/' or using 'QWebEngineUrlSchemeHandler') it triggers a download.
> 
> However, when using 'file:/' the MHTML file is displayed as a web page.
> 
> I am trying to have the MHTML displayed also when using a custom scheme.
> I have tried to play with
> https://doc.qt.io/qt-5/qwebengineurlscheme.html#Flag-enum but it did not
> work.
> 
> Does someone have an idea to make it work?
> 
Unfortunately it is pretty hard-coded, see  src/3rdparty/chromium/content/
browser/loader/download_utils_impl.cc.

We could make it somewhat programmable by implementing 
ContentBrowserClientQt::AllowRenderingMhtmlOverHttp() which despite its name 
is called for all non-file schemes.

The question is then, should it be a setting per scheme or per page, and are 
there other people needing such a feature? The fact it is called from both IO 
and UI threads makes it a little more work than usual to implement.

Best regards
'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] What is Qt::Key_Cancel?

[Allan Sandfeld Jensen]

On Donnerstag, 9. Juli 2020 12:41:14 CEST Tor Arne Vestbø wrote:
> It’s mapped to e.g. VK_CANCEL on Windows:
> 
> ❯ git grep Key_Cancel   
>   
>  dist/changes-4.2.0:1246:  * Added
> several missing keys to the Key enum: Key_Cancel, Key_Printer,
> src/corelib/global/qnamespace.h:1060:Key_Cancel  = 0x01020001,
> src/corelib/global/qnamespace.qdoc:1829:\value Key_Cancel
> src/gui/kernel/qkeysequence.cpp:693:{ Qt::Key_Cancel, 
> QT_TRANSLATE_NOOP("QShortcut", "Cancel") },
> src/gui/platform/unix/qxkbcommon.cpp:163:Xkb2Qt  Qt::Key_Cancel>,
> src/platformsupport/input/evdevkeyboard/qevdevkeyboard_defaultmap_p.h:664: 
>   { KEY_CANCEL,   0x, Qt::Key_Cancel, 0x00, 0x00, 0x },
> src/plugins/platforms/windows/qwindowskeymapper.cpp:214:Qt::Key_Cancel,
> //   3   0x03   VK_CANCEL   | Control-Break processing 
>
> Don’t know what physical key would produce this.
> 
CTRL + Pause/Break  on Windows supposedly.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Gold linker configuration in Qt 5

[Allan Sandfeld Jensen]

On Donnerstag, 2. Juli 2020 11:29:17 CEST Ramakanth Kesireddy wrote:
> Hi,
> 
> Is it recommended to use gold linker or system linker with
> -no-use-goldlinker while configuring Qt5.6.3 and above?
> 
> As per my understanding, gold linker should provide faster linking and use
> less memory than the traditional linker.
> 
> Please let me know your thoughts in this regard.
> 
Use gold linker if it works. It is faster and has more features. There were 
some issues on some embedded platforms so I believe the default was changed 
back to bfd around 5.14 or 5.15, but for a long time we would use gold if it 
was detected.

'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtQuick: weird fonts problem

[Allan Sandfeld Jensen]

On Freitag, 12. Juni 2020 07:17:30 CEST Jason H wrote:
> From what I've seen, it's a combination of poor font hinting, a bad
> cleartype implementation, it some combination there of. You can change the
> way Qt handles the font hinting, by turning off antialiased text. It'll
> good the issue, but then the text won't appear smooth.

You can also disabled just subpixel antialiasing using 
QFont::NoSubpixelAntialias. Then you should still get graytone antialiasing. 
Hopefully that would work better in this case. You can also disable cleartype 
on the OS level, if you are unable to modify the Qt application.

And on Windows you can try the freetype backend instead of the default windows 
font backend.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.12.8 32 bit libraries configure options on Ubuntu 16.04

[Allan Sandfeld Jensen]

Hi Ramakanth

Yes, to build Qt to 32bit you need have the 32bit version of the relevant 
system libraries installed as well, though many can just default to internal 
copies or disable functionality. 

For some libraries in some linux distros the 32bit and 64bit developer 
packages are mutually exclusive, and you might need to uninstall the 64bit 
version first. 

The -m32 is added automatically by the linux-g++-32 spec. 

Allan

On Dienstag, 5. Mai 2020 12:57:48 CEST Ramakanth Kesireddy wrote:
> Hi,
> 
> While configuring with -platform linux-g++-32, it fails the tests with
> below errors in the configure output:
> 
> ERROR: Feature 'ssl' was enabled, but the pre-condition 'config.winrt ||
> features.securetransport || features.openssl' failed.
> 
> ERROR: Feature 'xcb' was enabled, but the pre-condition 'features.thread &&
> features.xkbcommon && libs.xcb' failed.
> 
> ERROR: Feature 'system-freetype' was enabled, but the pre-condition
> 'features.freetype && libs.freetype' failed.
> 
> ERROR: Feature 'fontconfig' was enabled, but the pre-condition
> '!config.msvc && features.system-freetype && libs.fontconfig' failed.
> 
> Since the app is compiled with -m32, the corresponding Qt libs need to be
> compiled with -m32 inorder to generate the appropriate code on Ubuntu 16.04
> VM
> so as to replicate the same tests being performed on 32 bit target.
> 
> Please let me know if we need to install the 32 bit library versions to
> resolve the above errors.
> 
> Best Regards,
> Ramakanth
> 
> 
> On Tue, May 5, 2020 at 12:30 AM Allan Sandfeld Jensen 
> 
> wrote:
> > On Montag, 4. Mai 2020 18:31:19 CEST Ramakanth Kesireddy wrote:
> > > Hi,
> > > 
> > > Can anyone let me know the configure options to generate 32 bit Qt
> > > 5.12.8
> > > libraries on Ubuntu 16.04 like the below equivalent configure options in
> > 
> > Qt?
> > 
> > >  for  ./configure "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
> > > 
> > > Do we need to modify the QMAKE_CFLAGS or there are any configure options
> > > while configuring Qt 5.12.8 sources to generate 32 bit Qt libs?
> > 
> > Just configure with -platform linux-g++-32
> > 
> > Why are you making 32-bit libraries now though?
> > 
> > 'Allan
> > 
> > 
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.12.8 32 bit libraries configure options on Ubuntu 16.04

[Allan Sandfeld Jensen]

On Montag, 4. Mai 2020 18:31:19 CEST Ramakanth Kesireddy wrote:
> Hi,
> 
> Can anyone let me know the configure options to generate 32 bit Qt 5.12.8
> libraries on Ubuntu 16.04 like the below equivalent configure options in Qt?
> 
>  for  ./configure "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
> 
> Do we need to modify the QMAKE_CFLAGS or there are any configure options
> while configuring Qt 5.12.8 sources to generate 32 bit Qt libs?
> 
Just configure with -platform linux-g++-32

Why are you making 32-bit libraries now though?

'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtWebengine is not built with v8 snapshot error

[Allan Sandfeld Jensen]

I am not sure, I think gcc-7-base:i386 or something like that, check the 
config.log and how the test failed. You basically just need a compiler that 
compile to 32bit, and the most basic libraries (libc, libstdc++) for 32bit as 
well.

'Allan

On Sonntag, 3. Mai 2020 11:41:20 CEST you wrote:
> Thanks for your mail.
> Could you please let me know the packages to be installed on Ubuntu
> 16.04(64 bit) to match the target for building the snapshot?
> 
> Best Regards,
> Ramakanth
> 
> On Sun, May 3, 2020 at 12:15 PM Allan Sandfeld Jensen 
> 
> wrote:
> > On Sonntag, 3. Mai 2020 06:20:22 CEST Ramakanth Kesireddy wrote:
> > > ,Hi,
> > > 
> > > As am trying to cross-compile Qt 5.12.8 sources on Ubuntu 16.04(64 bit),
> > 
> > it
> > 
> > > throws below error:
> > > 
> > > V8 snapshot cannot be built. Most likely, the 32-bit host compiler does
> > 
> > not
> > 
> > > work. Please make sure you have 32-bit devel environment installed, or
> > > 
> > >  configure webengine with '-no-webengine-v8-snapshot'
> > > 
> > > QtWebEngine will not be built.
> > 
> > Just install the x86-32bit compiler and tools. We need a host compiler
> > that
> > matches the target for building the snapshot. Note in 5.15 we can no
> > longer
> > disable snapshots, and so it is no longer optional (though 5.12 should
> > still
> > work)
> > 
> > > Even configuring with -no-webengine-v8-snapshot doesnot builds
> > 
> > QtWebengine
> > 
> > > module.
> > > 
> > > Configure line:
> > > 
> > > ./configure -v -opensource -confirm-license -make libs -release -shared
> > > -sysroot
> > 
> > /home/ubuntu/ti-processor-sdk-linux-rt-am335x-evm-05.03.00.07/linux-devkit
> > /s> 
> > > ysroots/armv7ahf-neon-linux-gnueabi -no-gcc-sysroot -device
> > > arm-linux-gnueabihf-g++ -device-option
> > 
> > CROSS_COMPILE=/home/ubuntu/ti-processor-sdk-linux-rt-am335x-evm-05.03.00.0
> > 7/> 
> > > linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf-
> > > -reduce-exports -optimize-size -no-gtk -force-pkg-config
> > > -no-use-gold-linker -qt-libjpeg -qt-zlib -qt-libpng -sql-sqlite -no-xcb
> > > -no-cups -no-opengl -no-qml-debug -skip qt3d -skip qtactiveqt -skip
> > > qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity
> > 
> > -skip
> > 
> > > qtdatavis3d -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip
> > > qtimageformats -skip qtnetworkauth -skip qtlocation -skip qtmacextras
> > 
> > -skip
> > 
> > > qtpurchasing -skip qtmultimedia -skip qtquickcontrols -skip
> > > qtquickcontrols2 -skip qtremoteobjects -skip qtscript -skip qtscxml
> > > -skip
> > > qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip
> > 
> > qttools
> > 
> > > -skip qtwayland -skip qtwebsockets -skip qtwebview -skip qtwebchannel
> > 
> > -skip
> > 
> > > qtwinextras -skip qtandroidextras -skip qtx11extras -skip qtxmlpatterns
> > > -nomake tools -nomake tests -nomake examples -no-compile-examples
> > 
> > -no-iconv
> > 
> > > -dbus -fontconfig -system-freetype -ssl -qt-pcre -no-pch -recheck-all
> > > -DQT_ARCH_ARM
> > > 
> > > Appreciate your help in this regard to resolve Qtwebengine build error.
> > 
> > Please report the errors you see.
> > 
> > Best regards
> > Allan
> > 
> > 
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtWebengine is not built with v8 snapshot error

[Allan Sandfeld Jensen]

On Sonntag, 3. Mai 2020 06:20:22 CEST Ramakanth Kesireddy wrote:
> ,Hi,
> 
> As am trying to cross-compile Qt 5.12.8 sources on Ubuntu 16.04(64 bit), it
> throws below error:
> 
> V8 snapshot cannot be built. Most likely, the 32-bit host compiler does not
> work. Please make sure you have 32-bit devel environment installed, or
>  configure webengine with '-no-webengine-v8-snapshot'
> QtWebEngine will not be built.
> 
Just install the x86-32bit compiler and tools. We need a host compiler that 
matches the target for building the snapshot. Note in 5.15 we can no longer 
disable snapshots, and so it is no longer optional (though 5.12 should still 
work)


> Even configuring with -no-webengine-v8-snapshot doesnot builds QtWebengine
> module.
> 
> Configure line:
> 
> ./configure -v -opensource -confirm-license -make libs -release -shared
> -sysroot
> /home/ubuntu/ti-processor-sdk-linux-rt-am335x-evm-05.03.00.07/linux-devkit/s
> ysroots/armv7ahf-neon-linux-gnueabi -no-gcc-sysroot -device
> arm-linux-gnueabihf-g++ -device-option
> CROSS_COMPILE=/home/ubuntu/ti-processor-sdk-linux-rt-am335x-evm-05.03.00.07/
> linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf-
> -reduce-exports -optimize-size -no-gtk -force-pkg-config
> -no-use-gold-linker -qt-libjpeg -qt-zlib -qt-libpng -sql-sqlite -no-xcb
> -no-cups -no-opengl -no-qml-debug -skip qt3d -skip qtactiveqt -skip
> qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip
> qtdatavis3d -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip
> qtimageformats -skip qtnetworkauth -skip qtlocation -skip qtmacextras -skip
> qtpurchasing -skip qtmultimedia -skip qtquickcontrols -skip
> qtquickcontrols2 -skip qtremoteobjects -skip qtscript -skip qtscxml -skip
> qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip qttools
> -skip qtwayland -skip qtwebsockets -skip qtwebview -skip qtwebchannel -skip
> qtwinextras -skip qtandroidextras -skip qtx11extras -skip qtxmlpatterns
> -nomake tools -nomake tests -nomake examples -no-compile-examples -no-iconv
> -dbus -fontconfig -system-freetype -ssl -qt-pcre -no-pch -recheck-all
> -DQT_ARCH_ARM
> 
> Appreciate your help in this regard to resolve Qtwebengine build error.
> 
Please report the errors you see.

Best regards
Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Application - Disabling AVX/AVX2

[Allan Sandfeld Jensen]

On Mittwoch, 22. April 2020 17:29:56 CEST coroberti . wrote:
> On Wed, Apr 22, 2020 at 6:17 PM Thiago Macieira
> 
>  wrote:
> > On Tuesday, 21 April 2020 14:26:13 PDT coroberti . wrote:
> > > Hi,
> > > Is it enough to define:
> > > 
> > > QMAKE_CFLAGS -= -arch:AVX -arch:AVX2
> > > QMAKE_CXXFLAGS -=  -arch:AVX -arch:AVX2
> > > 
> > > to ensure that compilation by QtCreator with Qt-5.14-MSVC Windows
> > > will not compile with such optimization flags even if avx and avx2
> > > instructions have not been disabled in Qt-library itself?
> > 
> > Since those options aren't added to the CFLAGS or CXXFLAGS in the first
> > place, by default what you're tryng to do is a no-op.
> > Why do you think there are AVX instructions in your binary? And how did
> > you
> > turn them on in the first place?
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > 
> >   Software Architect - Intel System Software Products
> 
> Thank you for your reply.
> 
> Building 5.14.2, I was alerted by report from config that avx
> instructions are enabled.
> 
> Clear, I need to investigate it more.
> 
Probably support for them is enabled, but not turned on. That is what we do in 
qtbase, build only some files with AVX enabled and switch to them on at 
runtime.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Allan Sandfeld Jensen]

On Sonntag, 19. April 2020 14:39:40 CEST André Pönitz wrote:
> On Sun, Apr 19, 2020 at 02:21:39PM +0200, Allan Sandfeld Jensen wrote:
> > > I don't think we need "incomparable" here.
> > > 
> > > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA
> > > and
> > > TypeB based e.g. on alphabetical order of their .typeName().
> > > 
> > > If wanted, this can be refined to make e.g. all integral types
> > > comparable.
> > 
> > What about non-integral types?
> 
> They are compared by typeName(). So any QChar would be less-than any
> QRegularExpression.
> 
> > QVariants can't really be anything but weakly ordered as I see it,
> > as some of the things it contains are either non- comparable or
> > weakly ordered themselves.
> 
> On the inner level the situation is up to the actual type, that's no
> different than today, and would also not be affected by disallowing
> comparisons between different types.
> 
Yes, but in C++20 terms the comparison operators still need to return types of 
https://en.cppreference.com/w/cpp/utility/compare/partial_ordering[1] 

But all that really isn't possible before C++20 as I see it.

'Allan


[1] https://en.cppreference.com/w/cpp/utility/compare/partial_ordering
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Allan Sandfeld Jensen]

On Sonntag, 19. April 2020 14:23:56 CEST André Pönitz wrote:
> On Sun, Apr 19, 2020 at 01:28:32PM +0200, Allan Sandfeld Jensen wrote:
> > On Sonntag, 19. April 2020 13:05:05 CEST André Pönitz wrote:
> > > On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> > > > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest
> > 
> > wrote:
> > > > > I guess that's the reason for dropping the comparisons in 6.0 and,
> > > > > eventually, reintroduce it in 7.0. With the hope that we've learned
> > > > > the
> > > > > lesson and proceed at _specifying_ the behaviour before implementing
> > > > > it.
> > > > 
> > > > Indeed, and implement the QVariant comparator on top of each
> > > > underlying
> > > > type's spaceship operator. That way, we could order elements of the
> > > > same
> > > > type. For mismatched types, QVariant can return
> > > > std::partial_ordering::unordered.
> > > > 
> > > > We can't do that right now because we can't rely on C++20. In fact, no
> > > > current compiler supports the spaceship operator. So that has to be Qt
> > > > 7.
> > > 
> > > How comes the spaceship operator comes into play here?
> > > 
> > > It's syntactical sugar and in some cases an optimization, but has no
> > > concepual powers exceeding those of operator<().
> > 
> > It has the concept of weak ordering, it isn't just returning true or
> > false,
> > but an enum of a specific type, which so we can report two elements as
> > incomparable if they are not of comparable types.
> 
> I don't think we need "incomparable" here.
> 
> QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> TypeB based e.g. on alphabetical order of their .typeName().
> 
> If wanted, this can be refined to make e.g. all integral types comparable.
> 
What about non-integral types? QVariants can't really be anything but weakly 
ordered as I see it, as some of the things it contains are either non-
comparable or weakly ordered themselves.

'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

[Allan Sandfeld Jensen]

On Sonntag, 19. April 2020 13:05:05 CEST André Pönitz wrote:
> On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest 
wrote:
> > > I guess that's the reason for dropping the comparisons in 6.0 and,
> > > eventually, reintroduce it in 7.0. With the hope that we've learned the
> > > lesson and proceed at _specifying_ the behaviour before implementing it.
> > 
> > Indeed, and implement the QVariant comparator on top of each underlying
> > type's spaceship operator. That way, we could order elements of the same
> > type. For mismatched types, QVariant can return
> > std::partial_ordering::unordered.
> > 
> > We can't do that right now because we can't rely on C++20. In fact, no
> > current compiler supports the spaceship operator. So that has to be Qt 7.
> 
> How comes the spaceship operator comes into play here?
> 
> It's syntactical sugar and in some cases an optimization, but has no
> concepual powers exceeding those of operator<().
> 
It has the concept of weak ordering, it isn't just returning true or false, 
but an enum of a specific type, which so we can report two elements as 
incomparable if they are not of comparable types. 

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Hardware accelerated rendering in Qt 5.12.7

[Allan Sandfeld Jensen]

No, unfortunately not.

'Allan

On Saturday, 4 April 2020 06:18:57 CEST Ramakanth Kesireddy wrote:
> Is there any attribute that can be set in QWidget which could use hardware
> accelerated graphics or opengl paint device in Qt 5.12.7 without changing
> the custom widgets deriving from QWidget?
> 
> On Tue, 4 Feb, 2020, 13:52 Allan Sandfeld Jensen,  wrote:
> > On Dienstag, 4. Februar 2020 03:26:12 CET Ramakanth Kesireddy wrote:
> > > Hi,
> > > 
> > > Our existing application is based on c++ widgets(QWidget) using QPainter
> > 
> > on
> > 
> > > Qt 5.13. As i understand Qpainter uses raster engine for graphics
> > > rendering, Is there any means to make use of hardware accelerated
> > > rendering(GPU) other than changing the complete Application code into Qt
> > > quick or QGLWidget?
> > 
> > You can create a QOpenGLWindow or QOpenGLWidget and paint therein.
> > 
> > You can also use QGraphicsView with a QOpenGLWidget as a viewport.
> > 
> > In both cases an accelerated QPainter would then be used.
> > 
> > 'Allan




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] WebEngine proxy whitelist

[Allan Sandfeld Jensen]

On Friday, 6 March 2020 11:02:55 CET Benjamin TERRIER wrote:
> On Thu, 5 Mar 2020 at 21:54, Allan Sandfeld Jensen  wrote:
> > I don't know why they would say that, as far as I know it works. In any
> > case I
> > would suggest using the same mechanism we use for testing PAC support:
> > The command line argument "--proxy-pac-url=file://$$PACFILE"
> > 
> > And since it is how we test our PAC support it is covered by our
> > regression
> > tests ;)
> > 
> > 'Allan
> 
> Hi,
> 
> Thanks for the tip. I've looked into the tests to see how it's done.
> 
> However after some tests it does not seem to work.
> It seems that when a proxy is set in Qt Network, the command line switches
> are ignored.
> 
Uh, that might be true. I don't think we have spend a great deal of time 
figuring out which outside source of proxy configuration should win, but yes, 
I think QtNetwork might win currently :/

'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] WebEngine proxy whitelist

[Allan Sandfeld Jensen]

On Thursday, 5 March 2020 20:57:06 CET Benjamin TERRIER wrote:
> On Thu, 5 Mar 2020 at 19:56, Allan Sandfeld Jensen  wrote:
> > Could you write it as a pac-script?
> > 
> > I think there are some Chromium command-line arguments too that can change
> > the
> > defaults, but I think a pac-script is the most flexible and universal way.
> 
> This could be a solution. If PAC is supported by Qt Web Engine.
> 
> I searched how to configure Qt Web Engine to use PAC and all I found was:
> 
> *Note:* If the first page takes long too load, this is often because Qt
> 
> > WebEngine queries the network for a PAC (Proxy Auto-Configuration) file.
> 
> in https://wiki.qt.io/QtWebEngine/Network . Well, ok, but there is no
> information how to enable this.
> 
> And I also found this in qutebrowser changelogs:
> 
> PAC proxies currently don't work properly on QtWebEngine (and never did), so
> >   an error is now shown when trying to configure a PAC proxy.
> 
> So I am a bit skeptical.
> 
I don't know why they would say that, as far as I know it works. In any case I 
would suggest using the same mechanism we use for testing PAC support: 
The command line argument "--proxy-pac-url=file://$$PACFILE"

And since it is how we test our PAC support it is covered by our regression 
tests ;)

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] WebEngine proxy whitelist

[Allan Sandfeld Jensen]

On Wednesday, 4 March 2020 16:33:17 CET Benjamin TERRIER wrote:
> Hi,
> 
> Is there any way to set a whitelist of URLs for proxy in Qt WebEngine?
> 
> In Qt application this is done by implementing
> QNetworkProxyFactory::queryProxy() and returning NoProxy based on the query
> URL.
> 
> However, even if Qt WebEngine does use the application proxy it does not
> call queryProxy() for each request. My understanding is that only some
> specific proxy parameters (host, port, etc.) are copied to the chromium
> network stack, making impossible to specify a different proxy for each
> request.
> 
> Is there any other way to specify a list of URLs that should not use proxy
> in Qt WebEngine?
> 
Could you write it as a pac-script?

I think there are some Chromium command-line arguments too that can change the 
defaults, but I think a pac-script is the most flexible and universal way.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Hardware accelerated rendering in Qt 5.13

[Allan Sandfeld Jensen]

On Dienstag, 4. Februar 2020 03:26:12 CET Ramakanth Kesireddy wrote:
> Hi,
> 
> Our existing application is based on c++ widgets(QWidget) using QPainter on
> Qt 5.13. As i understand Qpainter uses raster engine for graphics
> rendering, Is there any means to make use of hardware accelerated
> rendering(GPU) other than changing the complete Application code into Qt
> quick or QGLWidget?
> 
You can create a QOpenGLWindow or QOpenGLWidget and paint therein.

You can also use QGraphicsView with a QOpenGLWidget as a viewport.

In both cases an accelerated QPainter would then be used.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVideoFrame 32 bit formats byte order

[Allan Sandfeld Jensen]

On Thursday, 14 November 2019 21:37:09 CET Allan Sandfeld Jensen wrote:
> On Thursday, 14 November 2019 21:17:38 CET Stefan Fabian wrote:
> > That may be explained by the endianness, though, since ARGB as 32bit uint
> > on little-endian (what most if not all consumer pcs use) would be BGRA in
> > memory. In the case of BGRA32, endianness could change it to ARGB but not
> > ABGR or RGBA as in my test. Either way, it should be documented how raw
> > memory is interpreted (consecutive bytes [big-endian] or one 4 byte word
> > per pixel [cpu dependent]).
> 
> Formats called something32 are 32-bit formats, they are the same regardless
> of endian when read in as 32bit integers. Formats that are called
> something are bytewise formats and the same regardless of endian when
> reads a series of 8bit integers.
> 
> See https://en.wikipedia.org/wiki/RGBA_color_space#Representation[1]
> 
> 
> BGRA32 is how RGBA looks if you read it as 32bit integers on a little
> endian machine.
> 
Ooos. how ARGB would look like..
 Which is actually rather silly, the two most common formats are ARGB32 and 
RGBA, and their misinterpreted counterparts on little-endian BGRA and 
ABGR32

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVideoFrame 32 bit formats byte order

[Allan Sandfeld Jensen]

On Thursday, 14 November 2019 21:17:38 CET Stefan Fabian wrote:
> That may be explained by the endianness, though, since ARGB as 32bit uint on
> little-endian (what most if not all consumer pcs use) would be BGRA in
> memory. In the case of BGRA32, endianness could change it to ARGB but not
> ABGR or RGBA as in my test. Either way, it should be documented how raw
> memory is interpreted (consecutive bytes [big-endian] or one 4 byte word
> per pixel [cpu dependent]). 

Formats called something32 are 32-bit formats, they are the same regardless of 
endian 
when read in as 32bit integers. Formats that are called something are 
bytewise 
formats and the same regardless of endian when reads a series of 8bit integers.

See https://en.wikipedia.org/wiki/RGBA_color_space#Representation[1] 


BGRA32 is how RGBA looks if you read it as 32bit integers on a little 
endian 
machine.

Regards
Allan


[1] https://en.wikipedia.org/wiki/RGBA_color_space#Representation
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dark mode for other platforms

[Allan Sandfeld Jensen]

On Wednesday, 16 October 2019 13:59:54 CEST Nikos Chantziaras wrote:
> On 15/10/2019 13:46, Allan Sandfeld Jensen wrote:
> > On Tuesday, 15 October 2019 11:58:42 CEST Vadim Peretokin wrote:
> >> Hello!
> >> 
> >> I've noticed that Qt on macOS now automatically uses dark mode, and it
> >> looks amazing
> >> <https://www.mudlet.org/wp-content/uploads/2019/10/unknown.png>. My
> >> question is: how can I enable this for Windows and Linux as well?
> > 
> > Linux and Window have had such modes forever.
> 
> Well, I wouldn't say "forever" in the case of Windows. It only got a
> dark mode theme exactly 1 year ago (October 2018.) Which is one month
> *after* macOS 10.14 was released (September 2018.)

Windows have had color schemes since at least Window95. It recently added a 
single button to switch the default white color scheme to a dark one, instead 
of selecting a dark on from a list of schemes, but the ability to change them 
has existed for 25 years if not more.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dark mode for other platforms

[Allan Sandfeld Jensen]

On Tuesday, 15 October 2019 11:58:42 CEST Vadim Peretokin wrote:
> Hello!
> 
> I've noticed that Qt on macOS now automatically uses dark mode, and it
> looks amazing
> . My
> question is: how can I enable this for Windows and Linux as well?
> 
Linux and Window have had such modes forever. The main problem however have 
been as long as they weren't a common default, many applications didn't follow 
the colors, or did follow them, but then ended up looking bad.


'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Building QTWebEngine

[Allan Sandfeld Jensen]

On Thursday, 10 October 2019 01:07:46 CEST Simon Matthews wrote:
> On 10/9/19 3:52 PM, Thiago Macieira wrote:
> 
> > On Wednesday, 9 October 2019 15:18:33 PDT Simon Matthews wrote:
> > 
> >> However, it appears that files such as "Qt5WebEngineConfig.cmake" are
> >> not included in my build.
> >>
> >>
> >>
> >> Is it necessary to build QtWebEngine as a separate build?
> > 
> > No.
> >
> >
> >
> > Are you sure the build completed without errors? To be sure, go into
> > qtwebengine and type "make".
> >
> >
> 
> $ cd qt-everywhere-src-5.13.1/qtwebengine/
> /home/simon/rpms/sources/qt-everywhere-src-5.13.1/qtwebengine
> [simon@UserBuild qtwebengine]$ make
> make: Nothing to be done for 'first'.
> 
That means QtWebEngine is being skipped due to a missing dependency. If you 
clean the build dir, you can run "make qmake" there and see what fails.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Q_NAMESPACE is not portable?

[Allan Sandfeld Jensen]

On Monday, 26 August 2019 17:29:31 CEST Matthew Woehlke wrote:
> On 23/08/2019 19.02, Giuseppe D'Angelo via Interest wrote:
> > On 24/08/2019 00:10, Matthew Woehlke wrote:
> >> Am I doing something wrong, or is it impossible to use Q_NAMESPACE
> >> correctly without platform-specific PP conditionals?
> > 
> > I've fixed this in 5.14, see
> > 
> >> https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_NAMESPACE_EXPORT
> 
> BTW, what happened to the doc? Macros aren't class members...

LOL. 
It is broken in 5.13 too
https://doc-snapshots.qt.io/qt5-5.13/qobject.html#Q_NAMESPACE

looks right 5.12
https://doc-snapshots.qt.io/qt5-5.12/qobject.html#Q_NAMESPACE


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QPainter::drawImage() is terrible at smooth scaling?

[Allan Sandfeld Jensen]

On Freitag, 17. Mai 2019 06:48:20 CEST David M. Cotter wrote:
> is this a bug?
> 
> https://forum.qt.io/topic/102637/qpainter-drawimage-is-terrible-at-smooth-sc
> aling
> 
Likes like you are downscaling more than 2x. QPainter is doing bilinear 
sampling when smooth scaling, and that produces bad results at 2x downscaling. 
QImage::smoothScaled() uses a slower box scaling algorithm that works at even 
the most aggressive downscaling.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Building Qt and WebEngine

[Allan Sandfeld Jensen]

On Donnerstag, 25. April 2019 10:28:42 CEST Volker Enderlein wrote:
> Hi,
> 
> 
> when building Qt and WebEngine separately (i.e. not doing an embeddd
> build), do I need to install Qt before building WebEngine and provide
> the path to the installation?
> 
> Are there any step by step instructions how to do this? I searched
> already for a while with no luck, apparently using the wrong keywords.
> 
Like any other Qt project, you call the qmake from either the installed or 
temporary build path (under qtbase/bin). If you want to build qtwebengine 
separately, the builddir need to be somewhere it wouldn't be in a qt5 top-
build. Calling QMake should then cause the configure step to run, and the 
project can be built like normal after that. You can put the configure 
arguments for webengine on the qmake command line after --. For instance:

/bin/qmake  -- -
webengine-proprietary-codecs -system-webengine-ffmpeg -no-webegine-webrtc

Best regards
'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.13 QtWebEngine GN Error

[Allan Sandfeld Jensen]

On Dienstag, 23. April 2019 19:45:14 CEST Oliver Niebuhr wrote:
> Hi.
> 
> I am constantly running into the following Error:
> 
> Project MESSAGE:
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\build\gen.py
> --no-last-commit-position --out-path
> C:/QtSrcx64/qtwebengine/src/3rdparty/gn/out/Release --cc "C:\Program
> Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\Hostx64\x64\cl.exe"
> --cxx "C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\Hostx64\x64\cl.exe"
> --ld "C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\Hostx64\x64\link.exe"
> [1/11] CXX tools/gn/xml_element_writer.obj
> [2/11] CXX util/sys_info.obj
> [3/11] CXX util/semaphore.obj
> [4/11] CXX util/ticks.obj
> [5/11] CXX util/msg_loop.obj
> [6/11] CXX util/exe_path.obj
> [7/11] CXX util/worker_pool.obj
> [8/11] CXX tools/gn/substitution_writer.obj
> FAILED: tools/gn/substitution_writer.obj
> ninja -t msvc -- C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\Hostx64\x64\cl.exe
> /nologo /showIncludes /FC @tools/gn/substitution_writer.obj.rsp /c
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools/gn/substitution_writer.cc
> /Fotools/gn/substitution_writer.obj
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 91): error C2039: 'string': is not a member of 'std'
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\include\vector(19):
> note: see declaration of 'std'
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 91): error C3646: 'ApplyPatternToSourceAsString': unknown override specifier
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h
> (92): error C2059: syntax error: 'const'
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 95): error C2238: unexpected token(s) preceding ';'
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 117): error C2039: 'string': is not a member of 'std'
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.20.27508\include\vector(19):
> note: see declaration of 'std'
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 117): error C2065: 'string': undeclared identifier
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 117): error C2923: 'std::vector': 'string' is not a valid template type
> argument for parameter '_Ty'
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h(
> 117): error C3203: 'allocator': unspecialized class template can't be used
> as a template argument for template parameter '_Alloc', expected a real
> type
> C:\qt5srcgit\qt5\qtwebengine\src\3rdparty\gn\tools\gn\substitution_writer.h
> (137): error C2039: 'string': is not a member of 'std'
> [...shortened here...]
> 
> I am not sure if this is a already known Issue or if the Chromium
> Version coming with Qt 5.13 is not compatible with VS 2019?
> 
None of Qt WebEngine versions are compatible with VS 2019. If you had managed 
to build GN you would have run into our hardcoded check that you are using a 
known compatible compiler. 

You need the following changes that have gone to 5.12 first:

https://codereview.qt-project.org/259283
https://codereview.qt-project.org/259285/

"Fortunately" most of the changes in VS 2019 were introduced gradually in VS 
2017, so it was only a single very minor change.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Allan Sandfeld Jensen]

On Donnerstag, 18. April 2019 14:46:59 CEST Oliver Wolff wrote:
> Hi,
> 
> as you might have heard, we are currently in Qt 6's planning phase and 
> thus checking things that have to be done to make Qt even better.
> Of course we also want to use this opportuniy to drop support for 
> platforms that are no longer relevant in Qt's new environment.
> 
> One of these platforms is Microsoft's Universal Windows Platform which 
> is used on desktop PCs (for "Tiled" UWP applications, no classic desktop 
> applications), Windows Phone, Xbox one, Microsoft Hololens, and 
> Microsoft IoT devices. With Windows Phone no longer being relevant and 
> Microsoft's IoT strategy being unclear we now consider dropping support 
> for these platforms. Additional benefits and reasons can be found in 
> https://bugreports.qt.io/browse/QTBUG-74755
> 
> To be able to make the right decision, we now want your input as well. 
> If you can give some input on why support should be kept or have 
> additional reasons for dropping support, please reply to this mail or 
> add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we 
> want to gather all the needed information before making a decision.
> 
> As said before, nothing is set in stone. At the moment we are gathering 
> information so that we can make a well informed decision.

How does UWP support relate to using UWP APIs? 

It seems a lot of new Windows API is UWP specific. For instance for HDR 
support I need to read the luminance level for SDR content in HDR mode, and I 
could only find UWP API for that.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] WebAuthn support

[Allan Sandfeld Jensen]

On Sonntag, 7. April 2019 06:13:44 CEST Tom Isaacson wrote:
> I was trying to find whether Qt supports WebAuthn but all I could find is
> this list of missing use cases for QtWebEngine:
> https://wiki.qt.io/QtWebEngine/UseCases
> 
> Is there anything else, does it just require an example or is it still to be
> implemented?
> 
It is missing both research into what is needed to enable it, and implementing 
the missing pieces. As far as I know we are missing at least WebUSB support, 
and to clean up the new FIDO code in Chromium so that it compiles on more than 
just clang.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Allan Sandfeld Jensen]

On Donnerstag, 21. März 2019 10:16:35 CET René J. V. Bertin wrote:
> >> Actually, it doesn't: 5.9 support ends in May 2020, OpenSSL 1.0 in Dec
> >> 2019.> 
> > You're off by one year. 5.9.0 was released May 29, 2017.
> > 
> > (probably a bit later because we are able to
> > make the 5.9.9 release).
> 
> That means some of the dates in the wikipedia article are wrong... but not
> the EOL date :)
> And interesting that I apparently missed 2 releases, my version monitor
> mustn't be as reliable as I thought.
> 
> > > but I'm guessing Qt may not want to depend only on an OpenSSL variant
> > > that's EOL.
> > 
> > Except that it's not EOL. OpenSSL 1.0.2 is still officially supported
> > until
> > 2019-12-31.
> 
> "May want" as in the future, not "doesn't want" now.
> 
> > If you search the commit log, you'll see a number of OpenSSL 1.1 bugfixes.
> > 
> > PS: you should backport those fixes too.
> 
> Indeed! Are they all labelled OpenSSL, or should I rather look at the log
> for the network/ssl folder hope I catch everything?
> Are all fixes in 5.10 and thus in the 5.10 branch?
> 
Just find the patch from one of the distros that did already did the 
backporting. There are at least two, but probably more.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [#ID:INC-1251018#] Installation issue.

[Allan Sandfeld Jensen]

On Dienstag, 12. März 2019 02:02:44 CET Thiago Macieira wrote:
> On Monday, 11 March 2019 04:14:02 PDT Bill Crocker wrote:
> > If you can build with GCC 4.8 on "Generic Linux" why does
> > RHEL7 require GCC 5.3.1
> 
> The problem is not the GCC version. It's the set of libraries provided by
> the old distribution.

And I guess he could still build his own packages. The libraries would just 
use bundled qt copies if too old. Only the prebuilt packages have higher 
requirements, right?

' Allan 


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Allan Sandfeld Jensen]

On Freitag, 15. Februar 2019 19:43:56 CET Konstantin Shegunov wrote:
> On Fri, Feb 15, 2019 at 4:57 PM Allan Sandfeld Jensen 
> 
> wrote:
> > Btw. If(when) the output isn't debug friendly, it is really a gcc bug
> 
> True, and I (hope) I haven't implied otherwise.
> 
> > should be reported to them if you have the time, and want it to improve in
> > the
> > future.
> 
> Perhaps, but as is of now (with disabling the optimizations) it works for
> me. If I get some time in I'd try to reproduce and report it, although I'm
> not completely sure how I should format that report ... maybe I should
> provide the assembly alongside the source to serve as an illustration ...
> 
Yes, exactly. They prefer sources and then one or more intermediate formats, 
in this case I would assume compiling to assembly with the debug information 
annotated might have all the necessary information (or lack there of). There 
are various flags to make assembler output more verbose and annotated. Though 
there is a risk it might not have all the dwarf debug-info or might contain 
things that later get lost in dwarf encoding, in that case you would have to 
make do with just the test case in source, and how it fails in debugging.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Allan Sandfeld Jensen]

On Freitag, 15. Februar 2019 15:00:36 CET Konstantin Shegunov wrote:
> Hello,
> That flag's been a pain for me to debug the Qt codebase for a while now,
> I'm really annoyed that configure generates it when using -developer-build.
> Long story short it prevents me to do step-by-step with gdb as the compiler
> reorders the code as it sees fit (no clue why). I remember I had found a
> commit from about 2-3 years ago which introduced it, and even found how to
> disable it, but for the life of me I couldn't find it again during my most
> recent searches.
> How can I disable the debug optimizations, and I mean completely?
> 
Btw. If(when) the output isn't debug friendly, it is really a gcc bug, and 
should be reported to them if you have the time, and want it to improve in the 
future.

Best regards
'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Allan Sandfeld Jensen]

On Freitag, 15. Februar 2019 15:00:36 CET Konstantin Shegunov wrote:
> Hello,
> That flag's been a pain for me to debug the Qt codebase for a while now,
> I'm really annoyed that configure generates it when using -developer-build.
> Long story short it prevents me to do step-by-step with gdb as the compiler
> reorders the code as it sees fit (no clue why). I remember I had found a
> commit from about 2-3 years ago which introduced it, and even found how to
> disable it, but for the life of me I couldn't find it again during my most
> recent searches.
> How can I disable the debug optimizations, and I mean completely?
> 
You disable it with -no-optimize-debug on the configure line

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebEnginePage acceptNavigationRequest leads to empty page

[Allan Sandfeld Jensen]

On Montag, 28. Januar 2019 13:11:45 CET Sven Bergner wrote:
> Hi there,
> I have an app that uses QWebEngine to show a webpage that has a link to a
> pdf document.
> Now I want to handle a click on that link by
> implementing QWebEnginePage::acceptNavigationRequest().
> The method is called an I can check if the link leads to a pdf and if so I
> handle the url by myself and return false. The downside is that the
> QWebEngineView now shows an empty page.
> Is there any way to prevent this? I want to stay on the same page where the
> link was clicked.
> Any hints?
> 
Try disabling error-pages, with error-pages disabled, errors should result in 
staying on the same page, where with them enabled, navigations always go 
somewhere.

Still sounds like an error, navigation should either not be performed or go an 
error-page.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[Allan Sandfeld Jensen]

On Dienstag, 13. November 2018 07:50:12 CET coroberti . wrote:
> > > Il 11/11/18 17:15, coroberti . ha scritto:
> > > > Following Allan's advise, here's something that is starting to work
> > > > (checks omitted)
> > > > 
> > > > QTextDocument* doc = this->text_edit_->document();
> > > > QTextBlock currentBlock = doc->firstBlock();
> > > > 
> > > >  while (currentBlock.isValid()) {
> > > >  
> > > >  QTextCursor cursor(currentBlock);
> > > >  QTextBlockFormat blockFormat = currentBlock.blockFormat();
> > > >  blockFormat.setLineHeight(200,
> > > >  QTextBlockFormat::ProportionalHeight);
> > > >  cursor.setBlockFormat(blockFormat);
> > > >  
> > > >  currentBlock = currentBlock.next();
> > > >  
> > > >  }
> > > > 
> > > > Thank you very much!
> > > 
> > > Isn't it simpler to use a selection approach instead?
> > > 
> > > QTextBlockFormat format;
> > > format.setLineHeight(...);
> > > 
> > > QTextCursor cursor(textDocument);
> > > cursor.select(QTextCursor::Document);
> > > cursor.mergeBlockFormat(format);
> > > My 2 c,
> > > --
> > > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> 
> Thanks, Guiseppe. It also works properly.
> 
> Thanks, Allan.
> So, there are two good ways from the API point of view.
> 
> When HTML from QTextEdit is retrieved by toHtml(), it generates HTML
> with the correct line-height, i.e. 200% as in the example below:
> 
> 
> 
> It's properly treated by browsers, etc.
> 
> However, when saved to an html file and next loaded to QTextEdit,
> line-height attribute inside  tag is ignored.
> This page doesn't refer to line-height as to the supported attributes:
> http://doc.qt.io/qt-5/richtext-html-subset.html#block-attributes
> 
> Is it correct to say that this is not a bug but rather an expected behavior,
> and bug report is not required for this case?
> Thanks.
> 
No I would argue it is a bug, and it is also a bug that line-height is not 
listed as a supported property, we are parsing it after all. And if we cant 
parse what we write outselves that is pretty silly.

'Allan



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[Allan Sandfeld Jensen]

On Sonntag, 11. November 2018 16:13:12 CET coroberti . wrote:
> On Sun, Nov 11, 2018 at 5:06 PM Allan Sandfeld Jensen  
wrote:
> > On Sonntag, 11. November 2018 14:11:52 CET coroberti . wrote:
> > > Hi,
> > > It seems that arranging line spacing for text in QTextEdit (like 1.5,
> > > 2, 3 lines) is not an easy coding.
> > > 
> > > Any code samples, directions, howtos would be very much appreciated.
> > 
> > There is probably a way to get to the default or root QTextBlockFormat and
> > set lineHeight on it, but I couldn't spot the logical way from QTextEdit
> > either; but you can always just do it in CSS and set the CSS as the
> > default style- sheet on the document the QTextEdit is showing. Remember a
> > QTextEdit is basically showing HTML, so you can do it like you would in
> > HTML.
> > 
> > 'Allan
> 
> Hi Allan,
> Thanks, but It seems that only this HTML/CSS subset is supported:
> 
> http://doc.qt.io/qt-5/richtext-html-subset.html
> 
Right, line-height isn't mentioned there, but considering the C++ side of the 
CSS implementation (QTextBlockFormat) has it, it might just have left out. I 
would give it a shot.

'Allan



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Development] QTextEdit - Line Spacing

[Allan Sandfeld Jensen]

On Sonntag, 11. November 2018 14:11:52 CET coroberti . wrote:
> Hi,
> It seems that arranging line spacing for text in QTextEdit (like 1.5,
> 2, 3 lines) is not an easy coding.
> 
> Any code samples, directions, howtos would be very much appreciated.
> 
There is probably a way to get to the default or root QTextBlockFormat and set 
lineHeight on it, but I couldn't spot the logical way from QTextEdit either; 
but you can always just do it in CSS and set the CSS as the default style-
sheet on the document the QTextEdit is showing. Remember a QTextEdit is 
basically showing HTML, so you can do it like you would in HTML.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QWE hacking: "backporting" src/3rdparty/chromium?

[Allan Sandfeld Jensen]

On Mittwoch, 7. November 2018 15:09:40 CET René J.V. Bertin wrote:
> Hi,
> 
> Out of curiosity, how feasible would it be to deploy a more up-to-date
> QtWebEngine on a system that's stuck on an older Qt version. I understood
> from a previous exchange that QWE is much more a "thin wrapper" around the
> actual web engine than QtWebKit is, with the intention of making it easier
> to upgrade that component. If so, it might be possible to replace the
> src/3rdparty/chromium directory from, say, 5.8.0 with the one from 5.9.7
> and get things to build with only minimal patching.
> 
You should be able to compile QtWebEngine 5.9.7 against Qt 5.8. We dont test 
that, but we do test QWE 5.9 against Qt 5.6, so it has a good chance of 
working.

Note however that newer QtWebEngine comes with the same platform limitations 
regardless of what Qt they are built against as QWE always have harder 
limitation due to limits in what upstream Chromium supports building on

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] update on building Qt/Linux with clang?

[Allan Sandfeld Jensen]

On Montag, 5. November 2018 20:33:58 CET René J.V. Bertin wrote:
> On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
> >In my experience clang generates significantly more compact binaries
> 
> Quite: bzipped tarballs of everything except the examples, translations,
> QWE, QtWebView and Qt3D:
> 
> -rw-r--r-- 1 root root 363M Sep  8 13:22
> qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
> -rw-r--r-- 1 root root 199M Nov  5 19:22
> qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)
> 
> The first built with GCC 8, the 2nd with clang 6.0; identical compiler
> options (release build, -O3, force_debug_info for qtbase).
> 
Enable -lto/ltcg if you want smaller binaries, and -optimize-size if you don't 
mind losing a bit a performance for it.

Also enable -separate-debug-info. The executable results of the two compilers 
are very identical in size, or is mainly the debug-info that varies so much in 
size.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] update on building Qt/Linux with clang?

[Allan Sandfeld Jensen]

On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote:
> I tried building everything with clang 7 and libc++ last week but hit a
> qlalr segfault during build. I've been trying to debug it ever since to no
> avail.
> 
> 
clang sometimes segfaults while compiling, the crash usually goes if I try 
again. It seems to just randomly crash once for every ~10 thousand files 
compiled for no reason. The fact the crashes are random and not stable doesn't 
really raise my confidence in clang code quality though, but it is easy to 
work around. Just keep calling make until it makes it.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] update on building Qt/Linux with clang?

[Allan Sandfeld Jensen]

On Montag, 5. November 2018 12:03:31 CET René J.V. Bertin wrote:
> Hi,
> 
> Last time I asked the advice was still not to bother with trying to build
> (all of) Qt with clang on Linux. Is that still the case or is it now safe
> to use clang (5 or 6)?
> 
> In my experience clang generates significantly more compact binaries, which
> should reduce load times. Build time should be shorter too.
> 
I build all of Qt regularly with clang to make sure qtwebengine works like 
that, and I have never had any issues. You can even use clang-libc++ if you 
make sure not to depend on any system C++ libraries.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bug Reports

[Allan Sandfeld Jensen]

On Montag, 22. Oktober 2018 21:37:01 CEST Dan Allen wrote:
> Hi All,
> 
> I'm frustrated by what has happened on the last bug report
>  I posted yesterday.
> 
> Why would this get closed in this way so quickly? Could there not have
> been a comment just saying "Did you make an error with the test case?"
> before closing it? And then give me 24 hours to respond perhaps?
> 
> I'm trying to help improve Qt. I don't see how closing the bug for this
> reason in that time is doing the same.
> 
Yes, sounds like it should have been set in needsmoreinfo instead of being 
closed. I was to guess as to why it was closed it would be because it looked 
like a "support case", someone making a programming mistake and then blaming 
everybody but themselves and opening a bug to get help fixing it. That 
unfortunately happens... Though personally I prefer waiting a few days before 
closing issues like that, but mistakes happens.

Best regards
'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Porting Qt to our RTOS

[Allan Sandfeld Jensen]

On Freitag, 28. September 2018 00:20:37 CEST Kim Hartman wrote:
> Thanks Tuuka (and others), 
> 
> We've ported much of the BOOST libraries, so pthreads are most possible.
> I've started an internal audit of the rest of POSIX services we would need
> in order to create an INtime QPA. Is there a more comprehensive list of
> POSIX calls needed for GUI functionality? Is there such a thing as a
> generic QPA?
 
As Thiago said Posix is for the core stuff not for the GUI, though it is more 
than filesystem and network, the core eventloop needs a unix poll(), or a port 
of glib. For a gui you just need some way of reading input and for rendering 
output. If you support libinput for instance the first part is covered, but 
you can also do your own thing, and the second just means we need a API for 
opening and writing to a framebuffer and perhaps tell the system when it 
should flip/sync the buffer. Getting the graphics working is almost the 
simplest part.

Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Linux openssl 1.1.0 versus 1.0.X

[Allan Sandfeld Jensen]

On Sonntag, 16. September 2018 12:14:28 CEST Roland Winklmeier wrote:
> Christophe Thomas  schrieb am So., 16. Sep. 2018,
> 
> 10:41:
> > Hello,
> > 
> > From the comment of Giuseppe I understand that we could go with just a
> > package installation. I've an ubuntu 18.04 (not installed from scratch but
> > from an upgrade of 16.04). When I look in /usr/lib/x86_64-linux-gnu/, I
> > have several libssl
> > => libssl.so (symlink to libssl.so.1.1)
> > => libssl.so.1.1
> > => libssl.so.1.0
> > I can also see a folder: /usr/lib/x86_64-linux-gnu/openssl-1.0.0
> > 
> > This is consistent with the fact that I have following packages:
> > libssl-dev/bionic-security,bionic-updates,now 1.1.0g-2ubuntu4.1 amd64
> > libssl1.0.0/bionic-security,bionic-updates,now 1.0.2n-1ubuntu5.1 amd64
> > libssl1.1/bionic-security,bionic-updates,now 1.1.0g-2ubuntu4.1 amd64
> > 
> > Event then I still get the SSL error in Qt:
> > Several : qt.network.ssl: QSslSocket: cannot resolve and finaly
> > then : qt.network.ssl: Incompatible version of OpenSSL
> > and several : qt.network.ssl: QSslSocket: cannot call unresolved function
> > 
> > I've tryed to modify the symlink to have libssl.so => libssl.so.1.0 but it
> > didn't do the trick.
> > 
> > How do you think I can make my Qt app find the right SSL lib ?
> > 
> > Chris
> 
> Hi Chris,
> 
> I ran into the same problem the other day. Qt is loading openssl
> dynamically at runtime. This is failing on many newer platforms now since
> they usually have symlinks pointing to openssl 1.1 as it is on your case. I
> do not recommend to change the system symlinks since that has impact an all
> your distribution binaries with huge negative impact.
> The only workaround I could find without modifying the system path was to
> add symlinks in my applications path (or any other) and add that directory
> to the LD_LIBRARY_PATH environmental variable. This way Qt found and loaded
> openssl 1.0 without issues. The workaround is still annoying since one had
> to add wrapper scripts.
> 
> Ideally Qt would load any version at runtime. So far it's a compile time
> decision only. Would it be possible to built support for both? If that's
> not possible, it should try to load the versioned binaries (e.g
> libssl.so.1.0) first and only if not available fall back to the unversioned
> library name. This should avoid conflicts like this.
> 
No, it is not possible to support both without a lot of work, and since the 
problem will go away soon, it is not worth it. Loading libssl.so.1.0 before 
trying libssl.so might work though, at least if any distros exist with both 
libraries.

Alternatively link to libssl instead of loading it as runtime, I believe that 
is still a configure option.

'Allan



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Macro to identify desktop(Ubuntu-X86) and embedded Linux(ARM)

[Allan Sandfeld Jensen]

On Samstag, 8. September 2018 22:56:29 CEST Thiago Macieira wrote:
> On Saturday, 8 September 2018 11:56:45 PDT Tomasz Olszak wrote:
> > So as well you can to it in runtime and don't need macro.
> 
> Better yet, don't do anything. Use the font that the user configured and
> don't override. If you don't like the font, use your desktop's font
> changing tool to make the customisation.

And getting the system default fonts can be a bit tricky, but it is done like 
this:

QFontDatabase db; // needs to be instantiated at least once first
QFont defaultFont;
defaultFont.setStyleHint(QFont::SansSerif);
defaultFont = QFont(defaultFont.defaultFamily()));

You have to use QFont first as a query to query the default, and then you can 
set the default name to get the actual default font. This is because 
QFont::StyleHint generally isn't working well cross-platform, and it is also 
not quite clear what it is supposed to do in general font queries, but it can 
query default font families like this.

I might have cleaned parts of this up so it is less error-prone, but this
is at least the old standard incantation for font defaults.

'Allan




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Metal-accelerated QPainter on macOS with MoltenGL?

[Allan Sandfeld Jensen]

On Samstag, 25. August 2018 01:23:57 CEST Adam Twardoch (Lists) wrote:
> 
> But is this easily possible?
> 
I would guess so, it is probably a matter of loading the right OpenGL libary.

I don't have a Mac new enough to support Metal so I can't test, but I would 
try to figure out how Qt loads the OpenGL libary, and make sure it picks up 
MoltenGL instead, or just link to it.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Drawing slow.

[Allan Sandfeld Jensen]

On Samstag, 18. August 2018 17:03:43 CEST william.croc...@analog.com wrote:
> On 08/17/2018 02:36 PM, Bill Crocker wrote:
> > Hello:
> > 
> > My newer, Qt based drawing program takes orders of magnitude longer to
> > draw lines than my good old plain X-Windows based drawing program.
> > 
> > The Qt call stack, as revealed by VTune, is:
> > 
> > QPainterPath::draw
> > QPaintEngineEx::draw
> > QRasterPaintEngine::stroke
> > QPaintEngineEx::stroke
> > QRasterPaintEngine::fill
> > QRasterizer::rasterize
> > QScanConverter::end
> 
>  From some experimentation it appears that the CPU time required by the
> QPainterPath system is quite non-linear in the number of control points.
> So, if I break my one long path up into a number of shorter paths, it
> draws MUCH faster.
> 
Is that the case with both antialiasing on and off? (They use different 
rasterization backends)

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

[Allan Sandfeld Jensen]

On Dienstag, 31. Juli 2018 14:02:23 CEST Christian Gagneraud wrote:
> On 31 July 2018 at 23:45, Allan Sandfeld Jensen  wrote:
> >
> > The question was: Do you want security fixes or not? The reason it was
> > done is because we have upped our game on security fixes in webengine.
> 
> Can't you just backport security fixes, eg like Debian and OpenBSD do?

Debian does not do that. They update ALL of chromium for every single update, 
even on the stable branch, because they don't have the manpower to backport 
security patches, and because backporting patches has severe limitations, 
especially for a full chromium browser as opposed to our subset of it. In fact 
no Linux distro does backports of security patches for Chromium, they have all 
given up.

`Allan




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

[Allan Sandfeld Jensen]

On Dienstag, 31. Juli 2018 13:32:38 CEST Christian Gagneraud wrote:
> On 31 July 2018 at 21:43, Allan Sandfeld Jensen  wrote:
> > On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
> >> Hi,
> >> 
> >> We used to build Qt-5.6.3 on and for Linux-i386.
> >> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
> >> fails with:
> >> 
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
> >> In function 'ssl3_ChaCha20Poly1305':
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:
> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
> >> member named 'pIv'
> >> 
> >>  aeadParams.pIv = (unsigned char *) additionalData;
> >>  
> >>^
> >> 
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:
> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
> >> member named 'ulIvLen'
> >> 
> >>  aeadParams.ulIvLen = 8;
> >>  
> >>^
> >> 
> >> Are there any special requirements,or actually is there a difference
> >> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
> > 
> > Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption
> > and certicate checking but in 5.6.3 is only used for certificate
> > checking. You can try using NSS 3.21, but note it will report most Google
> > certificates as broken. You can also try removing libnss-dev in which
> > case OpenSSL will be used for both, but that also means most Google
> > certicates are reported as broken (because they objectively are signed by
> > a too weak root).
> 
> Thanks for all the details, greatly appreciated. I'll have to dig that
> further, will report.
> 
> > See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry
> > pick it, though it might not be easy QtWebEngine also upgraded from
> > Chromium 45 to 49 in the 5.6 series.
> 
> What can I say other than:
> Should this (Chromium 45 -> 49) be part of "patch" release?

The question was: Do you want security fixes or not? The reason it was done is 
because we have upped our game on security fixes in webengine.

Note 5.6.2 was the first and so far only time we have done this in a patch 
release, and I don't think it was worth the trouble. Since then I have 
prefered to recommend people using a more modern qtwebenigne with older 
qtbase. Note for instance, you can use up to QtWebEngine 5.9.x with the rest 
of Qt being 5.6. In fact if you use QtWebEngine on potentially hostile 
content, I would strongly recommend it as Qt 5.6.x is not updated as 
regularly.

In fact using a newer QtWebEngine even if just the last one from 5.6.x with 
qtdeclarive being 5.6.0, might solve your problems.

> To the point that now the "Qt Maintenance Tool" offers you to install
> different patch release, like nobody trust they are actually
> equivalent and ABI backward compatible as they used to be...

I don't think that is fair. I know there has been a few mistakes, but they 
have usually been corner cases. When every other C++ project broke ABI due to 
C++11 Qt was able to maintain it due to how serious we have always taken it. 
But yes, you should always check if things still work when upgrading.

Best Regards
'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

[Allan Sandfeld Jensen]

On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
> Hi,
> 
> We used to build Qt-5.6.3 on and for Linux-i386.
> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
> fails with:
> 
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
> In function 'ssl3_ChaCha20Poly1305':
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:15:
> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
> named 'pIv'
>  aeadParams.pIv = (unsigned char *) additionalData;
>^
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:15:
> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
> named 'ulIvLen'
>  aeadParams.ulIvLen = 8;
>^
> 
> Are there any special requirements,or actually is there a difference
> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
> 
Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption and 
certicate checking but in 5.6.3 is only used for certificate checking. You can 
try using NSS 3.21, but note it will report most Google certificates as 
broken. You can also try removing libnss-dev in which case OpenSSL will be 
used for both, but that also means most Google certicates are reported as 
broken (because they objectively are signed by a too weak root).

See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry pick 
it, though it might not be easy QtWebEngine also upgraded from Chromium 45 to 
49 in the 5.6 series.

'Allan




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Why no T& QVariant::value()?

[Allan Sandfeld Jensen]

On Montag, 4. Juni 2018 09:00:28 CEST Giuseppe D'Angelo wrote:
> Il 23/05/2018 16:16, Jason H ha scritto:
> > Really wishing this function existed. Can someone explain why it doesnt'
> > exist?
> Because QVariant (as well as most Qt APIs) has wide contracts; combined
> with the policy of not using exceptions, that makes such a function
> impossible to implement.
> 
Actually it probably could be, but it would be ugly, we already do something 
similar for QJsonValues, though on a more limited scope. And depending on what 
you want from it, it might need to be type strong and templated for a specific 
type T.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QImage + pixel lambdas

[Allan Sandfeld Jensen]

On Freitag, 1. Juni 2018 15:38:03 CEST Jason H wrote:
> So I'm doing some qimage analysis/manipulation. I think it would be really
> good if QImage came with a per-pixel function. (Examples below) I'm tired
> of writing the x/y for loops. The really neat thing (not in the examples)
> is using QImage::scanLine(int y) for faster access, and automatically
> choosing the value of p in the lambda based on bit depth.
> 
> Anyone else think this is a good idea?
> 
I would strongly advise the templates use scanLine or raw pointer access. 
Going through the pixel() methods is rather slow. To get any kind of 
performance out of this the whole things need to be inlinable at compile time, 
images are just big that pixel transformations almost always need to consider 
performance (just a 1000x1000 image has 1 million pixels, which is a lot 
bigger than most arrays or lists we usually iterate over).

But providing some helpful templates to cut down on boilerplate code would 
probably not be a bad idea. Check for instance qimage_conversions.cpp for 
function after function with the same boiler-plate shape and a different inner 
conversion method. If you want to try you could try making a private template 
first and cut down on the boiler-plate code there first, and then we can 
discuss it, and consider making it public?

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] HDR 10/ HDR Dolby support?

[Allan Sandfeld Jensen]

On Dienstag, 15. Mai 2018 19:48:03 CEST Boudewijn Rempt wrote:
> On dinsdag 15 mei 2018 19:00:53 CEST Allan Sandfeld Jensen wrote:
> > They only way I know of doing that at all at the moment is on Windows and
> > only using fullscreen mode, and the monitor probably only supports it
> > though HDMI. We are missing the proper standards for mixing HDR and SDR
> > content, and for Linux, we lack the GLX, X11, Wayland and OpenGL
> > standards,
> > though in theory you can do it through EGL, but I haven't found support
> > for
> > it, so I haven't been able to tell how it would work and how we should use
> > it.
> 
> Yes... That's one thing I was wondering about. I am getting a lot of push
> towards creating an HDR image authoring application (like Krita), but not a
> lot of details on how this would work and with which technologies.
> 
> > Btw, if you have HDR support in Krita, how do you handle the difference
> > between relative SDR colors (0-1.0) and absolute HDR colors (0-12.0)? Do
> > you have a color wheel that allows for the imaginary colors HDR uses
> > (whiter than white, bluer than blue).
> 
> Well... Those float numbers don't really mean much. It's a matter of
> scaling, and people in the VFX world I've been talking to author HDR images
> in Nuke or Natron with any scale, and then tone-map to 0..1.0, which is
> still HDR, because it represents a scale wider than SDR images.
> 
Yes, but that is old style HDR with just higher color-space resolutoin. The 
weird thing about the new HDR that we have in new HDR screens is this concept 
of colors beyond the otherwise brightest white. Imagine you set the brightest 
white you can have on the screen while still being comfortable to look, at 
(1.0,1.0,1.0) and then you can have white whiter than that for special 
effects. That is the new HDR. So a combination of higher color resolution a 
new color-space and "imaginary" colors above the otherwise maximum brightness, 
this makes perfect sense for 3D light effects but not much else, which is 
while I find it cool am not entirely sure what it would be good for in our 
case.

In theory you could just turn up the maximum brightness and use the extra 
resolution to reserve part of the scale, but that is not how the new HDR 
standards are operating. As far as I know photo and image HDR works more 
classically and doesn't require as much special support. You could just use 
OpenGL with FP16, many drivers support that, and more are adding it recently, 
though we don't have good interaction with it in Qt. If you need better 
support of that classic HDR, it should be easy to add, just say what you are 
using. At least we should be able to output it as RGB30 or OpenGL.

best regards
'Allan



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] HDR 10/ HDR Dolby support?

[Allan Sandfeld Jensen]

On Dienstag, 15. Mai 2018 18:05:04 CEST Boudewijn Rempt wrote:
> On dinsdag 15 mei 2018 18:00:04 CEST Allan Sandfeld Jensen wrote:
> > On Dienstag, 15. Mai 2018 12:21:53 CEST Boudewijn Rempt wrote:
> > > Hi,
> > > 
> > > I'm wondering, is there any work going to support HDR 10 or HDR Dolby
> > > from
> > > within Qt, directly or through OpenGL? Has anyone tried something like
> > > that?
> > 
> > That is a TV format. What do you want Qt to do with it?
> 
> It's also a monitor format: the Lenovo Yoga X1 3rd gen has a Dolby HDR
> panel. What I want to do it make it possible to paint HDR images in Krita
> without having to tonemap to an SDR panel, if they have hardware like this.

They only way I know of doing that at all at the moment is on Windows and only 
using fullscreen mode, and the monitor probably only supports it though HDMI. 
We are missing the proper standards for mixing HDR and SDR content, and for 
Linux, we lack the GLX, X11, Wayland and OpenGL standards, though in theory 
you can do it through EGL, but I haven't found support for it, so I haven't 
been able to tell how it would work and how we should use it.

Btw, if you have HDR support in Krita, how do you handle the difference 
between relative SDR colors (0-1.0) and absolute HDR colors (0-12.0)? Do you 
have a color wheel that allows for the imaginary colors HDR uses (whiter than 
white, bluer than blue).

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] HDR 10/ HDR Dolby support?

[Allan Sandfeld Jensen]

On Dienstag, 15. Mai 2018 12:21:53 CEST Boudewijn Rempt wrote:
> Hi,
> 
> I'm wondering, is there any work going to support HDR 10 or HDR Dolby from
> within Qt, directly or through OpenGL? Has anyone tried something like that?

That is a TV format. What do you want Qt to do with it? I have solutions in 
mind once we have proper monitor and graphics standards for HDR, but so far 
the only thing that exist is scRgb on windows through DirectX, and a EGL 
standard for the same, that I haven't found anything implementing, and no 
general OpenGL or GLX standards yet. One of the problems seems to be there is 
no hardware with HDR support in RGB-mode, the only output modes with HDR are 
all TV modes, and thus HDR hardware are all TVs and not monitors.

'Allan



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Allan Sandfeld Jensen]

On Dienstag, 6. März 2018 17:44:19 CET Allan Sandfeld Jensen wrote:
> On Dienstag, 6. März 2018 16:50:23 CET Nuno Santos wrote:
> > Mitch,
> > 
> > Thanks for your reply.
> > 
> > You are right. I’m not playing all the cards…
> > 
> > Original image attached (it is white over transparent so you will not see
> > it in the email body. The file is called isotope.png)
> 
> Looks like you dont have antialiasing enabled. It is a good idea in general.
> Just add the line "antialiasing : false" to the rendered item.
> 
I meant 'antialiasing: true' of course. Looks like it is indeed  off by 
default 
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html#antialiasing
 and that will result in terrible scaled images.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to render small Images decently on non retina displays with QtQuick?

[Allan Sandfeld Jensen]

On Dienstag, 6. März 2018 16:50:23 CET Nuno Santos wrote:
> Mitch,
> 
> Thanks for your reply.
> 
> You are right. I’m not playing all the cards…
> 
> Original image attached (it is white over transparent so you will not see it
> in the email body. The file is called isotope.png)
> 
Looks like you dont have antialiasing enabled. It is a good idea in general. 
Just add the line "antialiasing : false" to the rendered item.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QImage detect full transparent

[Allan Sandfeld Jensen]

On Sonntag, 25. Februar 2018 21:35:41 CET maitai wrote:
> Just what I was looking for. I already live with using qt private stuff
> 
Though if you want to check for only fully transparent pixels, and not just 
some, it might be faster to do just do a memory compare against null. That 
should be reasonable fast and optimized.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QImage detect full transparent

[Allan Sandfeld Jensen]

On Sonntag, 25. Februar 2018 20:23:32 CET maitai wrote:
> Hello,
> Seems quite basic, but I need a **fast** way to know if a QImage is just
> full transparent. I know the size in advance (256x256). If it were a
> QPixmap I would use cacheKey() and compare with the cacheKey of a full
> transparent image. For a QImage I can compare it with a preset
> transparent image, or extract the alpha channel, or etc of course. But I
> need a really fast way.
> 
> Any idea?
> 
There is a private API for that which QPixmap uses 
QImageData::checkForAlphaPixels() can be accessed via QImage::d_ptr()-
>checkForAlphaPixels(). 

Of course being private API there is not guarantee it will keep working, and 
if you use it you might not be able to link with newer Qt versions.

You can ofcourse also just look at the code in qimage.cpp and do something 
similar.

`Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QWebView vs. QWebEngine

[Allan Sandfeld Jensen]

On Montag, 29. Januar 2018 14:57:50 CET Walter Stefan wrote:
> Hi,
> 
> I've done some research about QWebView and QWebEngine and came to the
> following conclusion:
> 
> QWebView is under GPL and uses internally WebKit.
> QWebEngine is under LGPL and uses internally Chromium.
> 
Be careful with the names ;) You are thinking of QtWebKit and QtWebEngine. Qt 
also has a module called QtWebview which wraps native webviews on iOS and 
Android and WebEngine on other platforms.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] font smoothing gamma changes in Qt 5.9?

[Allan Sandfeld Jensen]

On Donnerstag, 21. Dezember 2017 12:02:21 CET René J.V. Bertin wrote:
> Hi,
> 
> Well, it's confirmed: I was seeing the same "watery" rendering on certain
> fonts under Linux/X11 using Freetype+Infinality (still on 2.6.5 on Linux;
> Mac has 2.7.1 with the same patches). I need a font smoothing gamma of 0.95
> to get the font colour I had with Qt 5.8 across all fonts I tested. Which
> means that font rendering quality is still leagues ahead of what you get
> without those patches: better than the Mac font rendering quality in any
> case (on "normal" displays).
> 
> Again, the Novarese family is the one I use that's most affected. I don't
> really get why other fonts aren't affected (and still look about the same
> with the tweaked smoothing gamma). The up-to-date Infinality patches are
> here, if you're interested to see if they do anything that interacts with
> your new rendering approach: https://github.com/archfan/infinality_bundle
> 
> 
> I take it you checked the new rendering with those older Freetype versions?
> 
It only affects newer versions of freetype, I believe 2.6.2 introduced the 
setting.

Note newer versions of freetype (since 2.7) already include the most of the 
infinality changes as a runtime option. 

It is possible something else changed for you. The stem-darkening and gamma-
correcting if gone wrong, would either make text look paler or bolder, but not 
blurry, blurry sounds lcd-filtering or subpixel positioning changing.

'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] building Qt 5.9 on Linux - clang or GCC?

[Allan Sandfeld Jensen]

On Mittwoch, 20. Dezember 2017 18:32:16 CET Konstantin Tokarev wrote:
> 20.12.2017, 20:17, "René J. V. Bertin" :
> > Thiago Macieira wrote:
> >>  A Qt release build builds with -g1 instead of -g, which should be
> >> sufficient for backtraces but not for debugging.
> > 
> > That's interesting, the option doesn't show up in g++ --verbose --help so
> > I
> > wasn't aware it existed.
> 
> With GCC, you should better read man.
> With Clang you should better read --help :)
> 
With gcc either use "info", or google "gcc manual" and read the online manual 
which is the same as the info pages. ;)

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] font smoothing gamma changes in Qt 5.9?

[Allan Sandfeld Jensen]

On Dienstag, 19. Dezember 2017 19:51:40 CET René J. V. Bertin wrote:
> Hi,
> 
> Has something changed to the font smoothing gamma algorithm used with
> libfreetype in Qt 5.9?
> 
Yes. OpenType CEF fonts are now stem-darkening and rendered gamma-corrected, 
similarly to what CoreText would do. The result should be almost imperceptible 
with black on white, but produce sharper text with white on black that now has 
the same boldness as black on white has.

Unless something in Mac/freetype custom configuration interferes that is.

Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] building Qt 5.9 on Linux - clang or GCC?

[Allan Sandfeld Jensen]

On Montag, 18. Dezember 2017 20:55:42 CET René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It doesn't, because the debug information is not loaded in the first
> > place.
> > When using readelf, note how the "A" flag is missing for those sections.
> 
> So it has to skip certain, possibly considerable parts of the file while
> loading it, rather than simply doing some efficient operation to copy the
> whole file into memory. That should affect load times somewhat, no?
> 
> > One more reason to use GCC. It only builds once, even under LTO, unless
> > you
> > specifically ask for the fat LTO objects.
> 
> Yet even with GCC the build times and memory requirements are larger with
> LTO than without. How can it not do certain things twice?
> 
It uses more memory because the compiler effectively works on all the source 
files at once during the linking phase, so it needs to hold all of files 
decoded in memory at the same time. It is not really much slower anymore 
though. It used to be slower because the final compilation was all in a single 
process and single threaded, but that part is now multithreaded. Now it is 
only slower if you dont have enough memory.

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] building Qt 5.9 on Linux - clang or GCC?

[Allan Sandfeld Jensen]

On Montag, 18. Dezember 2017 15:38:20 CET René J.V. Bertin wrote:
> Hi,
> 
> Not to start a flame war, but are there clear differences between building
> Qt (on Linux) with clang (5.0) vs. GCC (7.2) that make the one or the other
> a better choice for certain domains of application?
> 
> Link-time optimisation is out of the question (too costly on my hardware,
> which is also why I can't really do a comparison). I'm not expecting much
> performance difference, so build time (cum memory requirements) and
> installation size can tip the scales for me.
> 
It is pretty much the same. I would recommend gcc because that is default on 
Linux and the most likely to compile warning free and support most 
configurations. Clang works almost entirely the same everywhere, but sometimes 
it has different warnings that breaks developer builds or peculiar bugs on in 
some obscure corner-case that causes a compile error in one late module 
somewhere (not that gcc don't have those too, but being default, we have 
already had to work around those).

Btw. LTO isn't that insane these days, In shared Qt builds we don't not let 
the LTO work across shared libraries, so it is only performed within each 
library, which gives almost all the benefits and none of the problems. 
Especially if you want smaller binaries ltcg + optimize_size gives great 
results.

'Allan

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Performance comparison of painting methods

[Allan Sandfeld Jensen]

On 13.11.2017 17:12, Jean-Michaël Celerier wrote:


http://kgronholm.blogspot.fr/2017/11/qt-510-qml-shape-testing.html

An interesting blog post which compares QPainter, the upcoming QML 
Shapes and QNanoPainter. I'm surprised to see QML Shapes perform so 
much slower than good old QPainter.



Doesn't QML Shapes depend on the NVIDIA only GL-extension for shapes? I 
am assuming it is just falling back to raster QPainter instead of FBO 
QPainter when not present.


'Allan

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chrome version in QT

[Allan Sandfeld Jensen]

On Donnerstag, 2. November 2017 13:18:23 CET Sudhir Sharma wrote:
> Hi,
> 
> Is there any way to upgrade QT Chrome version, instead of moving to entirely
> new QT release?
> 

You can build qtwebengine with an older Qt. For instance QtWebEngine 5.9 
builds with Qt 5.6, 5.8 and 5.9

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Whats the new openssl lib version to link Qt 5.10 against?

[Allan Sandfeld Jensen]

On Freitag, 27. Oktober 2017 11:56:54 CEST Nuno Santos wrote:
> Hi,
> 
> I was building Qt 5.8 from the source linking with openssl 1.0.2j
> 
> Yesterday I started building Qt 5.10 but it is not linking against 1.0.2j
> 
> I’m not sure if this is if this is due to a new required openssl version or
> because of some building problems.
> 
> Does the required openssl version changed for Qt 5.10?
> 
No. Qt 5.10 can now link against either openssl 1.0 or openssl 1.1. But note 
they are not binary compatible, so it is only one of them, and configure needs 
to pick up the right one or the compile will fail.

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] File Dialog in WebEngine

[Allan Sandfeld Jensen]

On Montag, 23. Oktober 2017 13:50:51 CEST Sudhir Sharma wrote:
> Hi,
> 
> In 5.9.2, when we try to invoke File Dialog from html loaded in WebEngine,
> it does not get open. If the same url is opened in web browser, it works.
> 
> Any idea?
> 

How are you trying to invoke it from HTML?

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Do I need widevinecdmadapter.so to watch Netflix, Prime etc.?

[Allan Sandfeld Jensen]

On Donnerstag, 5. Oktober 2017 22:25:23 CEST Allan Sandfeld Jensen wrote:
> On Donnerstag, 5. Oktober 2017 21:45:34 CEST Jan Neumann wrote:
> > Hi,
> > 
> > I am on Archlinux.
> > We have packages in AUR which should provide widevine, one of them
> > especially for
> > [qt5-webengine](https://aur.archlinux.org/packages/qt5-webengine-widevine/
> > )
> > . Generally they get the [widevine
> > component](https://dl.google.com/widevine-cdm/1.4.8.1008-linux-x64.zip)
> > and
> > copy the content (libwidevinecdm.so) to / usr/lib/chromium. So far so
> > good...
> > If i have chromium installed alongside e.g. Qupzilla i can watch netflix
> > with qupzilla very well. but if i remove chromium i ran in issues:
> > widevine- component not found.
> > So, with removing chromium i also remove libwidevinecdm**adapter**.so from
> > / usr/lib/chromium.
> > I searched the web and contacted the maintainer, but no clear statement.
> > I guess qt5-webengine needs both **libwidevinecdmadapter.so and
> > libwidevinecdm.so** to work properly.
> > 
> > Can someone of the devs please confirm...
> 
> You you need both. One is just a plugin wrapper for the other. So
> libwidevinecdmadapter.so is what Chrome and QtWebEngine talks to, the PPAPI
> plugin, but libwidevinecdm.so is the shared library with all the crucial DRM
> functionality.
> 
Btw. For all the details see 
http://blog.qt.io/blog/2016/06/03/netflix-qt-webengine-5-7/

I mentions both libraries, and how to get Chrome to download them and where to 
find them. Though for end-users just getting Chrome to download them is 
enough, QtWebEngine will look for them where Chrome puts them.

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Do I need widevinecdmadapter.so to watch Netflix, Prime etc.?

[Allan Sandfeld Jensen]

On Donnerstag, 5. Oktober 2017 21:45:34 CEST Jan Neumann wrote:
> Hi,
> 
> I am on Archlinux.
> We have packages in AUR which should provide widevine, one of them
> especially for
> [qt5-webengine](https://aur.archlinux.org/packages/qt5-webengine-widevine/)
> . Generally they get the [widevine
> component](https://dl.google.com/widevine-cdm/1.4.8.1008-linux-x64.zip) and
> copy the content (libwidevinecdm.so) to / usr/lib/chromium. So far so
> good...
> If i have chromium installed alongside e.g. Qupzilla i can watch netflix
> with qupzilla very well. but if i remove chromium i ran in issues:
> widevine- component not found.
> So, with removing chromium i also remove libwidevinecdm**adapter**.so from /
> usr/lib/chromium.
> I searched the web and contacted the maintainer, but no clear statement.
> I guess qt5-webengine needs both **libwidevinecdmadapter.so and
> libwidevinecdm.so** to work properly.
> 
> Can someone of the devs please confirm...
> 
You you need both. One is just a plugin wrapper for the other. So
libwidevinecdmadapter.so is what Chrome and QtWebEngine talks to, the PPAPI 
plugin, but libwidevinecdm.so is the shared library with all the crucial DRM 
functionality.

\Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtWebEngine on i.MX6 eglfs

[Allan Sandfeld Jensen]

On Mittwoch, 16. August 2017 17:33:32 CEST Christian Kandeler wrote:
> On Wed, 16 Aug 2017 16:46:09 +0200
> 
> Allan Sandfeld Jensen <k...@carewolf.com> wrote:
> > On Mittwoch, 16. August 2017 11:06:26 CEST Christian Kandeler wrote:
> > > On Tue, 15 Aug 2017 22:09:15 +0200
> > > 
> > > Allan Sandfeld Jensen <k...@carewolf.com> wrote:
> > > > On Dienstag, 15. August 2017 16:14:45 CEST Thiago Macieira wrote:
> > > > > On Tuesday, 15 August 2017 03:18:03 PDT Allan Sandfeld Jensen wrote:
> > > > > > You might want to cross compile Qt or most of Qt, but have other
> > > > > > projects
> > > > > > you want to build locally.
> > > > > > 
> > > > > > I for one would love such a feature for testing builds on various
> > > > > > build
> > > > > > configuration. So I can cross-build most of Qt, but ensure that we
> > > > > > can
> > > > > > still build the module I am testing, on such an architecture, not
> > > > > > just
> > > > > > for it.
> > > > > 
> > > > > If you've done your job right, you can cross compile and that should
> > > > > be
> > > > > superior than building on a slow device.
> > > > 
> > > > But it wouldn't verify if I CAN build on a non-x86 architecture, which
> > > > is
> > > > what I am trying to test.
> > > 
> > > But what exactly are you testing then? Whether the native compiler
> > > works?
> > 
> > In my case we have a tricky translation of qmake settings to GN settings
> > in
> > qtwebengine, so I am testing if everything get translated correctly, so it
> > can actually build. This has broken multiple times. Basically does ARM
> > host builds work or did we accidently make some critical arm part
> > cross-build only.
> I'm intrigued. Can you give an example? I can easily see how things can go
> wrong the other way around ("whoops, we assumed that target equals host"),
> but if you got the target right already, one would think everything's fine.
> Unless it's about the location of host tools...
> 
For non-x86 you often have to pass through or trigger the right CFLAGS, 
otherwise you don't get the right FP-implementation, architecture revision, 
SIMD instructions or ABI. That sort of thing.

Conversely there are often problems with cross-builds if detection goes wrong, 
so it starts assuming things detected on host is present on target, which can 
make it easier to start by fixing a standard build before fixing the cross-
build, and we have builds breaking regularly due to importing multi-million 
lines diffs from chromium.

'Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest