[Interest] OpenGL with Qt6 on Windows

[Adam Light]

Hi all

I'm trying to get some tests of our application running on a GitHub actions
runner with Windows Server 2022 as the OS.

If I use a version of our application with Qt 5.12, the application starts
correctly. This Qt 5.12 was self-built using this configure command:

c:\qtbuild512\qt\configure -confirm-license -make-tool jom
-debug-and-release -force-debug-info -opensource -gui -widgets
-no-qml-debug -skip qt3d -skip qtwebengine -skip qtwebview -nomake examples
-nomake tests -no-sql-mysql -opengl desktop -mp -prefix
C:\qtbuild512\install\win64

If I try to run our application built with a self-built Qt 6.5, the
application won't start and exits with error code -1073740771. That error
code is:
0xc41d (NT: 0xc41d STATUS_FATAL_USER_CALLBACK_EXCEPTION) --
3221226525 (-1073740771)
Error message text: An unhandled exception was encountered during a user
callback.

The configure command for this self-built Qt 6.5.1 is:
..\..\qt\configure  -debug-and-release -force-debug-info -gui -widgets
 -nomake examples -nomake tests -trace etw -opengl desktop -prefix
C:\qtbuild6_5\install\win64

If I use the same application with the official Qt 6.5.1 binaries for
Windows, the application starts. If I remove just opengl32sw.dll, I get the
same error message I get when using our self-built binaries, which do not
include opengl32sw.dll.

It's pretty clear to me that the official binaries are working because they
include software rendering for OpenGL. Since the server likely does not
have hardware based OpenGL, and our application links against opengl32.lib,
it seems reasonable that the application would not start using our
self-built Qt 6.5 that is configured with -opengl desktop.

But what I don't understand is why the application runs with our Qt 5.12,
which also has "-opengl desktop" in the configure command.

FWIW our application is a widgets based application that uses QOpenGLWidget
and related classes.

Thanks for any insight you might have
Adam
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] MSVC not-the-latest: are you using it? why?

[Adam Light]

On Tue, Jan 24, 2023 at 4:41 PM Thiago Macieira 
wrote:

>
> Ah, interesting. I'd completely forgotten Visual Studio is a paid product
> (who
> had the bright idea of charging for the ability to develop software for a
> given OS? Don't they want to enrich said OS with more software?). I only
> use
> the Build Tools because I only build SW on Windows from the command line,
> after pushing there from my Linux development machine.
>
>
According to https://visualstudio.microsoft.com/downloads/?q=build+tools,
  "These Build Tools [...]. Use of this tool requires a valid Visual Studio
license."

In my experience, it is possible to install the IDE (which also installs
the build tools) and continue using the build tools even after the IDE will
refuse to run because your demo period has expired.

We don't use the IDE for much other than debugging minidumps we get from
customers when our application crashes, so perhaps we could just download
the build tools and not pay the license fee, but it's a bit ambiguous to me.


>  I am wondering if the VS 2019 IDE can drive builds with the VS 2022 Build
> Tools.
>
>
I don't have VS 2019 installed so I don't know. I do have 2017 installed
and tried to check, but my trial period has expired so I can't use the IDE
enough to actually test this.




> What I also didn't know is that if you've purchased the licence for a
> given
> VS, you're not entitled to the upgrade to the next. I know this is how it
> used
> to be with Microsoft Office back in the 90s and even the old Visual
> Studios, but
> I thought this practice was long gone. You can upgrade Windows for free,
> after
> all.
>

There are a lot of different licensing schemes for Visual Studio, so I
would not be surprised if what you said is true for some people.

I purchased a single-user perpetual license to VS 2019 through the
Microsoft Store several years ago and was not eligible for a free upgrade
(or low-cost upgrade) to VS 2022, as far as I could tell. In fact, after VS
2022 was officially released, it was not even possible to purchase a
perpetual license on the MS store. I had to file a bug report with the VS
project and have that percolate through several layers of bureaucracy for
about a month before I could even give MS my money.

I think MS wants people to buy their subscriptions, not perpetual licenses.
Our product's release cycle is around 3 years, and we use the same version
of Visual Studio and Qt for that period, so the subscription doesn't pay
off for us.

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

Re: [Interest] MSVC not-the-latest: are you using it? why?

[Adam Light]

On Mon, Jan 23, 2023 at 3:06 PM Thiago Macieira 
wrote:

> But on Windows and on macOS, the compiler updates are disconnected from
> the OS
> version. Hence the question: if you can install compiler version Y using
> the
> same mechanism you installed version X, why won't you?
>
>
Outside of inertia, which is powerful, one consideration may be cost. While
there is a free "Community" version of Visual Studio, it places pretty
strict limitations on the kind of companies that can use it. A single user
perpetual license is about $500 USD and, in my experience, not particularly
easy to purchase for a small team. One can purchase a license for
themselves through the Microsoft store, but as far as I could tell
purchasing a small handful of licenses requires each person to do the
purchase themselves (and deal with getting reimbursed) or you must go
through a reseller, and we haven't been able to find a reseller
willing/able to sell us perpetual copies (I'm not sure how hard our
purchasing pers.

With that said, we have upgraded to VS 2022 and find it much better than
2017 (we skipped 2019), and we would not object to dropping 2019.

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

[Interest] Using AddressSanitizer with Qt on Windows

[Adam Light]

Has anyone been able to successfully run/test a Qt based application built
with AddressSanitizer enabled on Windows? I have a 64-bit Qt 6.2.4 build
that I built from git using MS Visual Studio 2022 (updated in the last
couple of weeks). I've tried building our application, as well as a couple
Qt example applications (mainwindow and lineedit) using qmake with this in
the additional arguments setting for the qmake build step in Creator:
QMAKE_CFLAGS+=-fsanitize=address QMAKE_CXXFLAGS+=-fsanitize=address

If I try to run any of these three applications, execution breaks very
early on. For example, with mainwindow execution stops at
QArrayData::reallocateUnaligned. This is while executing
qInitResources_cursors further up in the call stack.

When I run the lineedit example the break is in the initialization of
harfbuzz.

I have tried debug and release builds, I tried building Qt with the same
CFLAGS and CXXFLAGS, and I've tried using cl-clang.exe instead of cl.exe as
the compiler. All combinations end up hitting a break in execution pretty
early, though not always in the same place.

Unlike when I've used asan on macOS, I'm not seeing the full sanitizer
output in Creator's application output window, so it's not clear to me
whether these are legitimate bugs or if something else is going on.

Thanks for any advice
Adam
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] License for Qt6 QtMultimedia module (LGPL?)

[Adam Light]

On Tue, Feb 15, 2022 at 10:20 AM Alexey Edelev  wrote:

> Shadertools module provides an executable that is used by multimedia at
> build time only. So there is no runtime dependencies between qtmultimedia
> and shadertools, so that's the key, I guess.
>

OK, that makes sense. Thanks.

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

[Interest] License for Qt6 QtMultimedia module (LGPL?)

[Adam Light]

At https://doc.qt.io/qt-6/qtmultimedia-index.html, the Qt Multimedia module
is listed as being available under these licenses:
* commercial
* LGPL, v3
* GPL, v2

In a git checkout of the 6.2 branch, .gitmodules contains this:
[submodule "qtmultimedia"]
depends = qtbase qtshadertools
recommends = qtdeclarative
path = qtmultimedia
url = ../qtmultimedia.git
branch = 6.2
status = addon

According to https://doc.qt.io/qt-6/qtshadertools-index.html, the Qt Shader
Tools module is available under these licenses:
* commercial
* GPL, v3

If qtshadertools is required in order to build qtmultimedia, and
qtshadertools is not licensed under LGPL, how can qtmultimedia be licensed
under LGPL?

Is it possible to build qtmultimedia in such a way as to not use/require
qtshadertools? Our application uses qtmultimedia but I don't think it uses
anything that involves qtshadertools. Our application currently uses Qt 5
under the LGPL license and unless I'm misunderstanding it seems that we
would not be able to use Qt 6 under the LGPL license unless we get rid of
qtmultimedia.

Thanks for any clarification

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

Re: [Interest] win: can't trap WM_ENTER/EXITMENULOOP?

[Adam Light]

On Mon, Oct 25, 2021 at 9:40 AM David M. Cotter  wrote:

> in the documentation here
> , it
> indicates i can get a message when the menu bar starts to be browsed, and
> another when the browsing is completed.
>
> this is *exactly* what i need (the purpose is unrelated to this post).
>
> So in my QMainWindow derived class, i override the nativeEvent() method,
> like so:
>
> [...]
>
> However, those messages are never sent :(
>
> Any idea why not?
>
I'm just guessing here, but it might be that the menu bar's events don't
get delivered to the QMainWindow.

Or, perhaps this documented caveat is important: "Note: Events are only
delivered to this event handler if the widget has a native window handle."

You might be able to catch the events if you
use QCoreApplication::installNativeEventFilter (
https://doc.qt.io/qt-6/qcoreapplication.html#installNativeEventFilter).

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

Re: [Interest] Security message when I download Qt Creator?

[Adam Light]

On Wed, Feb 24, 2021 at 10:07 AM John Weeks  wrote:

> I just downloaded the latest Qt Creator (I keep hoping a new update will
> fix the Application Output pane's buffering problem). Chrome on Mac OS
> 10.14.6 wouldn't download it because "the file cannot be downloaded
> securely". Is this a Chrome issue, or was the dmg not marked properly, or
> perhaps this happens with any dmg these days? I did ultimately manage to
> download it by right-clicking, selecting Save Link As and then clicking the
> status tile at the bottom of the window, where there was a choice to go
> ahead anyway.
>
>
For what it's worth, I have reported this at
https://bugreports.qt.io/browse/QTWEBSITE-972.

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

Re: [Interest] QML app macOS dedicated graphic card issue

[Adam Light]

On Wed, Feb 24, 2021 at 3:25 AM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> Hi,
>
> Il 24/02/21 11:55, Alexander Dyagilev ha scritto:
> > "as soon as I start it my mac switches to dedicated nvidia graphic card
> > from item integrated.
> > which seems like unnecessary."
> >
> > Why? Can anything be done to prevent this?
> >
> > We use Qt 5.12.10, QML + QtQuick Controls 2.
>
> There's been a few bugs reported against this, search in the bugtracker.
> IIRC the "solution" was to advertise that the discrete GPU is OK in your
> application's info.plist.
>

For anyone interested, I foound
https://developer.apple.com/library/archive/qa/qa1734/_index.html which
supports what Giuseppe said.

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

Re: [Interest] QtCreator annoying message

[Adam Light]

On Tue, Feb 16, 2021 at 7:12 AM Alexander Dyagilev 
wrote:

> I always appears after i had to restart Qt Creator.
>
> I had to restrt it due to the following reasons:
>
> 1) It stops parsing c++ code for opened files so i can't use IDE's C++
> support
>
> 2)
>
> ...
>
> I can't think of another reason. It's always 1st one.
>
>
I see this all the time on Windows with our application's project (hundreds
of files, several million lines of code, likely very poorly organized with
regards to headers). When the "Parsing C/C++ Files" step starts (eg.
after switching between debug and release configurations), it typically
takes 10+ minutes (if it even finishes at all), and I think the message you
described will show up if I kill Creator while it's parsing C/C++ files.
For reference, a complete build of our project from scratch takes about 2
minutes on the same machine, so clearly the files can be parsed much more
quickly by the actual compiler.

My machine has 16 cores/32 threads. If I collect ETW data while Creator is
parsing files, the parsing is happening in around 20 threads but the total
CPU utilization during the entire time is typically about 5%, suggesting
that there may be a lot of thread contention. If I dive deeper into the
traces, for a 21.4 s sampling period (which represents 25.1 s of
qtcreator.exe CPU time), 18.2 seconds of CPU time are spent in either
RtlpAllocateHeap or RtlpHeapFindListLookupEntry. These are Windows API
functions that are indirectly called by QVector::realloc. In this case,
most of that is due to ::realloc. Note that
this 21.4 s sampling period is just a small part of the ~10 minutes it took
to complete the Parsing C/C++ Files step.

My guess is that Creator's CppTools and CPlusPlus plugins are not able to
efficiently handle deep #include trees. For what it's worth, our project
uses precompiled headers and in Creator's Code Model settings tab, "Ignore
precompiled headers" is unchecked.

I can't provide our project since our application is not open source. If
there is any sort of debugging mode I can enable that might shed more light
on what is happening I'm happy to help there.

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

Re: [Interest] Generate pdb for qmake.exe on Windows

[Adam Light]

On Fri, Dec 11, 2020 at 9:19 AM Joerg Bornemann 
wrote:

> On 12/11/20 5:15 PM, Adam Light wrote:
>
> >  > Is it possible to build Qt in such a way that debugging symbols
> for
> >  > qmake itself are generated?
> >
> > Not out of the box. Edit qmake/Makefile in your build directory and
> > - add /Zi to CFLAGS_BARE
> > - add /DEBUG to LFLAGS
> > then run "nmake clean" and "nmake".
> >
> >
> > Thanks for the help.
> >
> > But I don't see a qmake directory in my build directory. Did you mean
> > the qtbase\qmake directory in my build directory? I do have that one.
>
> Yes, that one.
>
> OK, thanks Joerg. That worked. The only thing is that the qmake.pdb that
is generated is not copied by jom install (after building the rest of Qt)
so I had to copy that over manually.

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

Re: [Interest] Generate pdb for qmake.exe on Windows

[Adam Light]

On Fri, Dec 11, 2020 at 7:46 AM Joerg Bornemann 
wrote:

> On 12/11/20 4:40 PM, Adam Light wrote:
>
> > Is it possible to build Qt in such a way that debugging symbols for
> > qmake itself are generated?
>
> Not out of the box. Edit qmake/Makefile in your build directory and
> - add /Zi to CFLAGS_BARE
> - add /DEBUG to LFLAGS
> then run "nmake clean" and "nmake".
>

Thanks for the help.

But I don't see a qmake directory in my build directory. Did you mean the
qtbase\qmake directory in my build directory? I do have that one.

Isn't qmake.exe created by configure.exe itself? Or is it built once by
configure.exe and then rebuilt when building the rest of Qt?

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

[Interest] Generate pdb for qmake.exe on Windows

[Adam Light]

I'm building Qt 5.12.11 myself on Windows (VS 2017) using the following
configure command:
c:\qtbuild512\qt\configure -confirm-license -make-tool jom
-debug-and-release -force-debug-info -opensource -gui -widgets
-no-qml-debug -skip qt3d -skip qtwebengine -skip qtwebview -nomake examples
-nomake tests -no-sql-mysql -opengl desktop -mp -prefix
C:\qtbuild512\install\win64

This gives me .pdb files for all of the qt tools and libraries *except*
qmake.exe itself. In other words, no qmake.pdb is generated but I do get
moc.pdb, uic.pdb, etc.

I am trying to profile an incredibly slow build of our application that
uses this self-built Qt but since I don't have symbols for qmake.exe itself
I can't gain much information from the profiling data. FWIW, application
builds are taking > 1 hour where they should take about 5 min. All
antivirus (including Windows Defender) are disabled.

Is it possible to build Qt in such a way that debugging symbols for qmake
itself are generated?

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

Re: [Interest] Three-file modules vs. moc

[Adam Light]

On Thu, Aug 27, 2020 at 5:43 AM Bernhard Lindner <
priv...@bernhard-lindner.de> wrote:

> > You might also use a custom extra compiler -- that still invokes moc,
> > but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl,
> > and so on...
>
> Hm, I see. Has something like that been done before, is there code I could
> reuse?
>

This is for a rather different use case but attached to
https://bugreports.qt.io/browse/QTBUG-81348 you can find two (very similar)
examples of how to write a custom feature that runs moc in a different way
than the default.

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

Re: [Interest] Tracking down a macOS drawing bug

[Adam Light]

On Tue, Jun 16, 2020 at 4:07 PM Adam Light  wrote:

> We recently discovered a bug in our application that uses Qt 5.12.8 and
> we're having a hard time figuring out what might be going wrong. This is in
> a subclass of QPlainTextEdit.
>
>
For what it's worth, Qt 5.12.9 fixes this problem for us.

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

[Interest] Tracking down a macOS drawing bug

[Adam Light]

We recently discovered a bug in our application that uses Qt 5.12.8 and
we're having a hard time figuring out what might be going wrong. This is in
a subclass of QPlainTextEdit.

The bug presents in the following way:

If you have a line of text selected, such as "abcd;abcd;abcd;abcd;", and
use our replace bar to replace "abcd" with "foo", and then replace all
instances in the selected text, the widget still
displays "abcd;abcd;abcd;abcd;" with the original selection until something
forces the entire window to redraw (eg. the application is deactivated or
the window is resized).

This might sound like a bug in our application but we only see the bug when
both of the following are true:
1. The application is built on a machine with macOS 10.15.5 and Xcode 11.5
2. The application is running on macOS 10.14 or 10.15 but NOT 10.13

We are using the exact same copy of the Qt framework in all cases, built on
macOS 10.14 with Xcode 10.2.

The fact that we don't see this running macOS 10.13 suggests that it has
something to do with layer-backed views.

The fact that we can reproduce the bug when running the application on
10.15 and 10.14 suggests that it's not (just?) an OS bug.

We cannot reproduce the problem if we build our application with Xcode
11.2, but we can using Xcode 11.5. We haven't tried anything in between.

Is there Qt drawing code that behaves differently when the **application**
is **built** with the 10.15 SDK versus the 10.14 SDK? The only relevant
test I can see for this is in qnsview_drawing.mm (layerEnabledByMacOS())
but that test treats Mojave and Catalina the same.

Does this sound familiar to anyone?

Thanks for any ideas
Adam
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] how to get 3 pixel focus ring?

[Adam Light]

On Tue, Jun 9, 2020 at 11:02 AM David M. Cotter  wrote:

> ONLY around the lineEdit (search box, working fine on mac), the Tree view,
> or the Table view.
>
> these are the only three places that are the targets of the keyboard
>
> if you run my example project, you'll see things work fine for lineEdit
> and Tree view, but for some reason the table view gets only one pixel, even
> though it's set up EXACTLY the same way as the tree view.
>
>
On Macintosh I think you're probably running into
https://bugreports.qt.io/browse/QTBUG-82350.

It just so happens that I was working on a custom widget today and wanted
it to have a focus ring, and it's not drawn properly on Macintosh if I
build with Qt 5.12, but is drawn properly with Qt 5.9. I tracked this down
to the same problem described in the bug.

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

Re: [Interest] how to get 3 pixel focus ring?

[Adam Light]

On Sun, Jun 7, 2020 at 2:21 PM David M. Cotter  wrote:

> i have an example project (see below), that tries 6 different
> implementations, attempts to make the focus ring 3 pix wide. None of them
> work on windows, and only one of them PARTIALLY works on mac. What i want
> is the style you get around a text edit on mac, but i want that style on
> ALL widgets, and i want it on windows too.
>

Let's take a step back. What exactly are you trying to accomplish?

Do you want the focus ring to be around the QTreeWidget, QTableWidget, and
QLineEdit widgets (lineEdit, tableView, and treeView in your .ui file)? Do
you want a focus ring around the selected item in the tree and table views
(those are not widgets, but I suspect this is actually what you want). Or
do you want the focus ring around the widgets used for editing values in
your views, such as the line edit you get when you double click on one of
the cells in the table widget? These are all very different problems so
it's important to define the problem you are trying to solve first.

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

Re: [Interest] how to get 3 pixel focus ring?

[Adam Light]

On Sun, Jun 7, 2020 at 2:21 PM David M. Cotter  wrote:

> i have an example project (see below), that tries 6 different
> implementations, attempts to make the focus ring 3 pix wide. None of them
> work on windows, and only one of them PARTIALLY works on mac. What i want
> is the style you get around a text edit on mac, but i want that style on
> ALL widgets, and i want it on windows too.
>
> anyone have any idea how i can accomplish this?
>

It might be as simple as returning a different value
for QStyle::PM_FocusFrameHMargin and QStyle::PM_FocusFrameVMargin in a
QStyle::pixelMetric or QProxyStyle::pixelMetric implementaton. If you're
using one of the standard styles then it's pretty simple to create and use
a QProxyStyle class to tweak pixel metrics and other aspects of the style.

If that doesn't work you may be able to reimplement
Q[Proxy]Style::drawControl for element QStyle::CE_FocusFrame and handle the
drawing of the focus frame itself.

One thing to watch out for is that making QStyle::PM_FocusFrameHMargin and
QStyle::PM_FocusFrameVMargin larger than default can result in the focus
frame getting clipped in some situations. We see this using persistent
editors in itemviews sometimes, and I think we also sometimes see this when
certain widgets are in splitters.

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

Re: [Interest] Qt Creator Application Output window

[Adam Light]

On Thu, Apr 30, 2020 at 12:52 AM Christian Kandeler <
christian.kande...@qt.io> wrote:

> On Wed, 29 Apr 2020 14:34:57 -0700
> j...@wavemetrics.com wrote:
>
> > Maybe I was too specific here. This isn't just a problem with Address
> Sanitizer. It is a general problem with the output pane in Qt Creator. Its
> just that AddressSanitizer happens to put out lots of output.
>
> I don't. If you have a project with which to at least somewhat reliably
> reproduce the issue, you should file a bug report at bugreports.qt.io.
>
>
I sometimes see the same problem under the conditions John described, but
then I'm also working on the same project as John. This is the project for
our closed source application of around 5 million lines of code, so it's
not possible to file a bug and include the project, and likely impractical
to distill this down to a minimum working example.

We run into lots of problems with Creator that are reasonably attributable
to the size, complexity, or possibly the poor organization of our project,
but it's very tricky to turn these problems into actionable information for
the Creator developers.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Mon, Dec 23, 2019 at 2:26 PM Adam Light  wrote:

>
> One idea I had was to combine all files in HEADERS into a single giant .h
> file, and then call moc.exe once on that file. The single call to moc.exe
> would be executed in a single thread, but it would avoid the need to
> rediscover all of the header files from each of the 600 or so moc processes
> that would otherwise run.
>
>
I've come up with a feature that replaces the standard moc feature that
does exactly this. It's a bit fragile--it works for our project, but I
tried using it to build Qt Creator and there were errors. Someone better
with qmake might have more success making it more broadly useful.
Ultimately, I think the best approach would be to allow moc to accept a
list of files to be mocced, but as is I don't think qmake can (easily?) be
used to supply that list.

Using this new feature, it takes only 2-3 seconds to moc all of the 550 or
so mocable header files in our project, versus over 60 seconds without the
feature. So builds are much faster, and the feature almost eliminates the
performance killing effects of the bindflt minifilter driver I mentioned
earlier in the thread.

I've created a feature request at
https://bugreports.qt.io/browse/QTBUG-81348 that contains two versions of
the new feature as well as a detailed description of the problem and what I
have learned while investigating it.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Thu, Dec 5, 2019 at 5:09 PM Adam Light  wrote:

>
> We have almost 600 classes that use Q_OBJECT, so there are a lot of calls
> to moc. We probably don't strictly need the Q_OBJECT macro in some of those
> classes, but I would prefer not to start removing Q_OBJECT unless that's
> the last option.
>
> We also have around 200 paths in our INCLUDEPATH variable. Moving header
> files into fewer directories would allow that to decrease, which should
> improve moc performance.
>
> Does anyone else have any ideas of how we could change our build to
> improve moc performance when Windows decides to be "slow"? Like, for
> example, is there any way to have the moc calls run with only a few moc
> processes running at once but have the rest of the build done with all
> threads running. I'm pretty sure that the OS slowdown has something to do
> with thread contention of some sort.
>
>
 To follow up with my original post, I've made moderate progress by pruning
the number of paths in INCLUDEPATH, removing #include statements from our
header files that aren't actually necessary, and tweaking qmake CONFIG
settings. That has dropped the build time down from close to 5 minutes to
just under 3 minutes.

One idea I had was to combine all files in HEADERS into a single giant .h
file, and then call moc.exe once on that file. The single call to moc.exe
would be executed in a single thread, but it would avoid the need to
rediscover all of the header files from each of the 600 or so moc processes
that would otherwise run.

I was able to get qmake to generate the concatenated .h file for me with
the following commands:
COMBINED_HEADERS = $$shell_path($$absolute_path($${MOC_DIR}/allheaders.h,
$$OUT_PWD))
for (oneHeader, HEADERS): {
CMD = "type $$shell_quote($$shell_path($$absolute_path($${oneHeader},
$$_PRO_FILE_PWD_))) >>  $${COMBINED_HEADERS}"
message($${CMD})
system("$${CMD}")
}

I then manually executed the moc.exe command on the command line, using the
same flags used for all of the other regular moc calls, and it took moc
about 2 seconds, versus over 60 seconds when moc is called separately for
each mocable file. Concatenating all of the header files together did take
some time (maybe 20 seconds), but it's still a huge decrease in build time.

I haven't tried to link in this single moc output file, so there may still
be troubles ahead.

Does anyone know of an existing example of doing the concatenating of
headers properly so that the mega header file is updated when necessary? My
quick and dirty approach given above seems to work so far but I'd be
surprised if it's the best way.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Tue, Dec 10, 2019 at 5:09 AM Michael Jackson 
wrote:

> What did you use to collect the sampling data? Our project also
> experiences long build times (30 minutes on a 12 Core Xeon machine) using
> Qt5. I would like to be able to zero in on some of the issues instead of
> guessing at them.
>
>
>

I use UIforETW (https://github.com/google/UIforETW/releases) to collect the
traces. This is a powerful but relatively simple user interface for
Microsoft's ETW (event tracing for Windows). Bruce Dawson, the author,
works for Google on the Chrome Browser and therefore UIforETW has a lot of
Chrome specific options, but you can ignore all of those and use it for
tracing any application. Collecting the traces is pretty simple, but
analyzing them in WPA (Windows Performance Analyzer) is not because there
is just an immense amount of data and so many options for analyzing it.

I recommend that you start by reading this blog post:
https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/.
He also has several videos that cover some important analysis topics at
https://randomascii.wordpress.com/2014/08/19/etw-training-videos-available-now/,
but they're behind a paywall. When I first started using the tool there was
a free trial subscription of some sort that I signed up for so that I could
view the videos. After that, reading his ETW related blog posts is very
informative. He runs into some very strange performance problems, but the
analysis techniques he discusses have been useful to me in tracking down
less obscure problems in our application. The post at
https://randomascii.wordpress.com/2019/10/20/63-cores-blocked-by-seven-instructions/
is
even compiling related. I was excited when I saw that post since it's a
similar problem to what I'm running into with moc but the sources of the
problems are different.

For Windows minifilter driver problems, which is what I think I'm dealing
with here, I found a blog post at
https://blogs.msdn.microsoft.com/ntdebugging/2012/05/31/hotfix-to-enable-mini-filter-performance-diagnostics-with-xperf-for-windows-server-2008r2/
that discusses how to collect trace information on minifilter delays.
Instead of using the command line tool described there, I used UIforETW's
Settings dialog and added the flags given in the blog post to the Extra
Kernel Flags and Extra Kernel Stackwalk settings.

If you want to profile anything Qt related, you'll need the PDB symbols for
the libraries and the tools. We use our own build of Qt 5.12, so we have
all of the symbols available, EXCEPT that I can't figure out how to
generate PDB files for qmake.exe itself, so I've been unable to analyze why
qmake takes longer to run than it seems to me it should. If anyone knows
how to force generation of PDB files for qmake, that would be really
helpful.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Thu, Dec 5, 2019 at 5:09 PM Adam Light  wrote:

>
> Does anyone else have any ideas of how we could change our build to
> improve moc performance when Windows decides to be "slow"? Like, for
> example, is there any way to have the moc calls run with only a few moc
> processes running at once but have the rest of the build done with all
> threads running. I'm pretty sure that the OS slowdown has something to do
> with thread contention of some sort.
>
>
The problem with moc.exe is even worse than I first realized.

Even when Windows is in the "fast" state (that is, a full rebuild takes 4-5
minutes instead of 16-18 minutes), the vast majority of the build time is
spent in moc.exe.

I just collected sampling data for an entire build, excluding the qmake
step. So this is the entirety of jom.exe and everything it calls during the
build. Windows 10, debug build of our application, VS2017. I'm not using
any /j flag with jom, so it will use all available threads (16 core/32
threads).

The build took 4:54. During that time, there were a total of 551 moc.exe
processes that ran, and those processes took a total of 3,896 seconds of
CPU time. There were also 1270 cl.exe processes which took a total of 965
seconds of CPU time. Everything else (link.exe, ui.exe, jom.exe, was
minimal) compared to these two. So moc.exe was running almost 4 times as
long as cl.exe. That seems crazy to me.

When I previously analyzed the sampling data during a moc.exe run, it was
clear that the vast majority of the time was spent satisfying the includes,
and most of that was checking whether a concatenation of an include path
and a file name are a valid file (eg. include/path1/stdio,
include/path2/stdio, etc.). It seems like the compiler (cl.exe) would need
to do essentially the same thing when compiling each individual file, but
it's not nearly as slow as moc.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Fri, Dec 6, 2019 at 6:08 PM Thiago Macieira 
wrote:

> On Friday, 6 December 2019 15:10:41 PST Adam Light wrote:
> > > Yes:
> https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl
> >
> > Thanks. That saved a lot of time.
> >
> > For what it's worth, after changing all of our code to directly #include
> > the moc output, the total build time dropped by around 10%. That's
> helpful.
>
> Nice. Did you notice a size improvement in your optimised binaries too?
>
>
On Macintosh, with Xcode 10.2, the application's executable went from
202627092 bytes to 202587956 bytes. This is a release build (-O2). So the
decrease in size is small, but measurable.

I haven't tested the executable sizes on Windows yet. Strangely, on
Windows, this change has almost zero effect on build time. The time to run
qmake has increased slightly (about 3:10 to 3:20) but the remaining build
time (everything within jom.exe) only dropped by about 8 seconds (total of
about 7 minutes). On Macintosh, the qmake time also increases slightly but
the rest of the build is about 45 seconds faster (6:15 to 5:29). The
Windows builds are release builds with VS2017.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Fri, Dec 6, 2019 at 9:57 AM Thiago Macieira 
wrote:

> On Friday, 6 December 2019 06:30:36 PST Adam Light wrote:
> > Yes, that's definitely on my TODO list, though I don't think it's going
> to
> > do much to address the current situation in which moc itself is the main
> > bottleneck. But any improvement will help.
> >
> > Does anyone know of a script or other automated way to add these
> includes?
>
> Yes: https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl
>
>
Thanks. That saved a lot of time.

For what it's worth, after changing all of our code to directly #include
the moc output, the total build time dropped by around 10%. That's helpful.

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

Re: [Interest] Tricks to improve moc performance?

[Adam Light]

On Fri, Dec 6, 2019 at 12:42 AM Uwe Rathmann 
wrote:

> On 12/6/19 2:09 AM, Adam Light wrote:
>
> > Does anyone else have any ideas of how we could change our build to
> > improve moc performance when Windows decides to be "slow"?
>
> Something you can try is to include the moc file at the end of your cpp
> file. This can be done like this:
>
> #include "moc_XYZ.cpp"
>
>
Yes, that's definitely on my TODO list, though I don't think it's going to
do much to address the current situation in which moc itself is the main
bottleneck. But any improvement will help.

Does anyone know of a script or other automated way to add these includes?

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

[Interest] Tricks to improve moc performance?

[Adam Light]

We have several machines running Windows 10 that are quite powerful (eg. 8
or 16 core (16 or 32 thread) processors, lots of RAM, NVMe SSD storage).
However, since upgrading to Windows 1903, we have noticed that sometimes
the compile time of our large Qt 5.12 based application increases
dramatically.

As an example, on one 16 core/32 thread machine, a debug build can take as
little as 4 minutes. However it sometimes takes 18 minutes. This is for the
exact same code, compiler, settings, etc. I can literally do a full build
that takes 4 minutes, do something, delete the build directory and rebuild
and now it takes 16 minutes. The "do something" may be going to lunch or
making a trivial change in the code. Otherwise the state of the machine is
the same (no other heavyweight processes running, etc.)

We see this behavior both when using Qt Creator 4.10.2 to do the build
(using jom.exe) and also when done outside of Creator with calls to qmake
and then jom. All files involved in anything I mention here are on and/or
written to the local SSD. I see these issues with no antivirus running, no
backup, etc.

I have collected some Windows Performance Tracing traces while building and
during a "slow" build, most of the time is spent in moc, specifically
searchIncludePaths. This function results in a lot of calls to
QFileInfo::exists() and QFileInfo::isDir(), both of which ultimately call
GetFileAttributesExW. The vast majority of the time is spent in downstream
calls that GetFileAttributesExW makes, so I am not blaming moc itself for
the slowdown.

I don't want to get too much into the weeds, but I believe that the
slowdown is a bug in one or more Windows minifilter drivers, which get
invoked by the OS in the file API calls. I suspect that pinpointing the
problem in such a way that I could report it to Microsoft is unlikely, and
so for practical reasons I am hoping that there is a way we could change
our build process to work around this slowdown.

Our application is one that was ported into Qt and we are building a few
very small libraries and one gigantic application that links to those
libraries. This isn't ideal, I'm sure, but I don't think it would be
practical to disentangle everything to have separate projects that are
first built and then linked into the main application.

We have almost 600 classes that use Q_OBJECT, so there are a lot of calls
to moc. We probably don't strictly need the Q_OBJECT macro in some of those
classes, but I would prefer not to start removing Q_OBJECT unless that's
the last option.

We also have around 200 paths in our INCLUDEPATH variable. Moving header
files into fewer directories would allow that to decrease, which should
improve moc performance.

Does anyone else have any ideas of how we could change our build to improve
moc performance when Windows decides to be "slow"? Like, for example, is
there any way to have the moc calls run with only a few moc processes
running at once but have the rest of the build done with all threads
running. I'm pretty sure that the OS slowdown has something to do with
thread contention of some sort.

If anyone thinks they have run into this situation or is intimately
familiar with Windows minifilter drivers, I'm happy to share the details
behind why I think they are involved here.

Thanks for any ideas
Adam
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt free software policy

[Adam Light]

On Wed, Aug 21, 2019 at 7:17 AM Matthew Woehlke 
wrote:

> On 14/08/2019 16.22, John Weeks wrote:
> > We are a small company selling a very large and complex application
> which is now based on Qt open source. At the time we first considered
> porting to Qt (version 4.3?) the license was very expensive for small
> company (six programmers) and the evaluation period simply wasn't adequate
> to deciding if it was the right way to go. So we went open-source when it
> became available when Nokia took over.
> >
> > Since then, we have wished that we had a commercial license in order to
> get a bit more traction on some bugs. The Qt Company wanted us to pay for
> all the  licensing that had accrued since we started using the LGPL
> version. That up-front cost is prohibitive, so we haven't done it.
>
> Does TQtC *not* sell commercial-level *support* without the additional
> commercial licensing rights (and retroactive costs)? If not, that seems
> like an idiotic missed opportunity...
>
>
If I recall correctly, we looked into this a few years ago and the answer
was no. So we hired one of the big Qt consulting firms to work on an issue
for us instead. Since we don't actually have any need for the commercial
license (LGPL is just fine for what we use Qt for) there's really no
incentive for us to purchase a commercial license other than for the
support, but the pricing on the commercial license was close to an order of
magnitude more than the value of the support we would get (again, this was
years ago, so perhaps things have changed).

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

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Adam Light]

On Wed, Jul 10, 2019 at 9:17 AM coroberti .  wrote:

> Adam,
> Could you please provide more details about notarization without runtime
> hardening by using SDK 10.13?
> Specifically, which Xcode version was used and at which Mac OS?
> Thanks,
>
>
See
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution.
Look at the paragraph after the bullet list in the Prepare Your Software
for Notarization section.

I have successfully notarized our application that is built and code signed
with Xcode 9 on macOS 10.13. I did the notarization of the .dmg itself on a
different machine running 10.14 and Xcode 10. The application does not use
hardened runtime.

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

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Adam Light]

On Wed, Jul 10, 2019 at 2:28 AM Elvis Stansvik  wrote:

>
> With "work around" do you mean from the user POV (e.g. somehow
> disabling Gatekeeper, or Ctrl+Open, or something else) or from a
> developer POV (so, having to notarize)?
>
>
Instead of repeating myself here, please see my comment at
https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
which
explains what I mean by "work around". I just added screen shots of the
dialogs I mentioned in that comment so it's clear what the user sees.


> I'd like to know if there is some reasonably simple way for users to
> get around the requirement. We will not be able to notarize every
> build we do, because of the time it takes. But at the same time we,
> and our testers, must be able to test random builds from Git (we build
> a .dmg for every commit) to try out in-progress features/bug fixes...
> So I really hope there will be some way for the user to get around the
> notarization requirement.
>

Notarization doesn't take more than a few minutes (in my limited
experience) but it's a hassle to script the process. Your build machines
and possibly your testers will not need to have a notarized application
because, as I understand it, notarization is not required if the
application does not have a quarantine flag. If it's been downloaded via a
standard web browser, it should have the flag. But if it was built on the
machine, or if it was transferred from another machine using something like
curl, rsync, etc. then it is unlikely to have the quarantine flag.

Of course, it is possible that in the future the quarantine flag will not
control whether the notarization check happens, so what I said in the
paragraph above may change.

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

Re: [Interest] notarizing builds for Mac - enabling hardened runtime

[Adam Light]

On Fri, Jun 21, 2019 at 12:13 AM Kai Köhne  wrote:

>
> I understand that the "hardened runtime" enabling happens at codesign time,
> so this should arguably be a feature of macdeployqt. It's not there yet
> though,
> at least according to https://bugreports.qt.io/browse/QTBUG-71291 .  If
> you're
> right that this will become mandatory for macOS 10.15, it arguably get a
> higher
> priority; feel free to comment, including a link to the source of this
> statement.
>
> For the time being, it seems you've to execute the codesign call yourself.
>
>
Notarization is a requirement for macOS 10.15 (Catalina, currently in
beta). See https://developer.apple.com/news/?id=06032019i for an official
source of this requirement. In one of the WWDC 2019  talks about security
and code signing/notarization, they mentioned that this was true for
applications built (or maybe it's signed) after some date in early June.
For example, Qt 4.9.2, released June 26, 2019, will not run on Catalina
beta 3 without knowing how to work around the notarization requirement.

Note also that notarization is separate from hardened runtime. An
application built with the 10.14 SDK or later must enable hardened runtime
in order for it to be possible to notarize the application, but it is
possible to notarize applications built with previous SDK versions for
which hardened runtime did not exist.

See my comment at
https://bugreports.qt.io/browse/QTBUG-73398?focusedCommentId=468111&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-468111
for
some links that are particularly helpful in describing all of the
complexities involved in notarization and hardened runtime.

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

Re: [Interest] QTabWidget scroll buttons

[Adam Light]

On Tue, Mar 26, 2019 at 8:40 AM Murphy, Sean  wrote:

> > This works for me, and the button is small 16x16.
> >
> > m_TheTabWidget->setCornerWidget(bp1);
>
> You know, I saw that function and for some reason switched it
> in my head to be talking about the corner cell in a QTableWidget,
> not talking about a QTabWidget. Apparently I need more caffeine
> today...
>

 If you take this approach and your application is used on Macintosh, be
aware that the corner widget typically won't be visible unless your user is
using a non-default value for the System Preferences->General->Show scroll
bars setting.

In our application, we work around this by using the suggestion in the
comment of https://bugreports.qt.io/browse/QTBUG-50172.

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

Re: [Interest] What are you using for continuous integration?

[Adam Light]

On Tue, Feb 12, 2019 at 3:05 PM Nuno Santos 
wrote:

> Hi,
>
> I’m curious about what you Qt heads are using for continuous integration.
>
>
We have been using buildbot on a Linux server and multiple Macintosh and
Windows machines as workers for about 9 years. The workers build our Qt
based application, run tests, and if everything passes the application is
uploaded to the buildbot server which then passes the application to our
web server so users can download nightly builds of the application.

I wouldn't call it easy to set up, but that's largely because I was
learning Python as I was setting up the system.

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

Re: [Interest] Weird sizing in Qt Designer 5.12.0 with hi-res screen

[Adam Light]

On Tue, Jan 22, 2019 at 5:52 PM Tony Rietwyk  wrote:

> Hi Everybody,
>
> I have recently installed a hi-res screen 3840 x 2160 @ 150% scaling on
> my Windows 10 machine.
>
>
I'm not sure if this explains the problem you report, but we've found that
Qt does not fully support scale factors that are not a multiple of 100%. If
you change your scale factor to 200% (you may also need to log out/in
and/or reboot) you might find that you get the correct behavior.

On a related note, we've also sometimes found that Qt (and even other
non-Qt applications) misbehave on a system with multiple displays that have
different scale factors or on a mixed DPI environment (eg. one regular DPI,
one high DPI). The situation here has improved since Qt first started
supporting high DPI displays.

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

Re: [Interest] Struggling with moveEvent()

[Adam Light]

On Wed, Oct 3, 2018 at 6:27 AM Murphy, Sean  wrote:

>
> This looks promising - I had never stumbled across QWidgetAction before.
> Although now
> that you point it out, I've discovered the section of the QMenu
> documentation that I
> previously skimmed over that mentions it!
>
> Is the code in your paintEvent() something you can share, if there's
> anything noteworthy
> happening in there?
>

I don't think it's very noteworthy, but here's what we're using:

void WMColorPickerToolButton::paintEvent(QPaintEvent* event) {

Q_UNUSED(event);


QStylePainter painter(this);

painter.save();

painter.setPen(palette().color(QPalette::Text));


// Draw the regular tool button elements.

QStyleOptionToolButton opt;

initStyleOption(&opt);


// Clear the text in the opt object since text that we don't

// draw in this function will get in the way of the button's

// regular text.

opt.text.clear();


painter.drawComplexControl(QStyle::CC_ToolButton, opt);


// Get the rectangle into which the sample should be drawn.

QRect destField(style()->subControlRect(QStyle::CC_ToolButton, &opt,
QStyle::SC_ToolButton));


// Offset the rectangle by the style's button margin pixel metric.

int margin = style()->pixelMetric(QStyle::PM_ButtonMargin,  &opt, this);

destField.adjust(margin, margin, -margin, -margin);


// Draw the patterned background

WMColorPickerWidget::drawPatternedBackground(&painter, destField);


// Draw the color sample.

painter.fillRect(destField, _colorPickerAction->currentColor());


// Draw an outline rectangle.

QRect outlineRect(destField);

outlineRect.adjust(0, 0, -1, -1);

painter.setPen(palette().color(QPalette::Text));

painter.drawRect(outlineRect);

int thickness = 1;

outlineRect.adjust(thickness, thickness, -thickness, -thickness);

painter.setPen(palette().color(QPalette::Light));

painter.drawRect(outlineRect);


// Restore the painter.

painter.restore();

}

WMColorPickerWidget::drawPatternedBackground draws a checkerboard
background so that it's more obvious if a color's alpha value is not fully
opaque.

To be clear, that's the paintEvent for the tool button itself.  The QWidget
that's used by the QWidgetAction is just a container for other widgets in a
layout and doesn't have any need to reimplement paintEvent.

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

[Interest] Using NSTitlebarAccessoryViewController in a Qt window

[Adam Light]

Hi

I'm trying to add a NSTitlebarAccessoryViewController to the title bar of a
Qt window, similar to the example at
https://github.com/msorvig/qt-macos-nswindow-config (look for "Add
addTitlebarAccessoryViewController").

I've tried the example application given at the link above with Qt 5.9.6 on
macOS 10.13. When I check the Accessory views checkbox in the configurator
panel, the position of the title of the example window shifts to the right,
but I don't see either the green or red checkerboard patterns in the title
bar.

I can get closer if I edit the main() function and call show() on
leftAccessoryWindow and rightAccessoryWindow just before the call to
macWindow->show(). However in this case, I get small separate windows for
the two accessory windows. If I manually resize one of those windows by
dragging the corner, then the corresponding MacWindow titlebar accessory
view is updated. But that's clearly not the intended behavior.

Our application uses 5.9 because it's a LTS, and we'd prefer to stick with
that version. I haven't tried using a newer Qt version so I don't know if
this problem is due to an older Qt version, the macOS version, or something
else.

Does anyone have any experience getting such a thing to work in a Qt
application?

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

Re: [Interest] minimum macOS runtime version for Qt 5.9+ (Jake Petroules)

[Adam Light]

On Thu, Nov 30, 2017 at 5:10 PM, Steve Schilz  wrote:

>
> Why do people run on older deployment targets?  Inertia of large
> projects!  Our video module on OSX was written 7 years ago to support OSX
> 10.7 using QtKit, which was deprecated at the time.  While we have been
> aware of this for several years, I have only now been assigned to write an
> AVFoundation replacement because the 32 bit subsystem (and hence QtKit), is
> finally being pulled from the operating system.


We are in the same situation. While the QTKit headers were removed from the
10.12 SDK, the functionality does not seem to have been removed from the
OS. If you provide your own copy of the headers, you should be able to
compile and run old QTKit code. At least we're doing that in our Qt 5.9.3
based application. We have added an AVFoundation back-end but my
understanding is that there is not quite feature parity between the two
frameworks so we still use QTKit for some things.

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

[Interest] Using QAbstractScrollArea scrollBarWidget and cornerWidget on Macintosh

[Adam Light]

Hi

We use scroll bar widgets and corner widgets in several QAbstractScrollArea
subclasses in our application. We set the scroll bar policy for the
corresponding scroll bars to AlwaysOn. However, on Macintosh, the OS does
not typically show scroll bars, and this means that our scroll bar and
corner widgets are not visible for most users. In order for them to be
shown, the user must set their system preferences to always show scroll
bars (described in
http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion/).

Does anyone have a good solution for this (other than the obvious solution
which is to avoid using scroll bar widgets and corner widgets)? Ideally I
would be able to override the system setting for individual scroll areas.

An alternative would be to check the value of that system setting on
startup and suggest that the user change it if they don't always have
scroll bars visible. But I haven't been able to find a way to test the
value of that system setting.

Thanks for any ideas

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

Re: [Interest] Compiling a 32-bit application on Macintosh with Qt 5.9 fails

[Adam Light]

On Fri, Jul 28, 2017 at 8:36 AM, Thiago Macieira 
wrote:

> On Friday, 28 July 2017 06:42:26 PDT Adam Light wrote:
> > So if this is a valid reason, what's the trick to getting a 32-bit
> > application to compile? Or is this just a bug?
>
> Sounds like just a bug because we don't test that as often (or at all).
>
>
Fair enough. I've created a bug report at
https://bugreports.qt.io/browse/QTBUG-62199

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

Re: [Interest] Compiling a 32-bit application on Macintosh with Qt 5.9 fails

[Adam Light]

On Thu, Jul 27, 2017 at 12:43 PM, Thiago Macieira  wrote:

> On Thursday, 27 July 2017 11:28:28 PDT Adam Light wrote:
> > Our application can load plugins that are written by users. Our
> application
> > has only had a 64-bit Macintosh version available for 366 days, so most
> of
> > these plugins are 32-bit.
>
> That was the answer I was expecting. It's a valid reason.
>
>
So if this is a valid reason, what's the trick to getting a 32-bit
application to compile? Or is this just a bug?

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

Re: [Interest] Compiling a 32-bit application on Macintosh with Qt 5.9 fails

[Adam Light]

On Thu, Jul 27, 2017 at 9:13 AM, Thiago Macieira 
wrote:

> On quinta-feira, 27 de julho de 2017 09:00:38 PDT Adam Light wrote:
> > I'm not able to successfully compile a project (even an essentially empty
> > project created with the Qt Creator wizard) for 32-bit on Macintosh using
> > Qt 5.9.2.
>
> Why do you want to? Qt does only supports macOS versions that require
> 64-bit
> processors?
>
> (There's one answer I am expecting, just wondering if you may have more)
>
>
Our application can load plugins that are written by users. Our application
has only had a 64-bit Macintosh version available for 366 days, so most of
these plugins are 32-bit. Therefore we also ship a 32-bit version of our
application so that users who have old plugins can still use our
application with their existing plugins. This has worked just fine with Qt
5.6 but as I reported compiling a 32-bit version of our application with Qt
5.9 isn't working the same way as with 5.6.

We plan to support only versions 10.10 and above of the OS, and obviously
only on machines with 64-bit processors. We are also aware of Apple's
announcements about abandoning support for 32-bit desktop applications in
future releases.

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

[Interest] Compiling a 32-bit application on Macintosh with Qt 5.9 fails

[Adam Light]

I'm not able to successfully compile a project (even an essentially empty
project created with the Qt Creator wizard) for 32-bit on Macintosh using
Qt 5.9.2.

It looks like the problem is due to the "-arch x86_64" flag being
improperly inserted into the compiler command. Here's the full command for
one of the files:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-c -pipe -stdlib=libc++ -g -std=gnu++11 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-mmacosx-version-min=10.10 -Wall -W -fPIC -DQT_DEPRECATED_WARNINGS
-DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB
-I../exceptionsTest -I.
-I/qtbuild59/install/mac32/lib/QtWidgets.framework/Headers
-I/qtbuild59/install/mac32/lib/QtGui.framework/Headers
-I/qtbuild59/install/mac32/lib/QtCore.framework/Headers -I.
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/AGL.framework/Headers
-I. -I/qtbuild59/install/mac32/mkspecs/macx-clang
-F/qtbuild59/install/mac32/lib -o main.o ../exceptionsTest/main.cpp


Here is the "Effective qmake call" from the qmake build step in Creator.
This is the default command--I haven't specified any additional arguments.

qmake
/Users/aclight/Documents/qtbugreports/exceptionsTest/exceptionsTest/exceptionsTest.pro
-spec macx-clang CONFIG+=x86 CONFIG+=qml_debug && /usr/bin/make qmake_all


I'm using my own build of Qt from a git checkout of the 5.9 branch (checked
out yesterday afternoon) with the following configure command:

MAKEFLAGS=-j8 ../../qt/configure -confirm-license -debug-and-release
-force-debug-info -opensource -gui -widgets -qpa cocoa -no-qml-debug
-nomake examples -nomake tests -silent -no-sql-mysql -platform macx-clang
QMAKE_APPLE_DEVICE_ARCHS=i386  -skip declarative -prefix
/qtbuild59/install/mac32

I wonder whether https://codereview.qt-project.org/#/c/171757/ is the cause
of this problem.

I'm not sure if this is a bug or just a change in how things work for which
I need to make adjustments to my build configuration. I'm happy to file a
bug report if that's appropriate.

I'm using Xcode 8.3.3 on Sierra.

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

Re: [Interest] Optimizing performance with hundreds of widgets

[Adam Light]

On Wed, Feb 15, 2017 at 9:28 AM, Gibbs, Matt 
wrote:

> Hi All,
>
> I’m working on a Qt-based project to display rapidly updating information
> from a control system.  I want to display hundreds of signals, each
> updating at about 10 Hz.  As a performance test, I’ve thrown 500 Labels in
> a grid layout, and fire a timer every 100 ms which calls setText on each
> label.  This ends up being surprisingly CPU-intensive: on reasonably modern
> hardware (2012 MacBook Pro), I use 70% of one CPU.  This doesn’t leave me
> much overhead to do anything else.
>
> Are there any best practices to reduce CPU usage in this case?
>

Though I haven't checked to see whether or not this actually affects
performance, I would suggest callint setTextFormat(Qt::PlainText) to avoid
the need to inspect the string to determine whether it's rich text.

Also, based on the image you shared, I'd guess that most of the values that
are changing might be better displayed within QLineEdit widgets. You might
find that QLineEdit has better performance because I suspect there is less
to do in terms of laying out the text and such.

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

Re: [Interest] How to be notified when widget is moved to another screen?

[Adam Light]

On Fri, Oct 21, 2016 at 12:47 AM, Elvis Stansvik  wrote:

> 2016-10-21 9:22 GMT+02:00 Elvis Stansvik :
> > Using
> >
> > QApplication::desktop()->screenNumber(widget);
> >
> > it's possible to get the screen number of the screen where the widget
> > is mostly visible.
> >
> > But how can I be notified when this changes for a particular widget?
> >
>
> As a rough approximation, I tried connecting to QWindow::screenChanged
> of the window() for the widget, but it was never emitted when I moved
> the window between monitors.


In my experience, this is much trickier than it seems it should be.

Here is the relevant code from one of the classes in our application that
needs to be aware when it's moved from one display to another:

WMPixmapLabel::WMPixmapLabel(QWidget* parent) :
QLabel(parent),
_allowBitmapsOverride(false)
{
// NOTE: We do this as a single shot timer instead of immediately because
// depending on how this widget is created, its parentage up to a top level
// window may not be established.
QTimer::singleShot(0, this, SLOT(_connectToScreenChangedSignal()));
}

bool WMPixmapLabel::eventFilter(QObject *watched, QEvent *event)
{
if (event->type() == QEvent::WinIdChange) {
if (watched && window() == watched) {
_connectToScreenChangedSignal();
}
}
return false; // Don't filter out the event.
}

/**
\brief Connects to the top level window's screenChanged signal
and installs an event filter on the top level window so we can make
sure we're able to update our pixmap when necessary.
*/
void WMPixmapLabel::_connectToScreenChangedSignal()
{
// Disconnect any existing connections to the _updatePixmap slot.
disconnect(this, SLOT(_updatePixmap()));

// We do this for the side effect that will force this widget's top level
window
// to become a native window if it isn't already. It's required that the
window
// be a native window so that the call to windowHandle() below will return
non-null.
QWindow* theWindow = window()->windowHandle();
if (!theWindow) {
QWidget* winWidget = window();
if (winWidget) {
winWidget->winId();
theWindow = window()->windowHandle();
}
else {
// Should never get here.
Q_ASSERT(0);
}
}
Q_ASSERT(theWindow); // Should never fail.
if (theWindow) {
connect(theWindow, &QWindow::screenChanged, this,
&WMPixmapLabel::_updatePixmap, Qt::UniqueConnection);
installEventFilter(theWindow);
}

_updatePixmap();
}

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

Re: [Interest] FUD around licensing (From What don't you like about Qt?)

[Adam Light]

On Mon, Oct 10, 2016 at 6:18 AM, Giuseppe D'Angelo <
giuseppe.dang...@kdab.com> wrote:

> Hi,
>
> On 10/10/16 10:22, Carel Combrink wrote:
>
>> The very first comment on the youtube video:
>> /"The latest versions do not seem to be free/" - iddn
>>
>> I really hope the free edition of such a great tool can be moved out of
>> the clutter about the licensing.
>>
>
>
> PS: I wanted to reply directly on there but then got prompted to create
>> a Youtube channel and there is no single link I can give someone for Qt
>> Creator except by going into the page source and seeing it should
>> be https://www.qt.io/download-open-source/#section-9
>>
>
> Thanks for that :)
>
> I was about to ask if it would be possible to split that page in multiple
> (cross-linked) pages, in order to maximize SEO and getting better search
> engine hits; but then I found out that that particular page is actually
> deliberately excluded from search engines (there's a  noindex in the
> page). :\
>
>
>
I ran into this recently as well. In the past, I would Google "qt creator
open source download" to get to the page where I could easily download
creator, but that page is no longer a result (at least nowhere near the
top). Instead, the top result is now https://www.qt.io/download/, which as
others have said makes it quite easy to come to the conclusion that Qt
Creator is not appropriate for use due to licensing issues.

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

[Interest] Prevent tabbing of Qt application on macOS Sierra

[Adam Light]

macOS Sierra added an automatic tabbing mechanism that is enabled for
applications by default. This behavior is entirely inappropriate for our Qt
5.6 based application, and I'd like to be able to have my application
opt-out of this behavior.

https://developer.apple.com/library/content/releasenotes/AppKit/RN-AppKit/#10_12Window
Tabbing describes the API behind this feature, and includes this:
"The application should explicitly opt-out of automatic window tabbing by
calling [NSWindow setAllowsAutomaticWindowTabbing:NO]"

Does anyone know how I can do this in a Qt application? My understanding of
Cocoa/Objective-C is minimal, and I have no idea where I would make such a
call.

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

Re: [Interest] Depth-first filtering for QAbstractProxyModel

[Adam Light]

On Tue, Sep 6, 2016 at 12:20 PM, Thompson, Adam B. 
wrote:

>
> My question: can anyone provide some tips on how to properly subclass
> QAbstractProxyModel so I can provide some custom depth-first filtering
> capabilities? (Sorting isn’t really necessary at the moment, really just
> filtering.)
>
>
>
Our application does something similar to what you describe. We have
several item types: folders (which may have children), and waves,
variables, and strings, which may not contain children.

Our custom QSortFilterProxyModel class allows sorting and filtering by item
type and/or name. In order to get around the issue you describe, our
filterAcceptsRow method essentially always returns true for items of type
folder. For other item types, we actually test whether the type is
appropriate for the filter settings and whether the name matches the
specified pattern.

This isn't optimal, because it can be difficult to wade through all of the
empty folders displayed in the view, but in most cases the number of
non-folder items greatly outnumbers the number of folder items so the
filtering is still quite useful. It's also very fast since we're not
inspecting all descendants of each item when determining if it should be
filtered out or not.

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

Re: [Interest] widget rendering (alignment, sizing) issues on OS X

[Adam Light]

On Tue, May 31, 2016 at 1:06 AM, René J.V.  wrote:

> On Monday May 30 2016 15:22:50 Adam Light wrote:
>
> Hi,
>
> >To address this in our application, we use a QProxyStyle subclass in which
> >we reimplement layoutSpacing on Macintosh like so:
> >
> >   if (spacing > 2) {
> >   spacing /= 2;
> >   }
>
> You're full of interesting suggestions :)
>
> Initial testing shows that could indeed be a solution, though a factor two
> seems a bit too much for radio buttons. And the way I implemented it at 2am
> it also nuked the colour palette which left me with windows sporting Qt's
> proprietary gray/beige. I take it you initialise the spacing variable from
> QProxyStyle::layoutSpacing(/*arguments we received*/)?
>
>
Yes, that's correct.


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

Re: [Interest] widget rendering (alignment, sizing) issues on OS X

[Adam Light]

On Mon, May 30, 2016 at 12:39 AM, René J. V.  wrote:

> René J.V. Bertin wrote:
>
> Hi,
>
> >
> >> In our application, we have the following code in a
> >> QApplication::eventFilter reimplementation for this exact reason:
> >>
> >> case QEvent::ChildAdded:
> > ...
> >> theChildWidget->setAttribute(Qt::WA_LayoutUsesWidgetRect, true);
> >
> > That's very interesting, I hadn't yet realised there was a way to do
> this for
> > every widget created.
>
> I tried this, putting the event filter in my platform theme plugin where it
> affects each and every widget in each and every application when that
> plugin is
> set to load at startup :)
>
> Doesn't help. In fact, it makes interfaces even more "bloated" than they
> are,
> with even more space among widgets than is already being (IMHO) wasted.
> I'm not
> really sure if that's something that shows up in particular in applications
> using KF5 features for their interface but the result is that they look as
> if
> designed for the visually or motor impaired.
> (Or to use an analogy: KDE's new default style is called Breeze to suggest
> a
> fresh new wind ... the native Mac style could be called Draughty in that
> mindset
> :))
>

To address this in our application, we use a QProxyStyle subclass in which
we reimplement layoutSpacing on Macintosh like so:

if (spacing > 2) {

spacing /= 2;

}


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

Re: [Interest] widget rendering (alignment, sizing) issues on OS X

[Adam Light]

On Tue, May 24, 2016 at 11:40 AM, René J. V.  wrote:

> René J.V. Bertin wrote:
>
> I think I posted the question below to the wrong list.
>
> Has anyone ever noticed widgets not being aligned correctly because of
> sizing
> issues on OS X, outside of KDE applications, as shown in the link below?
> https://bugs.kde.org/show_bug.cgi?id=363423
>
> I've dug around some more on this and had some feedback which led me to
> understand that this happens when widgets are used that somehow do not use
> QMacStyle but QStyle instead.
>
> The fixes I found are extremely simple, requiring only the
> Qt::WA_LayoutUsesWidgetRect attribute to be set on the widget in question:
>

In our application, we have the following code in a
QApplication::eventFilter reimplementation for this exact reason:

case QEvent::ChildAdded:

{

QChildEvent* childEvent = 
static_cast(event);

if (childEvent->child()->isWidgetType()) {

QWidget* theChildWidget = 
qobject_cast(childEvent->child());


theChildWidget->setAttribute(Qt::WA_LayoutUsesWidgetRect, true);

}

}

break;


We do this on Macintosh and Windows. Testing I did years ago did not show
any effect on Windows, but without doing this on Macintosh the layouts of
many of our dialogs do not look very good. The attribute probably doesn't
actually need to be set on every widget type, but I didn't notice much harm
in doing so.

I believe that if you set a style sheet on a widget, then it's style will
no longer be/derive from QMacStyle on Macintosh. So one solution might be
not using QWidget::setStyleSheet. But that may not be sufficient to remove
the need for the WA_LayoutUsesWidgetRect attribute.

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

[Interest] Qt 5.6.0 online installer does not provide VS runtime libraries

[Adam Light]

On a Windows 10 virtual machine that is essentially a clean install of
Windows 10, I went to http://www.qt.io/download-open-source/ and downloaded
the online installer (
http://download.qt.io/official_releases/online_installers/qt-unified-windows-x86-online.exe).
I then executed the application and was given the following error message:
"The program can't start because MSVCP120.dll is missing from your
computer. Try reinstalling the program to fix this problem."

I got the same result with the offline installer (
http://download.qt.io/official_releases/qt/5.6/5.6.0/qt-opensource-windows-x86-msvc2013_64-5.6.0.exe
)

It seems rather unfriendly for the installer to not install the necessary
VC libraries as well. Is this intentional?

PS: I am trying to write instructions for an outside firm to use to
translate our application. I know how to work around this problem, but I
wouldn't expect others to.

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

[Interest] Closing Jira bug reports

[Adam Light]

What's the protocol for getting an issue marked as closed that clearly
should be closed. My immediate example is
https://bugreports.qt.io/browse/QTBUG-31474 but it's not uncommon that I'm
browsing issues and see a report that needs to be closed but I don't have
the permission to do so. Sometimes leaving a comment will prompt someone
with the right permissions to close it, but that doesn't always work.

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

[Interest] Creating a QCursor from a pixmap

[Adam Light]

Is there a way to create a QCursor from a pixmap that looks good on both
regular and high DPI displays? I can set the devicePixelRatio of the pixmap
that I pass to the QCursor constructor, but I don't necessarily know which
screen the cursor will be displayed on (and it could move from one to
another).

Cursors created using the QCursor(Qt::CursorShape shape) overload do look
good on both standard and high DPI displays, but unfortunately our
application needs custom cursors as well.

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

[Interest] Crashes related to QAccessibleWidget on OSX

[Adam Light]

We've had a few crash reports from users of our application that seem to be
caused by QAccessibleWidget. I've experienced it myself once or twice as
well. In all cases it's happened on OSX, but some reports are on 10.10 and
some on 10.11.

We've seen the crash with both Qt 5.5.1 and 5.6 beta.

Here are a few examples of the call stack of the crashed thread.

0 org.qt-project.QtWidgets 0x06714dd0 QAccessibleWidget::state() const + 48
1 libqcocoa.dylib 0x09518baa 0x94dd000 + 244650
2 libqcocoa.dylib 0x095151e5 0x94dd000 + 229861
3 com.apple.AppKit 0x95a3d9bb
 _NSAccessibilityEntryPointIsAttributeSupported + 292
4 com.apple.AppKit 0x95a3d88f
 NSAccessibilityEntryPointIsAttributeSupported + 24
5 com.apple.AppKit 0x95a3d85b ValueOfAttributeWithDefault + 64

0 org.qt-project.QtWidgets 0x00011428fc21 QAccessibleWidget::rect()
const + 33
1 org.qt-project.QtGui 0x000114685bf9
QAccessibleObject::childAt(int, int) const + 73
2 libqcocoa.dylib 0x000116d6a70d 0x116d33000 + 227085
3 com.apple.AppKit 0x7fff9182f658 -[NSWindow(NSWindowAccessibility)
accessibilityHitTest:] + 508
4 com.apple.AppKit 0x7fff91445219
-[NSApplication(NSApplicationAccessibility) accessibilityHitTest:] + 254
5 com.apple.AppKit 0x7fff9142b223 CopyElementAtPosition + 313

0 org.qt-project.QtWidgets 0x066a2600 QAccessibleWidget::rect() const +
48
1 org.qt-project.QtGui 0x069e853f QAccessibleObject::childAt(int, int)
const + 63
2 libqcocoa.dylib 0x094d7ac0 0x949d000 + 240320
3 libqcocoa.dylib 0x094bd819 0x949d000 + 133145
4 com.apple.AppKit 0x9c86241a -[NSWindow(NSWindowAccessibility)
accessibilityHitTest:] + 572
5 com.apple.AppKit 0x9c45c297
-[NSApplication(NSApplicationAccessibility) accessibilityHitTest:] + 340
6 com.apple.AppKit 0x9c43d95e CopyElementAtPosition + 475

The rest of the call stack is mostly calls to system routines. Sometimes
there is some of our application's code much earlier in the call stack, and
sometimes there is nothing from our application other than the call to
main().

I haven't been able to figure out a way to reproduce this. I have tried
enabling voice over and the screen reader functionality provided by the
system in an attempt to provoke the crash, but I wasn't able to get the
crash by turning on those features. As far as I know, none of the users who
have run into this crash have any accessibility features turned on. I know
I don't (except in the case mentioned above when I turned them on to try to
provoke the crash).

I don't understand why there are no symbols given for the calls within
libqcocoa.dylib.

Does anyone have any suggestions for what I can do to figure out what is
causing the crash?

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

Re: [Interest] qmake.exe -query gets stuck

[Adam Light]

On Fri, Dec 18, 2015 at 2:02 AM, Joerg Bornemann <
joerg.bornem...@theqtcompany.com> wrote:

> On 17-Dec-15 23:14, q...@supradigital.org wrote:
>
> A colleague of mine saw something similar on his Windows 10 machine last
>>> week. He would double click on the Creator Icon (version 3.5.1 I
>>> believe) and it would appear that Creator was not started, though task
>>> manager showed it running. Eventually we figured out that disabling his
>>> virus scanner fixed the problem. I don't remember which virus scanner he
>>> was using.
>>>
>>
>> That did indeed fix it. Thanks for the hint!
>>
>
> What virus scanner do you use?
> Maybe we can fix the issue. :)
>

AVAST. I'm not sure what version it was.

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

Re: [Interest] qmake.exe -query gets stuck

[Adam Light]

On Wed, Dec 16, 2015 at 3:55 PM,  wrote:

> Hello there,
>
> [System Windows7 64bit]
>
> I just tried to install Qt(32bit) for a less knowledgable person and
> utterly failed. Installation went successfull. At the end the installer
> offered to start QtCreator for us. We said sure and it did. However we
> never saw Qt Creator. The task manager showed it running, along with the
> child "qmake.exe -query". This qmake.exe turns out to be impossible to
> kill.
>
> I also tried calling it manually and sure enough it got stuck forever.
> Unkillable.
>
> Any advice? We tried this with Qt 5.5.0 and 5.5.1. Same result.
>

A colleague of mine saw something similar on his Windows 10 machine last
week. He would double click on the Creator Icon (version 3.5.1 I believe)
and it would appear that Creator was not started, though task manager
showed it running. Eventually we figured out that disabling his virus
scanner fixed the problem. I don't remember which virus scanner he was
using.

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

Re: [Interest] Changes in Qt 5.6 on Windows HiDPI

[Adam Light]

On Thu, Nov 12, 2015 at 3:49 PM, Adam Light  wrote:

> We've just started testing our application using Qt 5.6 (self built from
> Nov. 10 git checkout).
>
> It appears that the behavior of QDesktopWidget::logicalDpiX (and Y) has
> changed since Qt 5.5.
>
> We bought a Dell Inspiron 15 laptop with a High DPI display. If I open
> Control Panel, choose Display, and click the "set a custom scaling level"
> link, the scaling factor was set to 250% out of the box. When we run our
> application and call QApplication::desktop()->logicalDpiX(), the value
> returned is 80. Using Qt 5.5, that would have returned 240 (2.5 * 96).
>
> Is this change intentional? This change breaks a lot of the drawing code
> in our application, and so I'd like to know whether we need to adapt our
> application or if I should report this as a bug.
>
> Additionally, I notice that if I call
> QApplication::desktop()->devicePixelRatioF(), the returned value is 3. I
> would expect that 2.5 is returned.
>

For what it's worth, I've just created
https://bugreports.qt.io/browse/QTBUG-49465 for the devicePixelRatioF()
issue, since I'm pretty sure that's a bug.

Adam

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

Re: [Interest] Changes in Qt 5.6 on Windows HiDPI

[Adam Light]

On Fri, Nov 13, 2015 at 1:00 AM, Julius Bullinger <
julius.bullin...@asctec.de> wrote:

> Hello Adam,
>
>
>
> do you use the new environment variables QT_AUTO_SCREEN_SCALE_FACTOR=1 ?
>
> Additionally, make sure to unset the deprecated  QT_DEVICE_PIXEL_RATIO.
>
>
>
> You can do this in your shell for testing, and programmatically with
> qputenv [1].
>
>
>
We are not setting any environment variables whatsoever.

I have read through the documentation at
https://doc-snapshots.qt.io/qt5-5.6/highdpi.html several times now and I'm
having a hard time figuring out what our application needs to do.

I did try setting  QT_AUTO_SCREEN_SCALE_FACTOR=1, both with and without
calling QApplication::setAttribute(Qt::AA_EnableHighDpiScaling) before the
QApplication is constructed, and I get the same results: that is, with the
Windows "set a custom scaling level" setting set to 200%,
QApplication::desktop()->logicalDpiX() returns 96, whereas with Qt 5.5 it
returned 192.

We can live with either value that's returned, I'm just trying to figure
out if this particular change in behavior with Qt 5.6 is intentional or not.

The second problem is that when I set the system "set a custom scaling
level" to 250%, which is the factory value for the 15" Dell Inspiron laptop
we purchased, QApplication::desktop()->devicePixelRatioF() returns 3, which
is wrong--it should be 2.5. I'm happy to file a bug report about this, but
I'm hoping to make sure that I understand what the intended behavior is
before I call this a bug.

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

[Interest] Changes in Qt 5.6 on Windows HiDPI

[Adam Light]

We've just started testing our application using Qt 5.6 (self built from
Nov. 10 git checkout).

It appears that the behavior of QDesktopWidget::logicalDpiX (and Y) has
changed since Qt 5.5.

We bought a Dell Inspiron 15 laptop with a High DPI display. If I open
Control Panel, choose Display, and click the "set a custom scaling level"
link, the scaling factor was set to 250% out of the box. When we run our
application and call QApplication::desktop()->logicalDpiX(), the value
returned is 80. Using Qt 5.5, that would have returned 240 (2.5 * 96).

Is this change intentional? This change breaks a lot of the drawing code in
our application, and so I'd like to know whether we need to adapt our
application or if I should report this as a bug.

Additionally, I notice that if I call
QApplication::desktop()->devicePixelRatioF(), the returned value is 3. I
would expect that 2.5 is returned.

I see the note at https://doc-snapshots.qt.io/qt5-5.6/highdpi.html that
says:
Note: Non-integer scale factors may cause significant scaling/painting
artifacts.

That's unfortunate, as I suspect that non-integer scale factors will be
relatively common. I can change the scale factor to 200%, but when I do
that everything is a little too small, and I'm relatively young and have
good eyesight. Requiring our users to use integer scale factors is
something we'd rather not do.

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

Re: [Interest] Qt 5.5 and accessibility on OSX

[Adam Light]

On Fri, Oct 23, 2015 at 1:42 AM, deDietrich Gabriel <
gabriel.dedietr...@theqtcompany.com> wrote:

> Hi Adam,
>
>
> Can you post your example? We could have a look at it here as well and see
> if our measurements are consistent.
>
>
> I don't have a simple example at the moment. I discovered this when
opening a 650MB file sent to us by a customer using our application. It
currently takes about 13 minutes to open the file (using the current
shipping version of our application that does not use Qt takes about 1.5
minutes to load the file), and in the process of profiling the load, I saw
what appears to be a lot of time spent in QAccessibleEvent::uniqueId().
It's likely that I could put something simpler together using our
application, and I could make the compiled version of that available for
testing and profiling, but not the source. Coming up with a self contained
example would probably take a fair amount of time.

That's why I was hoping there was a simple killswitch for accessibility so
I could at least make sure that I'm on the right track here.

We're building our own Qt libraries (with relatively standard configuration
flags and only a few patches to Qt code that have nothing to do with
accessibility). Is there a configure option I can use to remove
accessibility in the libraries altogether?

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

[Interest] Qt 5.5 and accessibility on OSX

[Adam Light]

Hi

I'm using Qt 5.5.1 on Mac OSX 10.10.5.

I noticed my application being slower than expected, so I compiled a
release build and ran the application under the Instruments time profiler
(using release builds of the Qt libraries).

If I'm understanding the data correctly, about 45% of the time is spent in
QAccessibleEvent::uniqueId() and functions that calls. Many of these are
after calling QLabel::setText().

As far as I can tell, my application is doing nothing to make itself
accessible, and I don't have any accessibility features turned on in the
OS. So I'd be surprised if what should really amount to a no-op is causing
such a performance problem.

Is there a way for me to disable all accessibility in Qt so I can repeat
the profiling and see if performance improves?

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

Re: [Interest] How are High DPI Icons supposed to work?

[Adam Light]

On Tue, Sep 29, 2015 at 1:20 AM, Julius Bullinger <
julius.bullin...@asctec.de> wrote:

> On Tuesday, 29 September 2015 08:32 Thiago Macieira wrote:
> > And QT_DEVICE_PIXEL_RATIO is deprecated -- it will print a qWarning in
> Qt 5.6 now. Please don't set it.
>
> I know about the upcoming changes in 5.6, but AFAIK this the only option
> in 5.5 right now.
> But please enlighten me if there's a better way working with Qt 5.5.
>
>
On Macintosh, it's not necessary to set QT_DEVICE_PIXEL_RATIO when using Qt
5.5, as the correct resource is used (in buttons at least, but not in some
other widgets that display icons). However, AFAIK, using
QT_DEVICE_PIXEL_RATIO is required to get this to work at all on Windows
with Qt 5.5.

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

Re: [Interest] High DPI support in QT (Windows)

[Adam Light]

On Wed, Sep 23, 2015 at 4:01 AM, Sorvig Morten <
morten.sor...@theqtcompany.com> wrote:

> Hi,
>
> Behind the scenes the new 5.6 support is actually a rewrite, where we have
> moved the implementation from the platform plugins to QtGui.
>
> The user-visible changes are the environment variables:
>
> QT_DEVICE_PIXEL_RATIO: deprecated, and replaced by
>
> QT_SCALE_FACTOR: which takes a numeric scale factor, and
>
> QT_AUTO_SCREEN_SCALE_FACTOR: (bool) reads the OS settings on X11
> and Windows.
>
> There is no corresponding C++ API for applications at this point. One way
> around that is to call qputenv() as the very  first thing in main().
>
> I’m not too familiar with the Windows particulars. I can answer general
> questions about High DPI support if there are any.
>

Does the new code deal with actually drawing widgets containing icons
correctly depending on the resolution of the display that widget is
currently displayed on?

For example, covering the following previous (possibly abandoned?) patches:
https://codereview.qt-project.org/#/c/108770/
https://codereview.qt-project.org/#/c/108775/

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

Re: [Interest] High DPI support in QT (Windows)

[Adam Light]

On Fri, Sep 18, 2015 at 1:38 AM, Pavlo Dyachenko  wrote:

> Hi QT team, I posted a question on the forum about high DPI support but
> then was recommended this mailing list instead:
> According to documentation here http://doc.qt.io/qt-5/highdpi.html QT
> 5.4+ introduces high DPI support. However, either I’m missing something
> fundamental or the current support is still in very early stages. I’m
> writing a brand new application so I have a chance to do it right from the
> ground up. I understand that I would have to use layouts instead of fixed
> positioning etc, but there always going to be cases in which I would have
> to specify, for example a minimum/maximum size of a control. I can specify
> them in the editor, but these are device pixels. So if I change my Windows
> settings to use 150% DPI then min/max values in the editor would be too
> small. Of course I can obtain that ratio and adjust all the required values
> in code, but then what kind of high DPI support does QT give for me if I
> have to do everything by hand? I mean how is it different to pre QT 5.4?
>
> Then an interesting one is QT_DEVICE_PIXEL_RATIO environment variable. It
> does exactly what I need, it multiplies all pixels set in editor by a
> factor. But why is it an environment variable and not a per application
> setting? Why does it only support integer values of 2, 3 etc, since we know
> that Windows has settings like 125, 150% etc. and why couldn’t it
> automatically read the Windows setting and set itself to that value?
>
>
Though I have not yet tried it, my understanding is that in Qt 5.6, the
support for HiDPI has been improved. See
https://doc-snapshots.qt.io/qt5-5.6/highdpi.html for the most recent
documentation.

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

[Interest] Determining if a glyph can be painted for a given character

[Adam Light]

Hi

Our application has a QPlainTextEdit subclass, and one of its features is
that it has an option to display whitespace (such as line endings). One of
the whitespace symbols we use is \u21b5 (that's
DOWNWARDS ARROW WITH CORNER LEFTWARDS if anyone cares).

Our current code reimplements QPlainTextEdit::paintEvent() and has code
like this:

QPainter painter(viewport());

const QChar CRGlyph((ushort)0x21b5);
QRawFont rf(QRawFont::fromFont(painter.font()));
const bool fontHasCRGlyph = rf.supportsCharacter(CRGlyph);


We only try to paint the whitespace character if fontHasCRGlyph is true,
since otherwise we would end up painting the empty rectangle that indicates
a character was not found, and that doesn't look good.

The problem is that on some platforms, including Windows 7 and Mac OSX
10.10, but not Mac OSX 10.9, fontHasCRGlyph is false. Yet, if I do
something simple like the following, the correct glyph for the same
character is displayed:
setPlainText(CRGlyph);

I suspect the reason for this is that the font in use by the QPlainTextEdit
does not contain the CRGlyph character, but a fallback font is available
for use that does contain the character, so it is displayed properly.
However, I initialize the QRawFont object with the primary font used in the
widget, which is lacking the glyph.

Does anyone have any suggestions of how I can test that a character can be
displayed correctly before I try to draw the character on screen?

Thanks for your help
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Unassigned bug report

[Adam Light]

In my experience, bugs that start out unassigned never end up getting
triaged, and thus fixed (granted, a small sample size).

I realize that someone *could* work on a bug that's unassigned.

Adam

On Tue, Jun 9, 2015 at 6:14 PM, Thiago Macieira 
wrote:

> On Tuesday 09 June 2015 12:49:02 Adam Light wrote:
> > Hi
> >
> > There's a bug report (https://bugreports.qt.io/browse/QTBUG-46546) that
> I'm
> > interested in but it is unassigned. I assume that the component chosen
> had
> > nobody set as the automatic assignee. Could someone with the appropriate
> > permissions assign the bug so it can at least be triaged.
>
> Bugs don't need to be assigned to be triaged.
>
> Assigning is only required when someone takes responsibility for fixing it
> (usually when they start doing it or they know that they will work on it
> soon[ish]). It's an indication to others that they don't need to look into
> fixing this issue.
>
> Unassigned issues are open to anyone for fixing.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Unassigned bug report

[Adam Light]

Hi

There's a bug report (https://bugreports.qt.io/browse/QTBUG-46546) that I'm
interested in but it is unassigned. I assume that the component chosen had
nobody set as the automatic assignee. Could someone with the appropriate
permissions assign the bug so it can at least be triaged.

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

[Interest] QTBUG-45907: [Mac] Crash when file is dragged onto a QWidget

[Adam Light]

I created a bug report for a crash on Macintosh with Qt 5.5 (
https://bugreports.qt.io/browse/QTBUG-45907). When I report a reproducible
crash with detailed information, the bug is typically at least marked as
accepted pretty quickly. However, in this case, nobody appears to have
triaged it yet.

I had selected GUI: Drag and Drop as the component.

I noticed that it was unassigned. I guess that means that for the GUI: Drag
and Drop component, there is nobody who is automatically assigned those
tickets to triage?

If anyone with the appropriate power can at least triage this bug, that
would be great. I'd hate for it to get lost.

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

Re: [Interest] Survey: do you override QCoreApplication::notify? Why?

[Adam Light]

John Weeks and I are working on the same application, so don't double count
this, but I wanted to clarify:

On Wed, Apr 15, 2015 at 4:45 PM, Thiago Macieira 
wrote:

>
>  2) use it to catch exceptions and continue execution?
>  or use it to catch and abort?
>
>
If we catch an uncaught exception from our QApplication::notify()
reimplementation, we give the user the option to save his work. Depending
on the reason for the uncaught exception, this may or may not actually
succeed, but we at least allow for the possibility. In my experience, it
typically is successful.

Then, whether or not he chose to save the work, we call quit().

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

Re: [Interest] QOpenGLWidget and text

[Adam Light]

On Sat, Apr 4, 2015 at 2:57 AM, Till Oliver Knoll <
till.oliver.kn...@gmail.com> wrote:

>
> >> ...
> >>
> >> That's the way to draw "over OpenGL" - not with a restricted "drawText"
> convenience method which happened to be placed in some random API
> (QGLWidget) over a decade ago ;)
> >
> > The problem is I don't *want* to draw "over" GL¹. I *need* to draw *in*
> > GL, specifically I need to specify the text location in terms of the GL
> > modelview space.
> > ...
> > Overpainting techniques are fine... *for overpainting*. That's not what
> > I'm doing.
>
> Clearly I cannot predict your application's requirements, but
> "overpainting", that's exactly what you were doing apparently, all the
> time. You said so yourself, you were using
>
>  http://doc.qt.io/qt-4.8/qglwidget.html#renderText
>
> I've never used this method myself, but from what I gather you specify the
> text coordinates in /window/ coordinates - /not/ world (or model)
> coordinates!
>
> So all the "renderText" does is it "overpaints" the given text into the
> current GL buffer (by disabling the depth test).
>
> You get exactly the same result (probably even a better one due to better
> anti-aliasing) by using a QPainter and "overpaint" at the same window
> coordinates.
>
> So this method did not do what you now tell us what your requirements are.
> So one reason more to quickly remove it (before people come and request to
> please extend the API such that the coordinates could be specified also in
> model/world coordinates ;)).
>

I think you missed this overload of renderText:
http://doc.qt.io/qt-4.8/qglwidget.html#renderText-2

This takes object coordinates, including a z value.

The removal of this overload of renderText() was a significant blow to our
efforts in moving from 4.8 to 5.

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

Re: [Interest] [OS X] qmake -spec macx-clang-32 on a 64bit system

[Adam Light]

On Tue, Mar 10, 2015 at 6:29 AM, René J.V.  wrote:

> Hello,
>
> I am getting strange behaviour from qmake, trying to generate a 32bit
> build with it on a 64bit system. qmake in fact seems to ignore the -spec
> argument (as long as it's not in error, that is). I get exactly the same
> Makefile even when I tell qmake to use linux-g++, for instance ...
> And this time I can rule out any interference from the MacPorts runtime:
>
> %> ( cd
> qt5dsql3-mp9-work/qt-everywhere-opensource-src-5.4.1-i386/qtbase/src/plugins/sqldrivers/sqlite
> ; /opt/local/libexec/qt5/bin/qmake -r PREFIX=/opt/local
> QMAKE_MACOSX_DEPLOYMENT_TARGET=10.9 CONFIG+=release
> INCLUDEPATH+=/opt/local/include LIBS+="-L/opt/local/lib -lsqlite3" -spec
> macx-clang-32 )
>

I'm not sure if this matters, but before I execute configure, I always
execute the following commands:

cd /qtbuild5/build/mac32
rm -rf *
rm .qmake.*

I do this for both 32 and 64 bit builds.

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

Re: [Interest] [OS X] 32bit build on 64bit system?

[Adam Light]

On Mon, Mar 9, 2015 at 6:14 AM, René J.V.  wrote:

> Hi,
>
> Following up on the earlier discussion of 32bit Qt builds.
> Is it possible to do a 32bit Qt build on a 64bit system? I just tried to
> build Qt 5.4.1 using `configure -platform macx-clang-32`. I did get a 32bit
> qmake executable, but the build already failed on creating
> libQt5Bootstrap.a :
>
>
We use the following configure command with a Git checkout of the 5.4
branch to build 32-bit Qt builds without problems:
MAKEFLAGS=-j16 ../../qt/configure -confirm-license -debug-and-release
-opensource -gui -widgets -qpa cocoa -no-qml-debug -nomake examples -nomake
tests -silent -no-sql-mysql -platform macx-clang-32 -no-c++11 -skip
declarative -prefix /qtbuild5/install/mac32

Note that we do not have any pieces of mac ports installed.

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

Re: [Interest] [OSX/iOS] Garbage collection still in place in Qt?

[Adam Light]

On Wed, Mar 4, 2015 at 5:36 AM, Sorvig Morten <
morten.sor...@theqtcompany.com> wrote:

>
> This does not prevent applications from using ARC since it can be enabled
> per translation unit. We would like to start using ARC internally in Qt as
> well, but the requirement to drop 32-bit support may be too steep at this
> point in time. (Question for interest@: is 32-bit support important?)
>
>
For our application, YES!

Our application allows users to use/write external C/C++ libraries that our
application loads. On Macintosh, the shipping (non-Qt) version of our
application has only a 32-bit version. Once we release the new version
(using Qt), we will want to continue to provide a 32-bit version as well as
a 64-bit version so that users using existing external libraries (32-bit)
can continue to use our application. A lot of these libraries are pretty
old and not likely to be recompiled for 64-bit any time soon, so that's why
we really need to ship a 32-bit version of our application.

To answer Thiago's question, we are building our own version of 32-bit Qt
on OSX from the 5.4 branch just fine (though we're not using Webkit, for
what that's worth).

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

Re: [Interest] Deploying Qt to MacOs still...errr, sucks?

[Adam Light]

On Wed, Feb 11, 2015 at 6:08 AM, Mike Krus  wrote:

> Hi all,
>
> this tool is quite useful: https://github.com/auriamg/macdylibbundler
> does the install_name_tool dance for the libs that macdeployqt ignores.
> So I run macdeployqt, then dylibbundler
> Then I still need a script to handle other plugins (for example of OSG).
> And do the code signing…
> And build a nice dmg…
>
>
>
If you're using Qt 5 (maybe only 5.4), macdeployqt may be able to help with
the code signing and possibly the dmg part:

/qtbuild5/install/mac64/bin/macdeployqt --help

Usage: macdeployqt app-bundle [options]

Options:

   -verbose=<0-3> : 0 = no output, 1 = error/warning (default), 2 =
normal, 3 = debug

   -no-plugins: Skip plugin deployment

   -dmg   : Create a .dmg disk image

   -no-strip  : Don't run 'strip' on the binaries

   -use-debug-libs: Deploy with debug versions of frameworks and
plugins (implies -no-strip)

   -executable= : Let the given executable use the deployed
frameworks too

   -qmldir= : Deploy imports used by .qml files in the given path

   -always-overwrite  : Copy files even if the target file exists

   -codesign=  : Run codesign with the given identity on all
executables


I haven't tried using the -codesign flag because I came up with my own
script to do that before it was possible to do it using macdeployqt.

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

[Interest] plugins deployed by macdeployqt

[Adam Light]

I'm using a recently built version of Qt 5.4 (from the 5.4 branch) on Mac
OSX 10.9.5.

I'm using macdeployqt to deploy my application. I'd like to minimize the
frameworks and plugins that are deployed to only those that are necessary,
but I'm having a hard time figuring out how to do that.

If I use the -no-plugins option to macdeployqt, the frameworks that are
deployed match those that the application actually uses:

> macdeployqt Igor64.app -no-plugins
> ls -l Igor64.app/Contents/Frameworks/

QtCore.framework
QtGui.framework
QtMacExtras.framework
QtNetwork.framework
QtOpenGL.framework
QtPrintSupport.framework
QtSvg.framework
QtWidgets.framework
libtbb.dylib
libtbbmalloc.dylib


If I omit the -no-plugins option, I get a bunch of plugins, most of which
my application is not using. Because many of the plugins have dependencies
on frameworks that my application is not otherwise using, I also get lots
of additional frameworks deployed in the bundle:

> macdeployqt Igor64.app
> ls -l Igor64.app/Contents/Frameworks/
QtCore.framework
QtDeclarative.framework
QtGui.framework
QtLocation.framework
QtMacExtras.framework
QtMultimedia.framework
QtMultimediaWidgets.framework
QtNetwork.framework
QtOpenGL.framework
QtPositioning.framework
QtPrintSupport.framework
QtQml.framework
QtQuick.framework
QtScript.framework
QtSensors.framework
QtSql.framework
QtSvg.framework
QtWidgets.framework
QtXmlPatterns.framework
libtbb.dylib
libtbbmalloc.dylib

> ls -l Igor64.app/Contents/PlugIns/
accessible
audio
bearer
geoservices
iconengines
imageformats
mediaservice
platforms
playlistformats
position
printsupport
qml1tooling
sensorgestures
sensors

Is there a way to get macdeployqt to only deploy the frameworks and plugins
that my application uses?

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

Re: [Interest] QWidget + friends; How to restore properties across sessions?

[Adam Light]

[Resending to the list]

Mark:

On Sat, Aug 16, 2014 at 11:12 AM, Mark Gaiser  wrote:

> That is roughly the solution i'm looking for.
> But i'd like to go one step further. Do you know of some way - without
> editing the Qt source itself - to automatically pass each QWidget the
> gets constructed through the ConfigManager class? That would remove
> the need to add each GUI "manually" (in your case the Config UI main
> widget) in the ConfigManager.
>
>
I'm not aware of a way to do exactly what you requested, but you can get
pretty close if you reimplement QApplication::notify() and look for
the QEvent::ChildAdded event. That will allow you to set up property saving
on any child widgets, which should include all of the widgets you're
displaying to the user.

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

Re: [Interest] Best way to build Qt5 distribution for internal development

[Adam Light]

Michael:


On Fri, Aug 8, 2014 at 7:39 AM, Michael Jackson 
wrote:

> In the past I have provided my developers with a custom build of Qt 4.8.x
> for their VS version (2010, 2012, 2013) all 64 bit versions. This was done
> via a combination of a self compile and creating an installer using the Qt
> Installer Framework. The basics are this:
>
>
We do something similar, though in our case a git checkout of the Qt
source, as well as a few sync scripts I built, are checked into a
Subversion repository. All of our developers check out from the Subversion
repository and then run the sync script, which uses rsync to get the build
and install files from our server.

We have both a Qt 4.8.6 and 5.4-dev build built with VS2013 as well as Mac
OSX builds and this process works pretty well for us.


> I am using the following to configure through a "Visual Studio 2013 x64
> Command Prompt"
> configure -opensource -confirm-license -shared -debug-and-release -prefix
> C:/Developer/x64/Qt-5.3.1-x64 -skip webkit -platform win32-msvc2013
>
>
The config command we use (from the VS2013 x64 command prompt) is:
set MACHINE=x64
c:\qtbuild5\qt\configure -confirm-license -make-tool jom -debug-and-release
-opensource -gui -widgets -opengl desktop -mp -prefix
C:\qtbuild5\install\win64

In our case the git checkout of Qt is at C:\qtbuild5\qt.

After configure, I execute:
jom
jom install

Then I run a script that rsyncs from my build machine to the server to
upload the build products to the server. My C:\qtbuild5\install\win64\bin
directory contains assistant.exe, designer.exe, etc.

I've never dealt with creating installers but I'm not sure why you'd need
to do anything significantly different for Qt 5 than what you did for Qt 4
unless the installer technology has changed.

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

Re: [Interest] Missing glyphs using Qt 5(.3+?) on Macintosh

[Adam Light]

I guess nobody else has run into this, so I've created a bug report at
https://bugreports.qt-project.org/browse/QTBUG-40549.

Adam


On Thu, Jul 31, 2014 at 8:27 AM, Adam Light  wrote:

> I noticed today that when I build my application using Qt 5.4 from the dev
> branch and I try to display certain mathematical symbols (say, in a
> QPlainTextEdit), I get the empty square box glyph instead of the correct
> symbol glyph.
>
> When I build using Qt 4.8.6, I get the correct symbols displayed.
>
> I have only tested this on Mac OSX 10.9.4.
>
> An example of a character that does not display properly is ∯ (that's
> U+222F, SURFACE INTEGRAL). There are at least 20 other symbols with similar
> problems that I've noticed.
>
> I can reproduce this problem using a Qt creator snapshot I've downloaded
> recently:
>
> Based on Qt 5.3.1 (Clang 5.0 (Apple), 64 bit)
>
> Built on Jul 14 2014 at 04:12:53
>
> From revision c30856e657
>
>
> If you set the cursor in a text editor for a file or a line edit (eg. the
> Find line edit) and insert this symbol by pasting or by using the system
> Character Viewer application, Creator draws the empty box. I don't have an
> old version of Creator built with Qt 4 to test, but I assume the symbol
> would show up correctly in an older version.
>
>
> I've searched the bug reports for something similar and the closest issue
> I could find is https://bugreports.qt-project.org/browse/QTBUG-13206 but
> that report is very old and against Qt 4.6.
>
>
> Has anyone else come across this problem? I'm happy to file a new bug
> report but since it's hard for me to come up with good search terms for
> this I thought I'd see if anyone else is familiar with this problem before
> I do so.
>
>
> Thanks
>
> Adam
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Missing glyphs using Qt 5(.3+?) on Macintosh

[Adam Light]

I noticed today that when I build my application using Qt 5.4 from the dev
branch and I try to display certain mathematical symbols (say, in a
QPlainTextEdit), I get the empty square box glyph instead of the correct
symbol glyph.

When I build using Qt 4.8.6, I get the correct symbols displayed.

I have only tested this on Mac OSX 10.9.4.

An example of a character that does not display properly is ∯ (that's
U+222F, SURFACE INTEGRAL). There are at least 20 other symbols with similar
problems that I've noticed.

I can reproduce this problem using a Qt creator snapshot I've downloaded
recently:

Based on Qt 5.3.1 (Clang 5.0 (Apple), 64 bit)

Built on Jul 14 2014 at 04:12:53

>From revision c30856e657


If you set the cursor in a text editor for a file or a line edit (eg. the
Find line edit) and insert this symbol by pasting or by using the system
Character Viewer application, Creator draws the empty box. I don't have an
old version of Creator built with Qt 4 to test, but I assume the symbol
would show up correctly in an older version.


I've searched the bug reports for something similar and the closest issue I
could find is https://bugreports.qt-project.org/browse/QTBUG-13206 but that
report is very old and against Qt 4.6.


Has anyone else come across this problem? I'm happy to file a new bug
report but since it's hard for me to come up with good search terms for
this I thought I'd see if anyone else is familiar with this problem before
I do so.


Thanks

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

[Interest] Application build times using Qt4 vs Qt5

[Adam Light]

I've noticed that compiling my application takes considerably longer when
compiling using Qt5 vs. Qt 4. This is true on Macintosh 10.9 and Windows 7.
I'm comparing builds done using the same machine with the same application
source code.

For example,
Macintosh:
Qt 4.8.6: Elapsed time: 06:20
Qt 5.4-dev: Elapsed time: 08:51.

Windows:
Qt 4.8.6: Elapsed time: 04:51.
Qt 5.4-dev: Elapsed time: 10:23.

I've pasted the exact build steps that are executed in these cases at the
end of this message. These are times for a full rebuild after having
deleted the build directory and build product from before.

The Qt builds we're using are self built. I've also pasted the configure
command we use to build our Qt libraries at the end.

There are a few places in our code where we use something like:

#if QT_VERSION >= 0x05

...

#else

...

#endif

to compile different code depending on the Qt version, but these are all
minor differences. We are not yet using any Qt5 only features so I wouldn't
expect the small differences in our code to have much impact on compile
time.

Do others see similar increases of build time with Qt5 vs. Qt4, especially
on Windows? Does anyone have any suggestions to improve the build
performance when we build with Qt5?

Just to be clear, I'm not complaining of how long it takes to build the Qt
libraries, just how long it takes to build *our application* with different
versions of the Qt libraries.

Thanks
Adam


Here is the full information on the builds:
Using Creator 3.2.0-rc1 on Mac 10.9.4 (64-bit Debug builds):
Qt 4.8.6: Elapsed time: 06:20.
Build Steps:
qmake: qmake IgorPhoenix.pro -r -spec unsupported/macx-clang CONFIG+=x86_64
Make: make -r -w -j 16 in
/Users/aclight/Documents/IgorDev/IgorGit/IgorPhoenix-Qt4-64bit--build-debug
 Clean steps:
Make: make -r -w clean in
/Users/aclight/Documents/IgorDev/IgorGit/IgorPhoenix-Qt4-64bit--build-debug
 Qt 5.4-dev: Elapsed time: 08:51.
Build Steps:
qmake: qmake IgorPhoenix.pro -r -spec macx-clang CONFIG+=x86_64
Make: make -r -w -j 16 in
/Users/aclight/Documents/IgorDev/IgorGit/build-IgorPhoenix-Latest_Qt5_from_SVN_64_bit-Debug_Qt5_Debug
 Clean steps:
Make: make -j 16 -r -w clean in
/Users/aclight/Documents/IgorDev/IgorGit/build-IgorPhoenix-Latest_Qt5_from_SVN_64_bit-Debug_Qt5_Debug
Using Creator 3.2.0-rc1 on Windows 7 (64-bit Debug builds, using jom.exe
for make step):
Qt 4.8.6: Elapsed time: 04:51.
Build Steps:
qmake: qmake.exe IgorPhoenix.pro -r -spec
C:\qtbuild\qt\mkspecs\win32-msvc2013 DEFINES+=WINDOWS_USE_BASH
Make: jom.exe in
C:\IgorDev\IgorGit\build-IgorPhoenix-Qt4_from_SVN_64_bit-Debug
 Clean steps:
Make: jom.exe clean in
C:\IgorDev\IgorGit\build-IgorPhoenix-Qt4_from_SVN_64_bit-Debug
 Qt 5.4-dev: Elapsed time: 10:23.
Build Steps:
qmake: qmake.exe IgorPhoenix.pro -r -spec win32-msvc2013
DEFINES+=WINDOWS_USE_BASH
Make: jom.exe in
C:\IgorDev\IgorGit\build-IgorPhoenix-Qt5_from_SVN_64_bit-Debug
 Clean Steps:
Make: jom.exe clean in
C:\IgorDev\IgorGit\build-IgorPhoenix-Qt5_from_SVN_64_bit-Debug


To build our copies of the Qt libraries, we use the following configure
commands:

Macintosh:
Qt4: echo yes | MAKEFLAGS=-j16
QMAKESPEC=/qtbuild/qt/mkspecs/unsupported/macx-clang ../../qt/configure
-debug-and-release -opensource -no-qt3support -nomake examples -nomake
demos -nomake tests -silent -no-sql-mysql -no-webkit -cocoa -arch x86_64
-arch x86 -no-phonon -no-phonon-backend -prefix /qtbuild/install/macosx

Qt5: MAKEFLAGS=-j16 ../../qt/configure -confirm-license -debug-and-release
-opensource -gui -widgets -qpa cocoa -no-qml-debug -nomake examples -nomake
tests -silent -no-sql-mysql -platform macx-clang -no-c++11 -prefix
/qtbuild5/install/mac64

Windows:
Qt4: echo yes | c:\qtbuild\qt\configure.exe -debug-and-release -opensource
-no-qt3support -nomake examples -nomake demos -nomake tests -no-dsp
-no-webkit -mp -prefix C:\qtbuild\install\win64

Qt5: c:\qtbuild5\qt\configure -confirm-license -make-tool jom
-debug-and-release -opensource -gui -widgets -no-qml-debug -nomake examples
-nomake tests -no-sql-mysql -opengl desktop -mp -prefix
C:\qtbuild5\install\win64
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Update QComboBox items on opening the combo box

[Adam Light]

On Mon, Jun 30, 2014 at 2:36 AM, André Hartmann 
wrote:

> Hello all,
>
> I'd like to have a QComboBox with the available serial ports on my
> system. Populating the box at program start is easy, but I'd like to
> detect USB serial ports that are connected during run time.
>
> The only think I found is focusInEvent, but it seems my port list is
> updated twice, on opening the list and on closing it (Windows 7, Qt
> 4.8.2). Is there a better way to do?
>
> I'd really like to have something like QComboBox::onOpened().
> Borland C++ Builder had OnDropDown which for that purpose.
>
>
Check out the virtual method QComboBox::showPopup().

http://qt-project.org/doc/qt-4.8/qcombobox.html#showPopup

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

[Interest] QWindowsMime or replacement in Qt 5

[Adam Light]

Our application makes extensive use of QWindowsMime and QMacPasteboardMime
to allow us to handle various clipboard formats properly.

For Qt 5, the QtMacExtras module provides the necessary functionality that
was in Qt 4. But I still don't see anything equivalent in QtWinExtras.

Without QWindowsMime or the equivalent functionality, it won't be possible
to use Qt 5 with our application--not a situation we want to be in.

I've pasted below the last I've heard on this situation, from almost 2
years ago.

Thanks
Adam

On segunda-feira, 15 de outubro de 2012 12.15.07, Adam Light wrote:
> It looks like QWindowsMime is also missing from Qt 5. Are there any
> alternatives to these classes? I don't see any mention of them being
> deprecated.

They aren't deprecated, most of them.

The platform-specific classes are just missing from 5.0 due to the QPA
porting.
They will either come back inside a new platform-specific module
(MacSupport,
X11Support, etc.) or they will be deprecated for good if a cross-platform
API
can be provided.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Text not displaying correctly in some cases (Qt 5.3, Mac OSX)

[Adam Light]

It appears that what I reported is a consequence of
https://codereview.qt-project.org/#change,83189 and was also reported in
https://bugreports.qt-project.org/browse/QTBUG-38363.

The issue was fixed in 40b195d0f9ee7ef1b917a635bb073fa108b2ed40 and after
updating my Qt source and rebuilding I'm no longer seeing the problem in my
application.

Adam


On Tue, Apr 29, 2014 at 9:16 AM, Adam Light  wrote:

> Since updating my git checkout of Qt 5.3 a few days ago to the release
> branch (I was previously using the stable branch as of early April) and
> rebuilding Qt, I noticed that I sometimes get weird text drawing problems
> in my application on Mac OSX 10.9.2 but not Windows 7.
>
> If I compile my application with Qt 4.8.6, I don't see these problems on
> either platform.
>
> I have attached two examples of the same QPlainTextEdit subclass widget.
> In one, each character is drawn as a rectangle in the widget itself
> (though, oddly, the window's title is displayed correctly). In the other,
> the text is drawn normally.
>
> The only difference between the two is that the font size is a bit larger
> in the window with the text properly drawn.
>
>
>  [image: Inline image 2][image: Inline image 3]
>
> If I change the text size back to what it was originally, the text is
> drawn wrong again.
>
> Here are printouts of the QFont after I set it:
> Left example, text drawn incorrectly:
> void WMPlainTextEdit::zoomIn(const double) QFont(
> "Monaco,11,-1,5,50,0,0,0,0,0" ) pointSizeF: 11
>
> Right example, text drawn properly:
> void WMPlainTextEdit::zoomIn(const double) QFont(
> "Monaco,13.75,-1,5,50,0,0,0,0,0" ) pointSizeF: 13.75
>
> I see the same behavior if I try using different font families, and the
> particular size doesn't seem to matter. For some font families, I have
> found multiple font sizes that cause incorrect drawing, and some I have
> found only one but have not tried an exhaustive search.
>
> When my application starts, all text is drawn correctly in all places. I
> can reproducibly cause the text in most places to start drawing wrong by
> bringing up a specific dialog, but there are other ways that I can get the
> text to start drawing wrong as well. When the text starts drawing wrong in
> one place it will sometimes also draw wrong in other places (eg. contextual
> menus, dialogs, etc.) but sometimes draw right.
>
> I have looked through the Qt bug reports and don't see anything related to
> this. I also tried building a few of the example projects and can't get the
> text to draw incorrectly using an example. My coworkers also get this
> behavior, and we're all running OSX 10.9.2 and using the same Qt 5.3 build.
>
> I'd create a bug report but it'll probably be ignored since I can't
> provide much information on how to reproduce this. Has anyone else seen
> this kind of behavior or have any ideas where I should start to try to
> track down the problem?
>
> Thanks
> Adam
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Text not displaying correctly in some cases (Qt 5.3, Mac OSX)

[Adam Light]

Since updating my git checkout of Qt 5.3 a few days ago to the release
branch (I was previously using the stable branch as of early April) and
rebuilding Qt, I noticed that I sometimes get weird text drawing problems
in my application on Mac OSX 10.9.2 but not Windows 7.

If I compile my application with Qt 4.8.6, I don't see these problems on
either platform.

I have attached two examples of the same QPlainTextEdit subclass widget. In
one, each character is drawn as a rectangle in the widget itself (though,
oddly, the window's title is displayed correctly). In the other, the text
is drawn normally.

The only difference between the two is that the font size is a bit larger
in the window with the text properly drawn.


 [image: Inline image 2][image: Inline image 3]

If I change the text size back to what it was originally, the text is drawn
wrong again.

Here are printouts of the QFont after I set it:
Left example, text drawn incorrectly:
void WMPlainTextEdit::zoomIn(const double) QFont(
"Monaco,11,-1,5,50,0,0,0,0,0" ) pointSizeF: 11

Right example, text drawn properly:
void WMPlainTextEdit::zoomIn(const double) QFont(
"Monaco,13.75,-1,5,50,0,0,0,0,0" ) pointSizeF: 13.75

I see the same behavior if I try using different font families, and the
particular size doesn't seem to matter. For some font families, I have
found multiple font sizes that cause incorrect drawing, and some I have
found only one but have not tried an exhaustive search.

When my application starts, all text is drawn correctly in all places. I
can reproducibly cause the text in most places to start drawing wrong by
bringing up a specific dialog, but there are other ways that I can get the
text to start drawing wrong as well. When the text starts drawing wrong in
one place it will sometimes also draw wrong in other places (eg. contextual
menus, dialogs, etc.) but sometimes draw right.

I have looked through the Qt bug reports and don't see anything related to
this. I also tried building a few of the example projects and can't get the
text to draw incorrectly using an example. My coworkers also get this
behavior, and we're all running OSX 10.9.2 and using the same Qt 5.3 build.

I'd create a bug report but it'll probably be ignored since I can't provide
much information on how to reproduce this. Has anyone else seen this kind
of behavior or have any ideas where I should start to try to track down the
problem?

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

[Interest] Qt 4 roadmap

[Adam Light]

My company is currently working on a major rewrite of our application using
Qt. We started the rewrite about 3 years ago and we are currently using Qt
4.8.5. We have done some testing using Qt 5.2 but we have found (and
reported) a number of bugs and regressions, especially on Macintosh
(though, to be fair, some bugs that affect us in Qt 4.8 are not present in
5.2).

Our program runs on Windows and Macintosh. If all goes well, we will
release the final application within a year from now.

We typically release a new major version of the application approximately
every 3 years.

We are trying to decide when, and if, we should switch to Qt 5. I've looked
online for a Qt 4 roadmap that extends into the future but haven't found
anything. Is one available? For long can we reasonably expect Qt4 updates
to continue? We are using the LGPL licensed version of Qt and we don't have
commercial support from Digia.

Thanks for any information
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Compiling 32- and 64-bit versions of Qt 5 on Macintosh

[Adam Light]

When compiling the Qt 4 libraries using Macintosh 10.6.8, I could pass
the"-arch x86_64 -arch x86" flags to configure and the compiled Qt
libraries would contain both 32- and 64-bit versions.

When compiling Qt 5.2 on the same system, if I use the -arch flag with
configure I'm informed that "Qt now detects the target and host
architectures based on compiler
output. Qt will be built using x86_64 for the target architecture
and x86_64 for the host architecture (note that these two
will be the same unless you are cross-compiling)."

Though I have not yet tried it, I think I could pass "-platform
macx-g++-32" to get a 32-bit build, and "-platform macx-g++" to get a
64-bit build (the default). But then I'd have two separate sets of binaries
that I'd need to lipo everything together.

Is there a better approach that I'm missing? If not, has anyone else done
this?

We need a 32 bit version of our application because users can (optionally)
use external libraries from the program. We have never had a 64-bit version
on Macintosh, so all existing libraries that users might want to use are
32-bit. Most of the users of these libraries do not have access to the
source code to rebuild, and in some cases the source code is probably lost.
But we'd like our users to continue to be able to use their 32-bit versions
of the libraries so we need a 32-bit version of our app and the Qt
libraries.

Thanks for any help
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Compilation of Qt 5.2 winextras fails on Windows

[Adam Light]

Jürgen:

On Mon, Jan 6, 2014 at 10:13 AM, Jürgen Hunold  wrote:

>
> Yes, this seems to be broken. The attached patch comments out the broken
> code
> and shows where to look closer.
> Please file a bug report.
>
>
Thanks. I've filed a bug report at
https://bugreports.qt-project.org/browse/QTBUG-35980.

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

[Interest] Compilation of Qt 5.2 winextras fails on Windows

[Adam Light]

Hi

I am trying to build my own version of Qt 5.2 from a Git checkout, but I'm
getting compiler errors in the winextras module.

I followed the instructions in the"Getting the source code" topic at
http://qt-project.org/wiki/Building-Qt-5-from-Git.

I'm using Windows 7 64-bit with the VS2008SP1 compiler and with the Windows
7 SDK installed. I have previously successfully built Qt 5.1-beta1 using
this same configuration.

I am using the following configuration command executed from a Visual
Studio command prompt:
c:\qt5test\qt5>configure -confirm-license -debug-and-release -opensource
-gui -widgets  -no-qml-debug -nomake examples -nomake tests -no-sql-mysql
-opengl desktop -make-tool jom

When I execute "jom", and wait for quite a while, I eventually get these
error messages:
cl -c -nologo -Zm200 -Zc:wchar_t -Zi -MDd -MP -GR -W3 -w34100 -w34189 -D
UNICODE -DWIN32 -DQT_BUILD_WINEXTRAS_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED _WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -D_USE_MATH_DEFINES -DNTDDI_VE
RSION=0x0601 -D_WIN32_WINNT=0x0601 -DQT_NO_EXCEPTIONS -DQT_GUI_LIB
-DQT_CORE _LIB -I"C:\qt5test\qt5\qtbase\include"
-I"C:\qt5test\qt5\qtbase\include\QtWinExt ras"
-I"C:\qt5test\qt5\qtbase\include\QtWinExtras\5.2.0" -I"C:\qt5test\qt5\qtbas
e\include\QtWinExtras\5.2.0\QtWinExtras" -I"tmp"
-I"C:\qt5test\qt5\qtbase\includ e\QtGui"
-I"C:\qt5test\qt5\qtbase\include\QtCore" -I".moc\debug" -I"C:\qt5test\q
t5\qtbase\mkspecs\win32-msvc2008" -Fo.obj\debug\
@C:\Users\aclight\AppData\Local
\Temp\moc_qwintaskbarprogress.obj.6880.1934.jom moc_qwintaskbarprogress.cpp
qwinthumbnailtoolbar.cpp(257) : error C2664:
'ITaskbarList3::ThumbBarAddButtons'  : cannot convert parameter 3 from
'THUMBBUTTON [7]' to 'THUMBBUTTON' No constructor could take the
source type, or constructor overload resol ution was ambiguous
qwinthumbnailtoolbar.cpp(322) : error C2065: 'THBN_CLICKED' : undeclared
identif ier
qwinthumbnailtoolbar.cpp(347) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(349) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(351) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(353) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(355) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(357) : error C2676: binary '|=' :
'THUMBBUTTONFLAGS' do es not define this operator or a conversion to a type
acceptable to the predefin ed operator
qwinthumbnailtoolbar.cpp(364) : error C2676: binary '|=' :
'THUMBBUTTONMASK' doe s not define this operator or a conversion to a type
acceptable to the predefine d operator
qwinthumbnailtoolbar.cpp(366) : error C2676: binary '|=' :
'THUMBBUTTONMASK' doe s not define this operator or a conversion to a type
acceptable to the predefine d operator
qwinthumbnailtoolbar.cpp(368) : error C2676: binary '|=' :
'THUMBBUTTONMASK' doe s not define this operator or a conversion to a type
acceptable to the predefine d operator
jom: C:\qt5test\qt5\qtwinextras\src\winextras\Makefile.Debug
[.obj\debug\qwinthu mbnailtoolbar.obj] Error 2
jom: C:\qt5test\qt5\qtwinextras\src\winextras\Makefile.Debug
[.obj\debug\qwinjum plistcategory.obj] Error 2
jom: C:\qt5test\qt5\qtwinextras\src\winextras\Makefile [debug-all] Error 2
jom: C:\qt5test\qt5\qtwinextras\src\Makefile
[sub-winextras-make_first-ordered] Error 2
jom: C:\qt5test\qt5\qtwinextras\Makefile [sub-src-make_first] Error 2
jom: C:\qt5test\qt5\Makefile [module-qtwinextras-make_first] Error 2

If I re-run configure and add the "-skip winextras" parameters, and then
run jom again, I am able to build successfully.

The combination of Windows 7 and MSVC 2008 is not listed as supported at
http://qt-project.org/doc/qt-5/supported-platforms.html. Has anyone else
run into this problem?

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

Re: [Interest] Display nicely truncated text in a QLabel

[Adam Light]

On Fri, Jul 12, 2013 at 2:06 AM,  wrote:

> Hi
>
> I would derive from QLabel, get the length of it (in pixel) with
> frameWidth() use QFontMetrics QWidget::fontMetrics () with int
> QFontMetrics::width ( const QString & text, int len = -1 ) to get the
> length of the text in pixels, check if it fits, and if no cut some chars
> and replace it with … until it fits. You would have to check every time
> again when the user changes the windows size..
>
> Maybe someone else knows a nicer way.
>

There are potential complications with this approach depending on what
textInteractionFlags are set on the label. For example, in my application
we sometimes display paths to a file on disk, and we use
the Qt::TextSelectableByMouse flag so that the user can select that text
and copy it into another application, if they wish. Though I haven't tried
this, I suspect that if you used Lucas's approach of eliding the text then
you would only be able to select the elided text, not the original text. I
think you'd have similar problems if the label's text contained a link.

In my application, we work around this by using a QLineEdit set to be read
only with no frame and a transparent background. The user can then use the
mouse or keyboard cursors to move the cursor position in the line edit so
that they can see the beginning or end of the text that would otherwise be
hidden.

This work around isn't great, but it at least makes it possible for the
user to see the full value of the string in cases where it wouldn't
otherwise be possible.

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

[Interest] Where do I submit bugs for qtmacextras

[Adam Light]

I can't figure out where the correct place is to submit bugs for the
qtmacextras project. I don't see it as a Project option in JIRA nor as a
component of the Qt project. It doesn't look like it's in the playground
any more so I don't think it belongs in the Qt Playground Projects
"project".

For what it's worth, my bug report is that I am unable to compile the
qtmacextras library (using the qtmacextras.pro file in the root directory)
using OSX 10.6.8.

I had to make simple changes to the order of #import statements so that the
Cocoa headers are imported before other #include statements. I also had to
remove the #import of CoreGraphics in qmacfunctions.mm. I've pasted the
diff at the end.

Thanks
Adam

diff --git a/src/macextras/qmacfunctions.mm b/src/macextras/qmacfunctions.mm
index ba0e940..cb00169 100644
--- a/src/macextras/qmacfunctions.mm
+++ b/src/macextras/qmacfunctions.mm
@@ -45,7 +45,9 @@
 #include 
 #include 
 #import 
-#import 
+#ifdef Q_OS_IOS
+ #import 
+#endif

 QT_BEGIN_NAMESPACE

diff --git a/src/macextras/qmacfunctions_mac.mm b/src/macextras/
qmacfunctions_mac.mm
index a78792a..784bad4 100644
--- a/src/macextras/qmacfunctions_mac.mm
+++ b/src/macextras/qmacfunctions_mac.mm
@@ -39,9 +39,9 @@
 **
 /

+#import 
 #include "qmacfunctions.h"
 #include "qmacfunctions_p.h"
-#import 

 QT_BEGIN_NAMESPACE

diff --git a/src/macextras/qmacnativetoolbar.mm b/src/macextras/
qmacnativetoolbar.mm
index 659362b..8caddc2 100644
--- a/src/macextras/qmacnativetoolbar.mm
+++ b/src/macextras/qmacnativetoolbar.mm
@@ -39,6 +39,7 @@
 **
 /

+#import 
 #include "qmacfunctions.h"
 #include "qmacnativetoolbar.h"
 #include "qmactoolbardelegate.h"
@@ -58,7 +59,6 @@
 #include 
 #endif

-#import 

 // from the Apple NSToolbar documentation
 #define kNSToolbarIconSizeSmall 24
diff --git a/src/macextras/qmacnativewidget.mm b/src/macextras/
qmacnativewidget.mm
index b9963ab..305de86 100644
--- a/src/macextras/qmacnativewidget.mm
+++ b/src/macextras/qmacnativewidget.mm
@@ -39,6 +39,7 @@
 **
 /

+#import 
 #include "qmacnativewidget.h"
 #if QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)
 #include 
@@ -47,7 +48,6 @@
 #endif
 #include 

-#import 

 /*!
 \class QMacNativeWidget
diff --git a/src/macextras/qmacpasteboardmime.mm b/src/macextras/
qmacpasteboardmime.mm
index 777e514..1ad437a 100644
--- a/src/macextras/qmacpasteboardmime.mm
+++ b/src/macextras/qmacpasteboardmime.mm
@@ -39,12 +39,12 @@
 **
 /

+#include 
 #include "qmacpasteboardmime.h"
 #include 
 #include 
 #include 

-#include 

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

Re: [Interest] Upgrade to Qt 5 -- pros and cons?

[Adam Light]

On Thu, Mar 21, 2013 at 1:41 PM, K. Frank  wrote:

> Hello List!
>
> What would be the pros and cons of upgrading from Qt 4 to Qt 5?  In
> particular, are there any good reasons not to do so?
>

My company is in the process of porting our large and complicated desktop
application, which currently supports Mac and Windows, to Qt. We are
currently targeting Qt 4.8, but I have run a few tests in the past month or
two using various builds of Qt 5. So far I have only tested on OSX but I've
found about 5 bugs in Qt 5 that are (for our application) critical and
would prevent us from using Qt 5 even for basic testing. I've reported all
bugs I've found in the Qt bug tracker but it looks like most of the bugs
have not been fixed, even though some were given high priority.
Unfortunately, we don't currently have the manpower or knowledge to
investigate these bugs ourselves and try to fix them.

As others have said, doing the actual port was pretty simple, and after
having done so it's not difficult to continue to use Qt 4.8 with the
application while still being able to compile against Qt 5 for testing
purposes.

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

[Interest] QMatrix4x4 in Qt 5

[Adam Light]

According to http://qt-project.org/doc/qt-5.0/qtgui/qmatrix4x4-compat.html,
the QMatrix4x4 class (as well as QMatrix) is deprecated in Qt 5. Is there a
suggested replacement?

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

Re: [Interest] Qt 5 on Mac OS X

[Adam Light]

Morten:

On Thu, Dec 20, 2012 at 4:09 AM, Sorvig Morten wrote:

> Hi,
>
> Qt 5 aims to be 98% source compatible with Qt 4. Still, changes has been
> made to the platform implementation and infrastructure. Not all have been
> discussed here, so I figured I'd give a brief rundown.
>
> The main issue that everyone should be aware of is that all Qt 5 platform
> ports are to a large degree rewrites. This means new code. If you find
> something that is missing it is far more likely that we simply forgot about
> it rather than it being a part some twisted scheme to break your
> application.
>
> Now, on the changes where we actually _are_ breaking your application:
>

Thanks for the summary of the changes.

I think you left one major one (for us at least) out of your list: the
elimination of the QMacPasteboardMime class (the equivalent QWindowsMime
class on Windows is also gone).

Thiago has previously mentioned on this list that a replacement for
QMacPasteboardMime
is/may be planned for Qt 5.1, but I assume that is a long way off. Is there
any plan to provide an equivalent in QtMacExtras sooner?

FWIW, we use these classes to support clipboard formats that Qt doesn't
natively support and to override handling of some image formats that Qt
does support but which it does not fully support (eg. TIFF images
containing floating point data or 16 bit integer data).

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

Re: [Interest] How to #include using Qt 5

[Adam Light]

On Mon, Oct 15, 2012 at 12:00 PM, Thiago Macieira  wrote:

> On segunda-feira, 15 de outubro de 2012 11.35.52, Adam Light wrote:
> > I have made my own build of Qt5 and passed the following flags (among
> > others) to configure:
> > -gui -widgets -qpa cocoa
> >
> > I have a few source files in my application that use the following
> #include:
> > #include 
> >
> > These files compile without any problems when I use Qt 4.8.3. However,
> when
> > I try to compile using Qt 5, I get the following compile error:
> > QMacPasteboardMime: No such file or directory
>
> That class is currently missing in Qt 5.
>
> It will reappear in a later version of Qt 5 in a module specific for Mac
> support.
>

It looks like QWindowsMime is also missing from Qt 5. Are there any
alternatives to these classes? I don't see any mention of them being
deprecated.

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

[Interest] How to #include using Qt 5

[Adam Light]

I have made my own build of Qt5 and passed the following flags (among
others) to configure:
-gui -widgets -qpa cocoa

I have a few source files in my application that use the following #include:
#include 

These files compile without any problems when I use Qt 4.8.3. However, when
I try to compile using Qt 5, I get the following compile error:
QMacPasteboardMime: No such file or directory


There are also lots of other errors that stem from the fact that the header
file can't be found.

My application's .pro file contains the following:
# Allow project to compile using Qt 5.

greaterThan(QT_MAJOR_VERSION, 4) {
  QT += widgets
  QT += gui
}

I don't see anything else mentioned at
http://qt-project.org/wiki/Transition_from_Qt_4.x_to_Qt5 that would be
relevant to my situation.

I understand that QMacPasteboardMime is part of the Cocoa QPA plugin in Qt
5 but it's not clear to me whether I need to add something to my .pro file
to use the plugin or whether I need to add a prefix path to the include
statement.

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

[Interest] Distributing custom qt build to a group of developers

[Adam Light]

My company currently has a Subversion repository for Qt that looks like
this:
/qtbuild
  /qt
  /build
/macosx
  /install
/macosx
/win32
/win64

The /qt directory contains a git checkout of qt.
The /install subdirectories contain the compiled frameworks/dlls for both a
debug and release build of qt.
The /build/macosx directory contains all of the object files generated when
compiling. These seem to be required to be able to step into qt code using
gdb.

When a new version of Qt is released, I checkout that tag in the /qt
directory and then rebuild Qt using certain configuration settings. I then
commit all changes (the new frameworks/dlls, object files, etc.) to the
Subversion repository. Other developers at my company can then update their
Subversion checkouts so they have the new version of Qt.

This works pretty well except that it requires checking a lot of binary
files into Subversion, and both committing the files and checking them out
is very slow. The size of the working copy is also extremely large (this
can be addressed partly by using Subversion's sparse checkout feature). The
repository on the server is also quite large.

We use this process in part because some developers use not-so-powerful
machines (and/or Windows virtual machines) on which compiling Qt can take
multiple hours. Furthermore, as long as everyone runs svn update when I
build a new version of Qt, we know that we are all using the same version
and libraries.

But I wonder whether there is a better way to handle this. How do other
groups handle this? Using the binaries and/or SDK available for download is
not an option for us because we need different configuration options and we
sometimes need to patch Qt's source to fix bugs that have not bee fixed in
Qt's git repository.

Thanks for any ideas.

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

Re: [Interest] Subclassing QMacPasteboardMime

[Adam Light]

In case anyone else encounters this, I've filed a bug report on this issue
at https://bugreports.qt-project.org/browse/QTBUG-25951

On Thu, May 24, 2012 at 1:52 PM, Adam Light  wrote:

> In my application, I wish to handle tiff clipboard data (of UTI type
> public.tiff) different than the implementation in QMacPasteboardMimeTiff (I
> don't want the data to pass through a QImage).
>
> I have written my own subclass of QMacPasteboardMime that does exactly
> what I want, and it works correctly.
>
> The documentation of QMacPasteboardMime (http://qt-project.org/doc/qt-4.8/
> qmacpasteboardmime.html) states:
> "When working with MIME data, Qt will interate through all instances of
> QMacPasteboardMime to find an instance that can convert to, or from, a
> specific MIME type. It will do this by calling canConvert() on each
> instance, starting with (and choosing) the last created instance first. The
> actual conversions will be done by using convertToMime()
> and convertFromMime()."
>
> I am instantiating my subclass of QMacPasteboardMime (call it
> MyMacPasteboardMimeTiff) after my application's QApplication object is
> created (the base QMacPasteboardMime class is created in the QApplication
> initialization code).
>
> My problem is that my MyMacPasteboardMimeTiff::mimeFor(), canConvert(),
> etc. methods never get called. This is because 
> QMacPasteboardMime::flavorToMime(),
> which gets called when QMimeData::formats() is called, uses this code:
>
> QString QMacPasteboardMime::flavorToMime(uchar t, QString flav)
>
> {
>
> MimeList *mimes = globalMimeList();
>
> for(MimeList::const_iterator it = mimes->constBegin(); it != 
> mimes->constEnd(); ++it) {
>
> #ifdef DEBUG_MIME_MAPS
>
> qDebug("QMacMIme::flavorToMime: attempting %s (%d) for flavor 
> %d[%c%c%c%c] [%s]",
>
>(*it)->convertorName().toLatin1().constData(),
>
>(*it)->type & t, flav, (flav >> 24) & 0xFF, (flav >> 16) & 
> 0xFF, (flav >> 8) & 0xFF, (flav) & 0xFF,
>
>(*it)->mimeFor(flav).toLatin1().constData());
>
>
> #endif
>
> if((*it)->type & t) {
>
> QString mimeType = (*it)->mimeFor(flav);
>
> if(!mimeType.isNull())
>
> return mimeType;
>
> }
>
> }
>
> return QString();
>
> }
>
>
> So contrary to what the documentation
> states/implies, QMacPasteboardMimeTiff::mimeFor() ends up getting called
> before MyMacPasteboardMimeTiff::mimeFor() gets called.
> Since QMacPasteboardMimeTiff supports the public.tiff UTI, it ends up being
> used to do the conversion from the clipboard's data to MIME data.
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Subclassing QMacPasteboardMime

[Adam Light]

Hi

This question applies to Mac OSX. I'm using Qt 4.8.1 on Mac OS 10.6.8.

In my application, I wish to handle tiff clipboard data (of UTI type
public.tiff) different than the implementation in QMacPasteboardMimeTiff (I
don't want the data to pass through a QImage).

I have written my own subclass of QMacPasteboardMime that does exactly what
I want, and it works correctly.

The documentation of QMacPasteboardMime (
http://qt-project.org/doc/qt-4.8/qmacpasteboardmime.html) states:
"When working with MIME data, Qt will interate through all instances of
QMacPasteboardMime to find an instance that can convert to, or from, a
specific MIME type. It will do this by calling canConvert() on each
instance, starting with (and choosing) the last created instance first. The
actual conversions will be done by using convertToMime()
and convertFromMime()."

I am instantiating my subclass of QMacPasteboardMime (call it
MyMacPasteboardMimeTiff) after my application's QApplication object is
created (the base QMacPasteboardMime class is created in the QApplication
initialization code).

My problem is that my MyMacPasteboardMimeTiff::mimeFor(), canConvert(),
etc. methods never get called. This is
because QMacPasteboardMime::flavorToMime(), which gets called when
QMimeData::formats() is called, uses this code:

QString QMacPasteboardMime::flavorToMime(uchar t, QString flav)

{

MimeList *mimes = globalMimeList();

for(MimeList::const_iterator it = mimes->constBegin(); it !=
mimes->constEnd(); ++it) {

#ifdef DEBUG_MIME_MAPS

qDebug("QMacMIme::flavorToMime: attempting %s (%d) for flavor
%d[%c%c%c%c] [%s]",

   (*it)->convertorName().toLatin1().constData(),

   (*it)->type & t, flav, (flav >> 24) & 0xFF, (flav >>
16) & 0xFF, (flav >> 8) & 0xFF, (flav) & 0xFF,

   (*it)->mimeFor(flav).toLatin1().constData());


#endif

if((*it)->type & t) {

QString mimeType = (*it)->mimeFor(flav);

if(!mimeType.isNull())

return mimeType;

}

}

return QString();

}


So contrary to what the documentation
states/implies, QMacPasteboardMimeTiff::mimeFor() ends up getting called
before MyMacPasteboardMimeTiff::mimeFor() gets called.
Since QMacPasteboardMimeTiff supports the public.tiff UTI, it ends up being
used to do the conversion from the clipboard's data to MIME data.

If I instantiate my MyMacPasteboardMimeTiff class before the QApplication
object is initialized, then my class gets called to do conversion of
public.tiff data on the clipboard (that's how I know that my class works).
However, if any QMacPasteboardMime subclasses are instantiated
before QMacPasteboardMime::initialize() is called, none of Qt's
QMacPasteboardMime subclasses will get instantiated (though I might be able
to instantiate them all on my own, but that is a hack and even then the
cleanup_mimes function wouldn't get called to clean them all up).

Am I missing something? It really seems to me that
QMacPasteboardMime::flavorToMime() should be iterating in reverse, not
forward, as the documentation suggests. But I suspect that "fixing" that
behavior could break the behavior of working applications so won't happen.

Thanks for any help
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QAbstractItemModel and lazy loading

[Adam Light]

Jason:

On Fri, May 11, 2012 at 12:15 PM, Jason Dictos wrote:

> What I’ve done to work around this is to always have a dummy item called
> “Loading…” as the first item in the list. Then when that node expands, load
> and replace it. That has turned out to be a pretty good user experience as
> well.
>
>
>
 Thanks, that's a good idea that I hadn't thought of.

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