[Interest] WebGPU integration in Qt 6.x?

[Michael Jackson]

We are currently developing a desktop widgets based application that uses
VTK as our 3D rendering backend (could not use GPL so that rules out Qt
Data Visualization). VTK still relies on OpenGL but apparently is moving
towards WebGPU as their backend. I’ve done some looking on Google and
cannot quite find if WebGPU is coming to Qt anytime soon (few years in the
future kind of thing). I found New graphics integration in Qt WebEngine 6.6
and even 6.5

that
suggests new graphics backends for QML but maybe not desktop widgets. Could
anyone from Qt comment on WebGPU and its possible integration with a future
version of Qt 6?

Thank You.
--
Mike Jackson
BlueQuartz Software
www.bluequartz.net
www.dream3d.io
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] App release

[Michael Jackson]

For the "Installer" we just package up everything into a standalone package
and zip it up. No installer necessary. Not sure of the downsides but seems
easier for our users to just right-click and expand the archive and run.
—
Mike Jackson


On Wed, Mar 20, 2024 at 8:44 PM Thiago Macieira 
wrote:

> On Wednesday, 20 March 2024 17:27:26 PDT Turtle Creek Software wrote:
> > We are ready to release a free alpha version of our accounting app for
> Mac
> > & Windows. The plan is to use LGPL while still in beta, then switch to a
> > commercial license and static Qt when it's ready to sell.
> >
> > Will the switch cause licensing problems?
>
> The LGPL will not cause you legal problems. But you must remember that the
> licence you gave to those recipients is irrevocable: they can continue
> using
> it, distributing it and even developing it after you've made your
> production
> release. You may want to think more about your business case here, because
> some potential paying customers may decide they don't want to pay you if a
> nearly as good version is open source.
>
> You should also check with Qt Company sales what terms they'll sell you a
> licence under. In the past, they usually required that you retroactively
> buy
> for the time you spent developing the application.
>
> > How do people usually distribute QT for dynamic linking?  Our
> users/testers
> > are not very tech savvy.
>
> For Mac, it's easy:  use macdeployqt and everything is inside your
> application's bundle.
>
> For Windows, you'll need to make an installer to deploy your .exe and all
> the
> Qt libraries and plugins. windeployqt can prepare the installation target,
> but
> the installer itself is up to you. You can use the Qt Installer Framework
> if
> you wish, or something else.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Principal Engineer - Intel DCAI Cloud Engineering
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Packaging Qt6 application using conda-build

[Michael Jackson]

 https://bugreports.qt.io/browse/QTBUG-120487


--
Mike Jackson


On Dec 26, 2023 at 9:29:52 AM, Michael Jackson 
wrote:

> Not really sure if this is good place to ask but I'll try anyways.
>
> I am trying to package up our Qt6 based application using conda-build. The
> issue that I think I am running into is this warning message during the
> conda-build process.
>
> ```
>
> WARNING: The install/build script(s) for simplnx deleted the following files 
> (from dependencies) from the prefix:
> ['bin/Linguist6', 'bin/Assistant6', 'bin/qdbusviewer6', 'bin/pixeltool6', 
> 'bin/Designer6']This will cause the post-link checks to mis-report. Please 
> try not to delete and files (DSOs in particular) from the prefix
> ```
>
> and later on I then get this "test" failure.
>
> I have looked through “conda” trying to find out how to put those
> dependencies in but at the moment I can’t even find a conda package that
> would install QtDesigner, QtAssistant and the other “missing” libraries.
> This is on macOS (intel and silicon variants). It seems to be happy on
> Windows.
>
> I’ve tried all sorts of versions of conda, conda-build, mamba, boa,
> conda-build. Different versions of Qt6 (6.5.x and 6.6).
>
> I’m not sure if this is a bug somewhere, user error on my part or how to
> fix this issue. The repo is at GitHub - BlueQuartzSoftware/simplnx: The
> backend algorithms and framework associated with DREAM3DNX, a data analysis
> program for materials science data analytics
> <https://www.github.com/bluequartzsoftware/simplnx> and the recipe
> directory is in the top level “conda” directory.
>
> Thanks to anyone who might be able to shed some light on what I am
> probably doing wrong.
>
> --
> Mike Jackson
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Packaging Qt6 application using conda-build

[Michael Jackson]

Not really sure if this is good place to ask but I'll try anyways.

I am trying to package up our Qt6 based application using conda-build. The
issue that I think I am running into is this warning message during the
conda-build process.

```

WARNING: The install/build script(s) for simplnx deleted the following
files (from dependencies) from the prefix:
['bin/Linguist6', 'bin/Assistant6', 'bin/qdbusviewer6',
'bin/pixeltool6', 'bin/Designer6']This will cause the post-link checks
to mis-report. Please try not to delete and files (DSOs in particular)
from the prefix
```

and later on I then get this "test" failure.

I have looked through “conda” trying to find out how to put those
dependencies in but at the moment I can’t even find a conda package that
would install QtDesigner, QtAssistant and the other “missing” libraries.
This is on macOS (intel and silicon variants). It seems to be happy on
Windows.

I’ve tried all sorts of versions of conda, conda-build, mamba, boa,
conda-build. Different versions of Qt6 (6.5.x and 6.6).

I’m not sure if this is a bug somewhere, user error on my part or how to
fix this issue. The repo is at GitHub - BlueQuartzSoftware/simplnx: The
backend algorithms and framework associated with DREAM3DNX, a data analysis
program for materials science data analytics
 and the recipe
directory is in the top level “conda” directory.

Thanks to anyone who might be able to shed some light on what I am probably
doing wrong.

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

Re: [Interest] QGraphicsView and OpenGL in Qt6

[Michael Jackson]

On Dec 4, 2023 at 9:55:26 AM, Volker Hilsheimer via Interest <
interest@qt-project.org> wrote:

> On 30 Nov 2023, at 12:16, Filippo Rusconi via Interest <
> interest@qt-project.org> wrote:
>
> > I know things change but after that little exercise I am not sure anyone
>
> > would ever convince me to try QML on the desktop again. Period. If
> QWidgets
>
> > goes away we would probably just move to another language all together
>
> > rather than try QML. QML on Phones and tablets? Sure. Go for it. Desktop,
>
> > stay away. Far Far away.
>
>
> +1000
>
>
> It is some time now that I feel like Qt going the Qml route in a preferred
>
> manner with respect to the QWidget route (more revenues, I guess). I hope
> I am
>
> wrong with this feeling. I would be terribly sorry to have to adopt a new
>
> library set for widgetry…
>
>
>
>
> First of all: yes, we know that there is still a bit of a way to go before
> Qt Quick can support everything we want to be able to do on the desktop.
> What was broken or missing a few years ago might be available, or work
> better, today.
>
> But QML vs C++ and Qt Quick vs Qt Widgets is not at all about revenue,
> it’s about technology.
>
> QML is a better language for building UIs than C++.
> And the modular, scene-graph based and hardware accelerated rendering
> architecture of Qt Quick is a better architecture than the comparatively
> monolithic, CPU-bound approach of Qt Widgets.
>
> Of course, you might disagree with those statements. But if those two
> statements are true for mobile and embedded, then they are - in principle -
> also true for the desktop. Again, we know there’s work to be done to
> improve desktop-specific use cases.
>
> So yes, our focus is on making Qt Quick better, and new UI solutions will
> be designed primarily for Qt Quick. But our focus is also on the
> technologies that allow mixing the two, so that you don’t have to pick one
> or the other. You can keep your widget code and add Qt Quick via
> QQuickWidget to it already today.
>
> Volker
>
>
>
Again, my experience is with QML under Qt 5.15 at the time my company had
it’s disastrous try at QML. Qt 6.2 was out at the time I think but we had
to stick with 5.15.x due to requirements from our client. But even *if* we
would have been allowed to use Qt6, QML simply lacked the needed widgets
and ease of customization that we required on the desktop. The main issue
was the lack of QTreeView. Since QML was targeted at mobile screens, the
lack of a workable TreeView is understandable as that isn’t how
hierarchical information is navigated on a mobile device, but on desktop,
it is the norm and specifically was needed by our project in order to move
“data” between nodes in the tree. There was a QML QTreeView that was
commercially available which didn’t work with our licensing so we were
stuck. We spect a large sum of funding from the contract just trying to get
a workable QTreeView. The other major tipping point, ironically enough, was
the ability to easily style the application. We would spend hours and hours
just trying to get simple ui bits styled. We had a professional UX group
help design and come up with the needed CSS but it just didn’t work at the
end of the day.

You can say that one language is better than another all you want, but if
that language is simply missing features that are needed then nothing else
really matters. If the debugging experience is not as good as the other
language, it doesn’t matter. If I am locked into a specific development
environment which objectively is not as good as others out there, then the
language isn’t good enough.

At some point in the future, QML will surpass QWidgets in all those areas.
In my opinion, that time still has not arrived for desktop apps that need
certain kinds of widgets. For the simple basic “hello world” trivial app
demos that come with Qt, everything looks really nice. It is when you
actually try to create something more complicated is where the entire
development ecosystem falls apart with QML. I wanted to like it. I wanted
it to work. I could see the potential in QML to make slick “modern” apps
but potential is just that. Potential. Potential doesn’t pay my employee’s
salaries. I can’t go to clients and say what we delivered has “potential”.
I need something I can deliver *today*.

Just my 2 cents.

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

Re: [Interest] QGraphicsView and OpenGL in Qt6

[Michael Jackson]

 
I’d like to chime in with a real world application that we have been
developing. It has a VTK based 3D rendering engine inside a Qt application
that is widget based. It did not start out great. We burnt 10 months with
3~4 engineers trying to develop this application as a QML desktop
application and it was just one thing after another in QML that just would
stop us in our tracks. QML on Desktop just isn’t as mature as Widgets on
the Desktop and suggesting for someone to rewrite a generally well working
desktop application to QML is not just a huge disservice but would be a
huge mistake. We ended up taking the last 2 months of the contract and spun
up a widgets based application and got more features completed for the
client in those 2 months than we did with 10 months of QML development. I
know things change but after that little exercise I am not sure anyone
would ever convince me to try QML on the desktop again. Period. If QWidgets
goes away we would probably just move to another language all together
rather than try QML. QML on Phones and tablets? Sure. Go for it. Desktop,
stay away. Far Far away.


And ironically enough, our application will also be trying to render large
tiled mosaics through VTK. Our tiled images are 2K x 2K each and our data
sets are upwards of 500 to 700 tiles at this point. The QTable idea sounds
interesting. I would have to research how to render the table inside an
OpenGL scene.


--
Mike Jacksonmike.jack...@bluequartz.net
BlueQuartz Software www.bluequartz.net

On Nov 23, 2023 at 9:38:35 AM, Shawn Rutledge via Interest <
interest@qt-project.org> wrote:

>
> On 23 Nov 2023, at 02:37, Calogero Mauceri  wrote:
>
> Hi all,
>
> We finally decided to port our Qt5 based application to Qt6.
> It is a pretty complex application. The main view is a QGraphicsView with
> multiple items: images, paths, possible animations and so on.
>
> I remember in Qt5 OpenGL rendering was experimental with lots of issues.
> My question is, is QGraphicsView OpenGL rendering more stable in the Qt6
> era? or even better, is it suggested to render using OpenGL? (note: it is a
> cross platform application that should run on Windows, Mac or Linux
> machines).
>
> To be more specific. The QGraphicsView shows a map. The map is made up of
> multiple tiles that should align perfectly. Each tile is a
> QGraphicsPixmapItem. After porting to Qt6, it sometimes happens that when
> applying a scale to the tiles, then there are gaps between them. It does
> not always happen, but it can.
> I'm pretty sure the QGraphicsPixmapItems are properly scaled and
> positioned. It was working as expected in Qt5.
>
>
> Depending on how much you want to invest in porting, maybe it’s time to
> check whether you can use Qt Quick now?
>
> I have also wondered if we need explicit support for large tiled images.
> We need tiles in Qt Location for example, but in that case it’s already
> conventional to download pre-rendered fixed-size tiles, so that’s what we
> do; and the implementation is a C++ one-off, not depending on any reusable
> tiling implementation, since we don’t have one yet.  I also wondered how
> many people will want to use QtPDF to render very large pages
> (architectural drawings, electrical schematics, maps and so on), so I
> figured the tiling mechanism might be useful there too, if we had one.  But
> I tried using TableView for that, and it was reasonably successful.
> TableView does a good job with instantiating the tiles just-in-time: you
> only get as many tiles as you can see onscreen, and an extra “border” of
> spare tiles in case you then pan the view by small increments.  In the PDF
> case, rendering tiles is the bottleneck, because QtPDF uses the same raster
> engine that Chrome does to render PDF pages, and it's not
> multi-thread-capable; so tiling with TableView made it possible to render
> large pages at a higher resolution than you could fit into a single GPU
> texture, but caused a big slowdown (rendering each tile took almost as long
> as rendering the whole page at maximum texture size: just a demonstration
> of what’s wrong with CPU-based raster engines).  But if you can get your
> tiles quickly, I think TableView is great for that.  The tiles can fit
> together perfectly with no gap, and you get the advantage of its
> well-maintained dynamic loading mechanism.  Each tile is a Qt Quick
> Item-based delegate though (at least an Image, plus whatever else you
> declare there), so as with item views in general, you should avoid making
> your delegates too complex (interactive per-tile features), because the
> overhead gets multiplied by the number of delegates.
>
> Graphics View on the other hand has not been getting much attention in R
> for over a decade already: only bug fixes.  (Many of us haven’t used it
> much ourselves, aren’t very familiar with the implementation, and haven’t
> learned all the lessons that we could from it.  This includes me, although
> I had a simple 

[Interest] QFileSystemWatcher: Timing of file changed signal.

[Michael Jackson]

I have a question about exactly _when_ the signal for "file changed" is
sent. Say we have a file watcher on a 10 Gigabyte file. And we start
rewriting that file (not atomically) by streaming data to the file. Does
the signal get sent when we get done streaming the data to the file and we
close the file on our end? or at some other time?

I get that this probably completely depends on the operating system being
used. I am not really familiar at that low a level how filesystems work
(like NTFS, APFS and others) so I can't figure out what would happen.

This also probably points to an issue in our design where we probably
should just be streaming to a temp file then atomically replace
the original with the new one.
--
Mike Jackson
BlueQuartz Software
Principal DREAM.3D Developer
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Qt 6.5.2: QTreeView::isExpanded() not working?

[Michael Jackson]

I have some custom painting code for a QTreeView, so I created the

VXPipelineModelItemDelegate : public QStyledItemDelegate
```


To do the custom painting. All is generally good. The issue I am facing
with Qt 6.5.2 (macOS) is that when try to call m_TreeView (which is the
pointer to QTreeView that is being painted, when I ask
m_TreeView->isExpanded(index) (and index is valid because everything else
that depends on it being valid is painted) it *always* comes back false.
Even when I am clicking on the index in the UI it always comes back false.
I will assume this is user error at this point rather than a bug in Qt
6.5.2. Anyone have any thoughts?

  if(m_TreeView->isExpanded(index)) // <<=== Always false
  {

  }


Thoughts? Besides putting together a minimal example and submitting?
—
Mike Jackson
___
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?

[Michael Jackson]

Actually, on macOS, XCode is specifically tied to a version of macOS. There is 
a short period of time where a version of Xcode will overlap 2 versions of 
macOS (usually the current and one version back). So for me, still back on 
macOS Catalina (out of choice) I use Xcode 12.4 which also works on my macOS 11 
Big Sur machine. Current Xcode version is 14.2 and ONLY works on macOS 12.5 and 
above. So I am locked out of the "official" Apple compilers without having to 
move up to a newer macOS. (That is a different conversation).

We also provided our own build machines for Azure (self hosted agents) and 
moving up compilers usually involves spending a few days updating those build 
machines with new versions of the libraries (all built using the new 
compilers). This used to be easy when Qt offered the offline installers but now 
I get to wait through the several gigabyte download on a dozen machines over a 
100Mbps connection. And now I get the fun of building Qt 
5.15.[3.4.5.6.7.8.9...] because those installers are not even around through 
the maintenance tools for open source developers. 

For the Visual Studio compilers, the same thing applies. First versions of any 
piece of software is usually a train wreck. I'm not into beta testing other 
peoples software, especially compilers. I'll wait till the dust settles before 
moving up. Again, for us it is a matter of finding a time when we are not 
crushed with deadlines to have the developer move up compilers, deal with all 
of the incompatibilities just introduced by said new compiler, and then get 
back to work. 

Like someone else said, it becomes inertia. Our tools work on a daily basis and 
any interruption to those tools becomes a productivity issue. Small 
productivity losses I can handle, losing multiple days to an "upgrade" just 
isn't on my list of things to do.

I feel like dropping VS2017 support is a no-brainer. Dropping macOS Catalina 
support is also a no brainer. Not sure about VS2019 as according to 
https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019 the 
support will end in 2024 and has extended support until 2029. And that is 
assuming VS 2019 16.11 and nothing earlier.

Just my 2 cents
--
Mike Jackson 


On 1/23/23, 6:05 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 23 January 2023 09:19:07 PST Scott Bloom wrote:
> One of the limiting factors in general, is we would prefer NOT to have 2
> compilers with very different c++ support.  There have a been a number of 
"
> C++11/14/17 etc" that have been partially implemented on one, and not on
> the other.  Unfortunately, NOT always protected by the "version switch".
> 
> The biggest one that hit me, is std::make_unique which didn't exist on g++
> but did on windows.  So if used, when you go build on linux, you have to
> clean up your code.  There have been some others through the years.
> 
> So in general, we try to keep their abilities as close as possible,

Thank you Scott, but you've answered the inverse of my question.

You're talking about the ability to write code given a compiler you can't 
move 
from and what one needs to do to keep that working. I am asking why people 
are 
staying with the older one, if the new one is available and shouldn't (in 
theory) produce a compatibility burden with already-compiled code.

On Linux, people generally use the compiler that their Linux distribution 
offers and many of them don't upgrade to another GCC major version after 
the 
initial release (CentOS/RHEL with the devtoolset being a notable 
exception). 
This implies to us that if a Linux distribution from 2018 is still a valid 
development environment, then GCC 8 must work too.

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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

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

[Michael Jackson]

Just some clarifications:

 

Apple used 68K processors from 1984 to 1994. 10 Years of use.

 

Apple Started using PPC in 1994 (Announced in 1992) and their last PPC machine 
was in 2006. 12 Years of use.

 

Apple started using x86 in 2006 and their last x86 machine was in 2020 (which 
is still in production). 14+ years of use ( and macOS still officially supports 
x86 releases)

 

Apple started using Arm64 in 2020…. 

 

So not really a “jolt every 3 years”. You have had 3 _total_ jolts over the 
course of 30 years. 

 

--

Mike Jackson 

 

From: Interest  on behalf of Turtle Creek 
Software 
Date: Sunday, December 18, 2022 at 10:24 AM
To: Qt Interest 
Subject: Re: [Interest] Qt 6.5 Is Irrelevant...

 

We sell to construction companies.  They are not computer geeks, and often run 
the original OS until the machine dies.  Given the flakiness of some Mac OS 
upgrades, that may be ideal policy.  

 

Apple moves far too fast with chip, OS and language changes. It's hard for 
small developers to keep up. We started on 680x0, Pascal and Toolbox. That's 3 
chips, 3 languages and 3 OS frameworks ago. A jolt every 3 years.  

 

We gave up on Xcode/Cocoa since Obj-C seemed doomed and we have too much C++ 
code to ever port to Swift and/or SwiftUI.  I imagine Qt faces the same 
problems, but on a more system level.

 

If Qt Co does not have the resources to support more than 3 years of OS 
versions, then please at least create some good stopping points that solidly 
support older Mac OS versions. Explain which to use for which OS ranges. Then, 
developers may need to build multiple apps.  That kinda sucks, but it's better 
than losing/annoying users because they don't want the expense/pain of new 
hardware.

 

Casey McDermott

TurtleSoft.com

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

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

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Michael Jackson]

Dear Tuuka or any other QtCreator Developers,

    I am interested in finding out more how QtCreator has implemented their 
telemetry system. We would also like to add this capability to our open-source 
software but this is our first foray into this kind of telemetry system. Maybe 
just a hint what what code bits to grep for in the source would get me started.

 

Thank You.

--

Mike Jackson 

 

From: Interest  on behalf of Qt Interest 

Reply-To: Tuukka Turunen 
Date: Saturday, December 17, 2022 at 3:45 AM
To: "Macieira, Thiago" , 
"developm...@qt-project.org" , Qt Interest 

Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

 

Hi,

 

Most of the macOS users are quite quick to take on new OS versions and this is 
true also for adoption of macOS versions with the new numbering scheme. Apple 
hardware is also rather good in keeping support for new OS versions and at 
least between versions 10.15 and 11 there does not seem to be a major drop in 
what HW is supported. 

 

The challenge we have with supporting macOS versions is that some users migrate 
really quickly, so we need to work a lot with the unreleased (developer beta) 
versions in order to ensure Qt works well with the new macOS version optimally 
before it is even released for production. We also aim to keep supporting older 
versions and the ones in between. This means quite a lot of CI system load – 
especially as we now have both Intel and ARM architectures to test on. 

 

There is also positive development happening. With the latest versions the 
virtualization support is improving so that we are hopeful to be able to use 
the hardware more efficiently (by running two virtual machines in each physical 
HW). So while macOS is still far from the convenience we have with Linux and 
Windows that support sever grade hardware, things are getting better with Macs 
as well going forward (not for 10.15, though). 

 

Related to the usage of 10.15 one indication comes from Creator telemetry. 
Based of this roughly 8% of the macOS users this year have version 10.15. Of 
course, this is not a direct indicator for how many end users of Qt based apps 
there are with macOS 10.15, just how much of the developers using Creator have 
it. Telemetry is fully optional, but I think it is reasonable accurate for this 
type of data point as the OS version is unlikely to greatly affect sending or 
not sending the telemetry data. Note also that we have a lot of different Qt 
versions supporting macOS 10.15, and many applications are still using Qt 5. 

 

Yours,

 

Tuukka

 

From: Interest  on behalf of Thiago Macieira 

Date: Saturday, 17. December 2022 at 1.20
To: developm...@qt-project.org , 
interest@qt-project.org 
Subject: Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of 
Mac Desktops

On Friday, 16 December 2022 18:15:11 -03 Alexander Dyagilev wrote:
> But why did you do this? Does the supporting of 10.15 really increase
> the development cost for Qt Company?

I can't speak for the Qt Company costs, particularly for the fact that this is 
one of their LTS releases.

But in general, it does increase the costs overall. There are new APIs that we 
can use if we don't have to keep 10.15 compat, there's one fewer platform to 
test on (usually with a virtual machine) before release, and so on. The 
benefits may not be realised now, but they will come in the future.

For me specifically, what matters is that 11.0 dropped support for Intel Macs 
that don't have AVX2 support, meaning that I can now assume that all machines 
running Qt 6.5 natively have it. We had further changes based on this 
assumption ready to go for 6.5, but they got removed at the last minute due to 
unexpected side-effects and the feature freeze being too close.

On Friday, 16 December 2022 19:44:16 -03 Michael Jackson wrote:
> I agree here. Is Qt 6.5 now using an API or a compiler feature that macOS
> 10.15 does not support? 

As of *today*, no. This may change tomorrow, as developers continue to do 
their work. That means that, as of *today*, Qt 6.5 *could* be compiled to run 
on 10.15, by just lowering the default minimum version somewhere in a config 
file. But we are not promising that this will remain true and especially we are 
not testing that it works.

We had to make a call and following Apple's own support lifetime makes sense. 
If you want to stay on an OS that is not receiving important fixes, then you 
can also stay on a Qt that is not receiving fixes. Though unlike Apple, you can 
backport fixes to 6.4 yourself or remove the new requirements from 6.5 yourself 
(or contract someone to do it for you).

Moreover, there's a time delay. This affects Qt 6.5, which will be released in 
March 2023, which means it probably affects applications released in May 2023 
and later.

>  Is there a security library that Qt 6 depends on (OpenSSL is my guess) that
>  1

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Michael Jackson]

On 12/18/22, 8:19 AM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Sunday, 18 December 2022 06:47:57 -03 Nuno Santos wrote:
> Many people are still running their Intel macs. I speak for myself. I had
> bought a really powerful quad core Intel mac laptop one year before m1 is
> out. Is terrible but what am I going to do? Throw it out of the window if
> it is still able to do the job?

Your computer is still supported.

The ones that have fallen out of support with the 11.0 requirement are 
those 
older than 2014.

Please also note the requirement of a system to *develop* with Qt may be 
even 
higher than those to *deploy* Qt on, usually because the minimum version of 
Xcode required may not install on an older OS. Right now, they appear to be 
the same.

> The ones who venture in instant updates are the ones who report problems 
to
> the plugin makers which can sometime take months to fix the problems.
[...]
> My experience is that sometimes people take up to two years to upgrade to 
a
> more recent operating system.

Months is fine. Even a year or two.

We're talking about someone making no major updates for 3 years.

Yep, that is me and I am also a developer (well at least some days). My reason 
for not upgrading:

* IMO: Apple continues to degrade my user experience to the point that I simply 
do not want to update.
* We are not using anything out of C++20 so my Xcode version is still useful.

After realizing 2 things I'm in favor of the cut-off:
 * Qt 6.5 is an LTS which means Qt would be stuck with macOS 10.15 support for 
2.5 years _after_ Apple has cut support. The Qt Company would do the same for 
Windows or Linux so Apple isn't being treated any differently.
* Qt 6.4 is still around in source form for those that need to stick with 10.15 
support.

Every software company that develops dependent libraries goes through this 
process. They cannot make everyone happy and they cannot simply support every 
operating system forever. I think keeping support for as long as they did was 
acceptable. Been using an M1 for development for the last few weeks and just 
for the speed and battery improvement alone I can deal with the (IMO) crappy UI 
changes.

Cheers
Mike Jackson



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

Re: [Interest] [Development] Qt 6.5 Is Irrelevant for More than 95% of Mac Desktops

[Michael Jackson]

I agree here. Is Qt 6.5 now using an API or a compiler feature that macOS 10.15 
does not support? If that is the case then sure I agree with the change. If you 
are changing "just to change" then I don't really agree. I sort of get the 
argument that "Apple stopped supporting 10.15" but what implications does that 
have for Qt 6? Is there a security library that Qt 6 depends on (OpenSSL is my 
guess) that 10.15 isn't now updating? Is Qt 6 using the new APIs from that 
version of OpenSSL (or what ever library broke)? Is there a graphics API that 
Qt 6 now depends on that is macOS 11.0 and greater? Maybe that is the reason?

--
Mike Jackson

On 12/16/22, 16:15, "Interest on behalf of Alexander Dyagilev" 
 wrote:

Hello,

It's understandable why Apple did this.

But why did you do this? Does the supporting of 10.15 really increase 
the development cost for Qt Company?


On 12/16/2022 3:39 PM, Thiago Macieira wrote:
> On Friday, 16 December 2022 09:20:44 -03 coroberti wrote:
>> Hi,
>> Since Qt 6.5 drops Mac OS 10.15 Catalina,
>> it apparently starts to be irrelevant for at least 95% of Mac Desktops.
> Please note the problem is that *Apple* dropped 10.15 earlier this year.  
Its
> last security release was already released and there won't be any new 
ones any
> more. If you have a problem with that, you can contact Apple support or 
vote
> with your pocket on your next computer or OS.
>
> In any case, even though the Qt minimum supported release is now 11.0, 
10.15
> will still work for a while. Eventually, there will be your usual crop of 
API
> uses that won't work in 10.15, but right now they aren't there because the
> minimum version bump only happened last month in Qt. So 6.5 will likely
> compile on 10.15 out of the box, or with minimal action on your part.
>
>> To keep Qt-6 being still relevant for Mac Desktop open-source
>> development, please
>> consider keeping  Mac OS 10.15 as a target.
> If you convince Apple to restart support for it, sure.
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] Qt 5.15.7-lts-lgpl compile on M1 Silicon (macOS 10.12 Monterey) Issues

[Michael Jackson]

To answer my own question a bit I ended up trying out several
different releases of LLVM+Clang. 15.0.4 for the M1 allowed the build
to completely proceed. I was also setting LLVM_INSTALL_ROOT but just
appending to the path to get 'llvm-config' on the path seemed to work
better. For the x86_64 build I ended up using LLVM+Clang 11.0.0 and
that allowed everything to work correctly.

Sorry for the weekend noise.
--
Mike Jackson

On Sun, Nov 6, 2022 at 5:07 PM Michael Jackson
 wrote:
>
> I have been trying to compile 5.15.7-lts-lgpl on my M1 system running
> Monterey. The actual compile seems to go off without a hitch for the
> parts that I am compiling but when I get to the part of "make docs"
> then I am getting an error but just not sure how to track this down
> and Google doesn't seem to find my error.
>
> here is the last part of the compile output:
>
> -
> cd network/ && ( test -e Makefile ||
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/bin/qmake -o
> Makefile /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/network.pro
> ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
> Makefile prepare_docs
> /Users/Shared/NX_SDK/Qt/5.15.7/clang_arm64/bin/qtattributionsscanner
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase --filter
> QDocModule=qtnetwork -o
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/network/codeattributions.qdoc
> File 
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
> Unknown key CopyrightFile.
> File 
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
> Expected JSON string as value of LicenseFiles.
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/network/qdoc_wrapper.sh
> -outputdir 
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/doc/qtnetwork
> -installdir /Users/Shared/NX_SDK/Qt/Docs/Qt-5.15.7
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/doc/qtnetwork.qdocconf
> -prepare -indexdir
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/doc
> -no-link-errors
> -I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network -I.
> -I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/kernel
> -I../../include -I../../include/QtNetwork
> -I../../include/QtNetwork/5.15.7
> -I../../include/QtNetwork/5.15.7/QtNetwork
> -I../../include/QtCore/5.15.7 -I../../include/QtCore/5.15.7/QtCore
> -I../../include/QtCore -I.moc
> -I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/mkspecs/macx-clang
> -F/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/lib
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1
> -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/include
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include
> -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
> qt.qdoc: Start qdoc for QtNetwork in dual process mode: prepare phase.
> QIODevice::write: device not open
> qt.qdoc: Parse source files for "QtNetwork"
> qt.qdoc: Source files parsed for "QtNetwork"
> qt.qdoc: End qdoc for QtNetwork in dual process mode: prepare phase.
> cd sql/ && ( test -e Makefile ||
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/bin/qmake -o
> Makefile /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/sql/sql.pro
> ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
> Makefile prepare_docs
> /Users/Shared/NX_SDK/Qt/5.15.7/clang_arm64/bin/qtattributionsscanner
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase --filter
> QDocModule=qtsql -o
> /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/sql/codeattributions.qdoc
> File 
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
> Unknown key CopyrightFile.
> File 
> /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
> Expected JSON string as value of LicenseFiles.
> libc++abi: Pure virtual function called!
> make[5]: *** [qtattributionsscanner] Abort trap: 6
> make[4]: *** [sub-sql-prepare_docs] Error 2
> make[3]: *** [sub-src-prepare_docs] Error 2
> make[2]: *** [module-qtbase-prepare_docs] Error 2
> make[1]: *** [html_docs] Error 2
> make: *** [docs] Error 2
> 
>
>
> Here is the configure that I am using:
>
> #--
> export LLVM_INSTALL_DIR=/opt/local/clang+llvm-15.0.2-arm64-apple-darwin21.0
> cd $Qt5_BUILD_DIR
> $DEV_ROOT/$Qt5_SOURCE_DIR/configure \
> --prefix=$INST

[Interest] Qt 5.15.7-lts-lgpl compile on M1 Silicon (macOS 10.12 Monterey) Issues

[Michael Jackson]

I have been trying to compile 5.15.7-lts-lgpl on my M1 system running
Monterey. The actual compile seems to go off without a hitch for the
parts that I am compiling but when I get to the part of "make docs"
then I am getting an error but just not sure how to track this down
and Google doesn't seem to find my error.

here is the last part of the compile output:

-
cd network/ && ( test -e Makefile ||
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/bin/qmake -o
Makefile /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/network.pro
) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile prepare_docs
/Users/Shared/NX_SDK/Qt/5.15.7/clang_arm64/bin/qtattributionsscanner
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase --filter
QDocModule=qtnetwork -o
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/network/codeattributions.qdoc
File 
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
Unknown key CopyrightFile.
File 
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
Expected JSON string as value of LicenseFiles.
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/network/qdoc_wrapper.sh
-outputdir /Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/doc/qtnetwork
-installdir /Users/Shared/NX_SDK/Qt/Docs/Qt-5.15.7
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/doc/qtnetwork.qdocconf
-prepare -indexdir
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/doc
-no-link-errors
-I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network -I.
-I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/network/kernel
-I../../include -I../../include/QtNetwork
-I../../include/QtNetwork/5.15.7
-I../../include/QtNetwork/5.15.7/QtNetwork
-I../../include/QtCore/5.15.7 -I../../include/QtCore/5.15.7/QtCore
-I../../include/QtCore -I.moc
-I/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/mkspecs/macx-clang
-F/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/lib
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/include
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
qt.qdoc: Start qdoc for QtNetwork in dual process mode: prepare phase.
QIODevice::write: device not open
qt.qdoc: Parse source files for "QtNetwork"
qt.qdoc: Source files parsed for "QtNetwork"
qt.qdoc: End qdoc for QtNetwork in dual process mode: prepare phase.
cd sql/ && ( test -e Makefile ||
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/bin/qmake -o
Makefile /Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/sql/sql.pro
) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile prepare_docs
/Users/Shared/NX_SDK/Qt/5.15.7/clang_arm64/bin/qtattributionsscanner
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase --filter
QDocModule=qtsql -o
/Users/Shared/OpenSource/qt-5.15.7-arm64-release/qtbase/src/sql/codeattributions.qdoc
File 
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
Unknown key CopyrightFile.
File 
/Users/Shared/OpenSource/qt-5.15.7-src/qtbase/src/3rdparty/libjpeg/qt_attribution.json:
Expected JSON string as value of LicenseFiles.
libc++abi: Pure virtual function called!
make[5]: *** [qtattributionsscanner] Abort trap: 6
make[4]: *** [sub-sql-prepare_docs] Error 2
make[3]: *** [sub-src-prepare_docs] Error 2
make[2]: *** [module-qtbase-prepare_docs] Error 2
make[1]: *** [html_docs] Error 2
make: *** [docs] Error 2



Here is the configure that I am using:

#--
export LLVM_INSTALL_DIR=/opt/local/clang+llvm-15.0.2-arm64-apple-darwin21.0
cd $Qt5_BUILD_DIR
$DEV_ROOT/$Qt5_SOURCE_DIR/configure \
--prefix=$INSTALL_PREFIX \
--docdir=$DOC_INSTALL_PREFIX \
--examplesdir=$EXAMPLE_INSTALL_PREFIX \
-platform macx-clang \
-device-option QMAKE_APPLE_DEVICE_ARCHS=$ARCH \
-device-option QMAKE_MACOSX_DEPLOYMENT_TARGET=11.0 \
-$BUILD_TYPE \
-opensource -confirm-license \
-gui \
-widgets \
-no-gif \
-no-icu \
-no-pch \
-no-angle \
-no-dbus \
-no-sqlite \
-no-harfbuzz \
-skip multimedia \
-skip qtcanvas3d \
-skip qtcharts \
-skip qtconnectivity \
-skip qtgamepad \
-skip qtlocation \
-skip qtmultimedia \
-skip qtnetworkauth \
-skip qtpurchasing \
-skip qtremoteobjects \
-skip qtscript \
-skip qtsensors \
-skip qtserialbus \
-skip qtserialport \
-skip qtwebchannel \
-skip qtwebengine \
-skip qtwebsockets \
-skip qtxmlpatterns \
-skip qtquick3d \
-skip qtquickcontrols \
-skip qtquickcontrols2 \
-skip qtquicktimeline \
-skip qtdeclarative \
-nomake examples \
-nomake tests \
-make tools
--

It is always nice to have the documentation local but maybe not
completely 

Re: [Interest] Small survey on necessary Qt Container size

[Michael Jackson]

We write science data processing software 
(github.com/bluequartzsoftware/dream3d) and there have been more than a few 
times where we load up past 32 bit signed int number of elements in an array. 
We are adding out-of-core to our software now which means we are definitely 
going past signed 32 bit indexes. We rewrote our core software library to 
remove any Qt codes from them so that we can have this kind of access using 
std::* containers.

My guess is that if you are NOT in the data processing realm the Qt containers 
are probably just fine for your use cases. If you need something more you have 
already made the changes necessary to move your code forward. 
Std::shared_ptr> also works well to pass around data as does the 
usual "const ref" passing which helps you keep ownership figured out.

Just my 2 cents.

--
Mike Jackson


On 9/5/22, 13:56, "Interest on behalf of A. Pönitz" 
 wrote:


Hi all.

In order to base my potential arguments in a certain discussion on a
neighboring list not purely just on my own experience with both Qt and
(independently) large data (a.k.a. "gut feeling") I would appreciate
if /you/ could help me to find a - very rough, readily admitted in
advance to be completely unscientific - estimation for an answer to
the following question:

  How often do people /need/ /Qt/ containers with /more than
  1 billion elements/ ? 

The question is really meant as conjunction, i.e. I'd like to count
only setups meeting both criteria at the same time:

   1. /Some/ relevant data set is really > 1e9 entries,

   2. It really needs to be a /Qt/ container because of some Qt container
  feature (e.g. reference counting or e.g. because of Q(5)List's
  "indirect" storage etc) that a std:: container does not offer
  out-of-the-box and it /needs/ to be like that, i.e. there is no
  simple / straightforward replacement like using std::*, and
  benefits do not exceed drawbacks like more expensive write
  access.

Problems meeting only one of the two criteria won't count, but I'd
accept "Would have needed in the past, but since Qt < 6 didn't offer
it I had to go through big trouble and create a hand-crafted solution"
;-)

In case of proprietary/personal/otherwise non-disclosable examples
I'd be happy enough to get a private mail. In any case: Any feedback
is appreciated.

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


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

Re: [Interest] Deploying 5.15.2 on Ubuntu 20.04 (Qt5OpenGL.so)

[Michael Jackson]

On 8/22/22, 10:24 AM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 22 August 2022 09:11:29 -03 Michael Jackson wrote:
> For our open source program we create self-contained .tar.gz archives for
> users to download. Currently we use Qt5.15.2 for those archives. After
> packaging I run a sanity check on my Ubuntu 20.04 fully patched system and
> the program will launch just fine. It is a GUI based program. Last week 2
> users reported that when the launch the program on their Ubuntu 20.04
> systems they get an error when one of our Plugins loads (we use Qt's 
plugin
> infrastructure to load) that basically says the plugin cannot load because
> Qt5OpenGL.so could not be loaded. That library is in the proper location
> (alongside all of the other libraries in the install). I'm not a linux 
guy
> and Googling didn't really turn anything up that was helpful. We dropped
> back to an older version of our program where I built against Qt5.9 and
> those binaries worked just fine. I'm looking for advice on what might be
> the issue? OpenGL drivers (The user's machine was using a Mesa install
> running on an Intel HD hardware). I think we actually build on Ubuntu
> 18.04 but we build against the Qt5.15 binaries from Qt.io instead of 
system
> installed Qt binaries. Maybe that is the issue? Advice is appreciated.

Please have them run with QT_DEBUG_PLUGINS=1 and send you the output. 
There'll 
be a line there saying that the plugin failed to load because something 
happened. It's probably a missing system library.

Have your users install that if it is the case.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


So we tracked down the issue to when we are creating the installer (through 
cmake) and the RPATHS are all getting adjusted for the dependent libraries, one 
library does NOT get adjusted and that library still references a system 
installed Qt5. I will have to go back through the install codes to figure out 
why that is not occurring.

Thanks for all the hints, it helped get us to the answer.

--
Mike Jackson


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

[Interest] Deploying 5.15.2 on Ubuntu 20.04 (Qt5OpenGL.so)

[Michael Jackson]

For our open source program we create self-contained .tar.gz archives for users 
to download. Currently we use Qt5.15.2 for those archives. After packaging I 
run a sanity check on my Ubuntu 20.04 fully patched system and the program will 
launch just fine. It is a GUI based program. Last week 2 users reported that 
when the launch the program on their Ubuntu 20.04 systems they get an error 
when one of our Plugins loads (we use Qt's plugin infrastructure to load) that 
basically says the plugin cannot load because Qt5OpenGL.so could not be loaded. 
That library is in the proper location (alongside all of the other libraries in 
the install). I'm not a linux guy and Googling didn't really turn anything up 
that was helpful. We dropped back to an older version of our program where I 
built against Qt5.9 and those binaries worked just fine. I'm looking for advice 
on what might be the issue? OpenGL drivers (The user's machine was using a Mesa 
install running on an Intel HD hardware). I think we actually build on 
Ubuntu 18.04 but we build against the Qt5.15 binaries from Qt.io instead of 
system installed Qt binaries. Maybe that is the issue? Advice is appreciated.

If you want to give the binaries a go they are at: 
http://dream3d.bluequartz.net/binaries/cmu_2022

Thank You.
--
Mike Jackson 


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

Re: [Interest] QMap<> function documentation

[Michael Jackson]

Should I put in a bug report on this so that the docs get updated at some point 
in the future?

--
Mike Jackson 

On 5/25/22, 12:51 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Wednesday, 25 May 2022 09:19:52 PDT Michael Jackson wrote:
> Specifically for the part of “value(…)” and “values(…)” that talk about
> “multiple values for a key”. Each key is unique in the QMap so how would I
> have multiple values associated with a key? Maybe I’m just not
> understanding what is trying to be said in the documentation. It looks 
like
> this should be in the MultiMap<> docs maybe? I bring this up because a
> young engineer was a bit confused by the docs.

That's stale documentation from when QMap could do insertMulti. You can 
only 
do that with QMultiMap now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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


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

[Interest] QMap<> function documentation

[Michael Jackson]

I feel like the documentation for QMap<>::value and QMap<>::values is a bit 
misleading:

 
const T QMap::value(const Key , const T  = T()) const
Returns the value associated with the key key.

If the map contains no item with key key, the function returns defaultValue. If 
no defaultValue is specified, the function returns a default-constructed value. 
If there are multiple items for key in the map, the value of the most recently 
inserted one is returned.

See also key(), values(), contains(), and operator[]().
QList QMap::values() const
Returns a list containing all the values in the map, in ascending order of 
their keys. If a key is associated with multiple values, all of its values will 
be in the list, and not just the most recently inserted one.

See also keys() and value().

 

Specifically for the part of “value(…)” and “values(…)” that talk about 
“multiple values for a key”. Each key is unique in the QMap so how would I have 
multiple values associated with a key? Maybe I’m just not understanding what is 
trying to be said in the documentation. It looks like this should be in the 
MultiMap<> docs maybe? I bring this up because a young engineer was a bit 
confused by the docs. 

 

Thank You.

--

Mike Jackson

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

Re: [Interest] Change QML Application Style on Runtime

[Michael Jackson]

Here is a bit of the code that we used in our desktop QML application to reload 
the application when the user pressed F7.

QQmlApplicationEngine engine;


QmlReloader reloader();
QObject::connect(
, ::objectCreated, qApp,
[](QObject* obj, const QUrl& objUrl) {
  if(obj == nullptr)
  {
qDebug() << "Can't load " << objUrl << " exiting.";
QCoreApplication::exit(-1);
  }
},
Qt::QueuedConnection);

qmlRegisterSingletonInstance("NX.interfaces", 1, 0, 
"Presenter", );
qmlRegisterSingletonInstance("NX.interfaces", 1, 0, 
"Clipboard", );
engine.addImportPath("qrc:/");
engine.addImportPath(DREAM3DNX::k_QmlNXResourceRoot);
engine.load("qrc:/main.qml");
qDebug() << "QML2_IMPORT_PATH:" << engine.importPathList();

QObject::connect(, ::reload, qApp, [, 
](QQmlApplicationEngine* engine) {
  qDebug() << "F7 Reloader Activated... ";
  NX::NXParameterManager* parameterManager = 
NX::NXParameterManager::Instance();
  parameterManager->setQmlParameterPrefix(
#ifdef Q_OS_WINDOWS
  "file:///"
#else
  "file://"
#endif
  + DREAM3DNX::k_QmlNXResourceRoot.toStdString());
  qmlRegisterSingletonInstance("NX.interfaces", 1, 0, 
"Presenter", );
  qmlRegisterSingletonInstance("NX.interfaces", 1, 0, 
"Clipboard", );
  engine->addImportPath(DREAM3DNX::k_Qml3rdPartyResourceRoot);
  engine->addImportPath(DREAM3DNX::k_QmlNXResourceRoot);
  engine->load(QUrl::fromLocalFile(DREAM3DNX::k_QmlApplicationsResourceRoot 
+ "/DREAM3D/main.qml"));
});

Maybe that helps. Maybe it does not.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 

On 5/24/22, 8:31 PM, "Interest on behalf of Alexander Dyagilev" 
 wrote:

Hello,

Try to call App.changeStyle via queued connection. I.e. your 
Button::onClicked handler must exit BEFORE you shut the engine down.


On 5/24/2022 6:45 PM, randomslap--- via Interest wrote:
> Hello Qt people!
>
> I would like to inquire your assistance regarding this:
> Is there a way to change the style of a QML(QuickControls2) UI of an 
> application while it runs? Specifically the program should work with 
> QQmlApplicationEngine and an ApplicationWindow QML Item.
>
> I have tried making a simple program that could reload its quick 
> style upon clicking one of the buttons on it. The program appears at 
> first and seems to close and execute the function that tries to reload 
> the style but seems to fail on engine.load(). I have sent an image of 
> all the code and the code files too.
>
> I would specifically like to implement something like this on a 
> Desktop Environment and being able to load a new style on runtime 
> would allow for unlimited "theming" options.
>
> Thank you for maintaining the Qt Project.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] QColumnView and QTreeView using same model

[Michael Jackson]

Thank you for the tips. Got the checkboxes working. 
--
Mike Jackson

On 5/4/22, 10:06 AM, "Interest on behalf of Tony Rietwyk" 
 wrote:

On 4/05/2022 11:43 pm, Michael Jackson wrote:
> ...
> Now on to figure out how to display checkboxes next to each item. I've 
tried:
>
> Qt::ItemFlags ImportDataStructureModel::flags(const QModelIndex& index) 
const
> {
>if(!index.isValid())
>{
>  return {};
>}
>return Qt::ItemIsUserCheckable | Qt::ItemIsSelectable | 
QAbstractItemModel::flags(index);
> }
>
> Which does not seem to show anything. I'll probably have to create a 
custom delegate.
> --
> Mike Jackson
>
Hi Mike,

If you return flag ItemIsUserCheckable in your model, then you must also 
return a valid variant with Qt::CheckState for data(Qt::CheckStateRole) 
- it won't just assume Qt::Unchecked.

Ditto with the item widgets - besides item->setFlags, you need to call 
item->setCheckState as well.

Tony

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


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

Re: [Interest] QColumnView and QTreeView using same model

[Michael Jackson]

Thanks for the help. I was able to track it down to errors in my parent(…) 
method. I was just returning:

return createIndex(0, 0, some_unique_value);

which apparently works just fine for tree views but not for QColumnView.

Now on to figure out how to display checkboxes next to each item. I've tried:

Qt::ItemFlags ImportDataStructureModel::flags(const QModelIndex& index) const
{
  if(!index.isValid())
  {
return {};
  }
  return Qt::ItemIsUserCheckable | Qt::ItemIsSelectable | 
QAbstractItemModel::flags(index);
}

Which does not seem to show anything. I'll probably have to create a custom 
delegate.
--
Mike Jackson


--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


On 5/3/22, 6:07 PM, "Scott Bloom" <mailto:sc...@towel42.com> wrote:

I have found when I use a custom model, most issues using views, are tied to an 
issue of some corner case condition in the model not being handled correctly. 



~~Scott



 Original message ----
From: Michael Jackson  
Date: 5/3/22 3:05 PM (GMT-08:00) 
To: Scott Bloom , Qt Interest List  
Subject: Re: QColumnView and QTreeView using same model 

No idea that existed. Now just trying to figure out how to translate qmake 
instructions to modern CMake instructions to be able to link against it.
 
--
Mike Jackson
 
On 5/3/22, 4:41 PM, "Scott Bloom" <mailto:sc...@towel42.com> wrote:
 
Have you run the modeltest on it?

Scott
 
From: Interest  On Behalf Of Michael Jackson
Sent: Tuesday, May 3, 2022 12:57 PM
To: Qt Interest List 
Subject: [Interest] QColumnView and QTreeView using same model
 
I have a custom QAbstractItemModel implementation that works correctly when 
using a QTreeView, i.e., I can open the complete hierarchy of the tree without 
any issues. I switched up to the QColumnView due to size constraints and now 
using the same exact instance of the model I can only navigate into the first 
item that has children. Other items at the root level that have children are 
shown with the little graphic arrow as having children but none of the children 
are actually listed in the next column over. I even put both the QTreeView and 
the QColumnView into my Widget at the same time with the same instance of the 
model and the QTreeView does not have any problems displaying the various 
levels.
 
Has anyone else seen something like this? I took at look at the Qt bug database 
and nothing really stuck out. I tried a QFileSystemModel for giggles and that 
worked as expected. So clearly I’ve got something sort of messed up in my 
custom model that allows the treeview to work but not the columnview. Odd.
--
Mike Jackson


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

Re: [Interest] QColumnView and QTreeView using same model

[Michael Jackson]

No idea that existed. Now just trying to figure out how to translate qmake 
instructions to modern CMake instructions to be able to link against it.

 

--

Mike Jackson

 

On 5/3/22, 4:41 PM, "Scott Bloom"  wrote:

 

Have you run the modeltest on it?

Scott

 

From: Interest  On Behalf Of Michael Jackson
Sent: Tuesday, May 3, 2022 12:57 PM
To: Qt Interest List 
Subject: [Interest] QColumnView and QTreeView using same model

 

I have a custom QAbstractItemModel implementation that works correctly when 
using a QTreeView, i.e., I can open the complete hierarchy of the tree without 
any issues. I switched up to the QColumnView due to size constraints and now 
using the same exact instance of the model I can only navigate into the first 
item that has children. Other items at the root level that have children are 
shown with the little graphic arrow as having children but none of the children 
are actually listed in the next column over. I even put both the QTreeView and 
the QColumnView into my Widget at the same time with the same instance of the 
model and the QTreeView does not have any problems displaying the various 
levels.

 

Has anyone else seen something like this? I took at look at the Qt bug database 
and nothing really stuck out. I tried a QFileSystemModel for giggles and that 
worked as expected. So clearly I’ve got something sort of messed up in my 
custom model that allows the treeview to work but not the columnview. Odd.

--

Mike Jackson

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

[Interest] QColumnView and QTreeView using same model

[Michael Jackson]

I have a custom QAbstractItemModel implementation that works correctly when 
using a QTreeView, i.e., I can open the complete hierarchy of the tree without 
any issues. I switched up to the QColumnView due to size constraints and now 
using the same exact instance of the model I can only navigate into the first 
item that has children. Other items at the root level that have children are 
shown with the little graphic arrow as having children but none of the children 
are actually listed in the next column over. I even put both the QTreeView and 
the QColumnView into my Widget at the same time with the same instance of the 
model and the QTreeView does not have any problems displaying the various 
levels.

 

Has anyone else seen something like this? I took at look at the Qt bug database 
and nothing really stuck out. I tried a QFileSystemModel for giggles and that 
worked as expected. So clearly I’ve got something sort of messed up in my 
custom model that allows the treeview to work but not the columnview. Odd.

--

Mike Jackson

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

Re: [Interest] debugging on Macintosh

[Michael Jackson]

On 4/29/22, 12:20 PM, "j...@wavemetrics.com"  wrote:

> This happened to a colleague (sort of). He could debug one executable but 
not any of the other ones. We tried QtCreator 4.x, 6.x and 7.x. What we finally 
did was move his QtCreator configuration directory to the side and relaunch 
QtCreator. That seemed to fix it. Seems like a sledge hammer but it did work. 

Interesting. That would ~.config/QtProject? And then you have to re-create 
all your kits, etc.?

-John Weeks


Yes. That is correct. Also removed the CMakeLists.txt.user file from the 
project. We were able to bring over our styles, macros and snippets but the 
rest we had to recreate.

---
Mike Jackson


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

Re: [Interest] debugging on Macintosh

[Michael Jackson]

This happened to a colleague (sort of). He could debug one executable but not 
any of the other ones. We tried QtCreator 4.x, 6.x and 7.x. What we finally did 
was move his QtCreator configuration directory to the side and relaunch 
QtCreator. That seemed to fix it. Seems like a sledge hammer but it did work. 

--
Mike Jackson

On 4/27/22, 13:36, "Interest on behalf of John Weeks" 
 wrote:

I recently lost the ability to debug on my Macintosh. To be sure, we are 
building with an oldish Xcode and a new Qt Creator. This morning, though, I 
downloaded Qt Creator 7.01. For a brief, shining moment, I was able to break at 
a breakpoint, single-step and all the rest. Then I tried again. Gone again. The 
breakpoints while running still have the X on them.

Mac OS: 10.14.6
Xcode: 10.3
Qt Creator: 7.01

What should I be checking? The fact that I was able to debug briefly today 
suggests that there is some setting or, or... something that could be changed 
to restore my ability to debug.

-John Weeks

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


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

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

[Michael Jackson]

So buried deep in the code base (which was being reused from another project) 
was an event filter that was specifically looking for deleteLater() and then 
swallowing it up. I need to figure out why in the other project we were doing 
that. I knew it was "user error", just needed some help getting me point in the 
right direction to look for issues.

We would like to clean up children items when they are removed from the UI. 
They are generated on the fly and may contain heavier data that one would want 
just laying around. Now that deleteLater() is working, in fact we just remove 
the single parent, call deleteLater() on it and everything finally gets deleted 
as it should.

Thanks everybody for the help.

--
Mike Jackson 

On 4/3/22, 4:25 AM, "Interest on behalf of Nikos Chantziaras" 
 wrote:

On 01/04/2022 16:17, Michael Jackson wrote:
> I have a bit of code where in I am removing a QWidget from the UI and it 
needs to be truly cleaned up as its parent QObject is also being cleaned up. I 
thought I did the appropriate:
> 
> layout->removeWidget(widget);
> widget->setParent(nullptr);
> widget->deleteLater();

Why not simply delete the parent, which will then delete all its 
children immediately?

Also, I don't even remember a single case where I ever needed deleteLater().

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


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

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

[Michael Jackson]

That is an interesting bug. I will have to see if that situation is
similar to ours. If an object is in the middle of a signal call would
that impact deleteLater()?

We are on the main UI thread and there are no other threads (that our
application creates and uses) in the works at this point. (.. to
answer some earlier questions).

--
Mike Jackson

On Fri, Apr 1, 2022 at 11:22 AM Sérgio Martins  wrote:
>
> On 2022-04-01 14:17, Michael Jackson wrote:
> > I have a bit of code where in I am removing a QWidget from the UI and
> > it needs to be truly cleaned up as its parent QObject is also being
> > cleaned up. I thought I did the appropriate:
> >
> > layout->removeWidget(widget);
> > widget->setParent(nullptr);
> > widget->deleteLater();
> >
> > I put a "std::cout <<... " in the widget's destructor but I never see
> > it printed. I put a break point in the destructor and the break point
> > never gets hit. Looked around on the internet, various forums, double
> > checked that the event loop is actually running, called
> > qtapp->eventLoop()->processEvents() (or whatever that bit of code is)
> > a few times. Nothing. Currently we are leaking memory because we are
> > creating the widget but never deleting the widget when it is removed
> > from the UI. I'll assume since I have complete control of the UI that
> > the event loop is running. The last line in our main() is app.exec();
> > so I am assuming the event loop is running. This was originally with a
> > self-built Qt 5.15.2 on macOS 10.15 (Catalina) but I installed the
> > normal Qt 5.15.2 from www.qt.io and it behaves the same way. I have
> > other applications where this does actually work so I am trying to
> > figure out where in this new version of the application we messed up.
> > If anyone has any thoughts on where to look I would really appreciate
> > the sanity check.
> >
> > If we are in the middle of a signal being fired would that stop the
> > deleteLater() from working?
> > Do I need to manually disconnect all signals/slots for deleteLater() to
> > work?
> > We have a mix of new style connects and old style connects? Is that
> > messing with deleteLater()?
>
>
>
> One situation I've came across in the past was:
> https://bugreports.qt.io/browse/QTBUG-83030
>
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Reasons why deleteLater() might not work

[Michael Jackson]

I have a bit of code where in I am removing a QWidget from the UI and it needs 
to be truly cleaned up as its parent QObject is also being cleaned up. I 
thought I did the appropriate:

layout->removeWidget(widget);
widget->setParent(nullptr);
widget->deleteLater();

I put a "std::cout <<... " in the widget's destructor but I never see it 
printed. I put a break point in the destructor and the break point never gets 
hit. Looked around on the internet, various forums, double checked that the 
event loop is actually running, called qtapp->eventLoop()->processEvents() (or 
whatever that bit of code is) a few times. Nothing. Currently we are leaking 
memory because we are creating the widget but never deleting the widget when it 
is removed from the UI. I'll assume since I have complete control of the UI 
that the event loop is running. The last line in our main() is app.exec(); so I 
am assuming the event loop is running. This was originally with a self-built Qt 
5.15.2 on macOS 10.15 (Catalina) but I installed the normal Qt 5.15.2 from 
www.qt.io and it behaves the same way. I have other applications where this 
does actually work so I am trying to figure out where in this new version of 
the application we messed up. If anyone has any thoughts on where to look I 
would really appreciate the sanity check.

If we are in the middle of a signal being fired would that stop the 
deleteLater() from working?
Do I need to manually disconnect all signals/slots for deleteLater() to work?
We have a mix of new style connects and old style connects? Is that messing 
with deleteLater()?
--
Mike Jackson 


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

Re: [Interest] QtCreator and macOS ARM64

[Michael Jackson]

This should have gone to the QtCreator list. My apologies to this list.


@David M. Cotter What version of QtCreator are you using? Maybe I just need to 
remove all the preferences for older versions that may be hanging around.

 

--

Mike Jackson

 

On 3/18/22, 3:14 PM, "Interest on behalf of David M. Cotter" 
 wrote:

 

I’m running on a 2021 MacBook Pro with the M1 Max (arm)

 

I debug daily on it but it’s a bit touchy (debugger crashes often, app hangs 
for no reason and debugger can’t break into it, sometimes breakpoints fail etc)

 

But it DOES work. For me.

 

-dave



On Mar 18, 2022, at 12:03 PM, Michael Jackson  
wrote:

 

Is there a version of QtCreator where the lldb debugger can launch on macOS 
ARM64. I’m running macOS Big Sur (11.x) and when I try to debug I get the 
following error from the debugger:

 

"error: process exited with status -1 (attach failed ((os/kern) invalid 
argument))"}

 

I am running Qt Creator version 4.15 since that seems to be the only viable 
version. I tried version 6.0.2 but the code completion is broken. The engine I 
am assuming is just utterly broken. My source code is filled with error markers 
although the code compiles fine. Which is why I dropped back to the 
tried-and-true version 4.15.


Does anyone else use macOS ARM machines for daily debugging? I was getting 
ready to switch over to an M1 based machine but if I can’t debug that could be 
seen as an “issue”.

 

Thanks

Mike Jackson

 

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

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

[Interest] QtCreator and macOS ARM64

[Michael Jackson]

Is there a version of QtCreator where the lldb debugger can launch on macOS 
ARM64. I’m running macOS Big Sur (11.x) and when I try to debug I get the 
following error from the debugger:

 

"error: process exited with status -1 (attach failed ((os/kern) invalid 
argument))"}

 

I am running Qt Creator version 4.15 since that seems to be the only viable 
version. I tried version 6.0.2 but the code completion is broken. The engine I 
am assuming is just utterly broken. My source code is filled with error markers 
although the code compiles fine. Which is why I dropped back to the 
tried-and-true version 4.15.


Does anyone else use macOS ARM machines for daily debugging? I was getting 
ready to switch over to an M1 based machine but if I can’t debug that could be 
seen as an “issue”.

 

Thanks

Mike Jackson

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Michael Jackson]

Dear Volker,
I will try to address some points from my own context which is that I've 
been using Qt for our open source cross platform desktop application since 
early Qt4. I've stuck with Qt because of the close to write once (mostly) just 
compile and run everywhere kind of thing. I code all day, try to run my 
company, hire people, manage projects, manage contracts so frankly I don't have 
the time to _learn_ the deep underpinnings of Qt to fix a bug. If it really 
only took an hour or so to fix I might actually consider contributing. And at 
this point since Qt 5.15.2 will not have any more releases there is absolutely 
*no* reason to contribute to Qt.

I think some of the hurdles to putting in bug patches is the following:
* Overly difficult to setup all the needed accounts, git pulls, PRs, Gerrit 
review processes.
* Finding time in my own schedule to match up with time from a Qt engineers 
schedule. 
* My bugs probably may not align with TQtC priorities
* Writing a unit test is always a blast. Again, time waiting for a code review.
* Ensuring it works cross platform when most may not have access to all of the 
needed testing systems.


I agree with the others that the LTS releases need to go out to open source. I 
understand that The Qt Company is a business and needs to earn revenue to pay 
its own engineers. On the flip side though TQtC yanking the licensing rug out 
from underneath my company puts _my_ company at risk. I don't have a solid 
answer for how the licensing should be done, but clearly the current practice 
_isn't_ well received by the Qt community. I don't think the community is 
asking for much to have the 5.15.8 released to OSS.

Respectfully
Michael Jackson
Owner, BlueQuartz Software, LLC

On 2/24/22, 10:39 AM, "Interest on behalf of Volker Hilsheimer" 
 wrote:

Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that 
allows us to put more focus on the desktop, and that we are are able to do more 
than maintenance and catching up with what’s happening on the underlying 
platforms. That includes the journey of making Qt Quick Controls a great 
toolkit for the desktop as well. In Qt 6 so far we have had first 
implementations of the native styles - yes, those require more work; we have 
made a number of improvements to item views, including a TreeView now in Qt 
6.3; a first set of standard dialogs is in Qt 6.2 and more are coming in 6.3. 
We have worked on some architectural issues that are problematic on the 
desktop, such as keyboard navigation and focus handling, and there is a fair 
amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem 
to find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing 
on a Tuesday evening. But given the apparently high interest in this feature, 
that nobody seems to have tried to give it a shot in 12 years is really 
puzzling me. When Nokia acquired Trolltech, it didn’t take a crystal ball to 
see that the focus won’t be the desktop. And one answer to this was to move Qt 
under Open Governance so that anyone could contribute to Qt and make sure that 
it stays awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt 
on the desktop to participate in the discussion. And I suppose most of us on 
this list are software engineers, many perhaps for more reasons than to put 
food on the table. My question to you is: how can we make it easier, or more 
fun, or more motivating to contribute to Qt, and to help with making things 
better?


Volker





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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Michael Jackson]

So I’ll throw my 2 cents worth of experience into the ring. 

 

I’ve developed a desktop application using Qt Widgets since 2009 era. Last year 
we got funding to completely rewrite it from the ground up. We selected QML 
over widgets because we wanted that forced Model-View-Delegate and separation 
of the back end from the front end. QML sure looked promising from the demos. 
The early prototypes were nice. What we got for development is a hot mess. The 
QML debugger is a joke. GammaRay helps here and there trying to figure out what 
rectangles are where. The development time is horribly long. QML itself is just 
a black-magic soup where you never really know when things are getting 
initialized. We were hoping to have a flashy desktop application, all “modern” 
and everything. We are months behind schedule at this point. We spend hours 
messing with QML trying to get it to behave appropriately (sizing, visual 
style) where widgets would have just been “done”. We spent a large chunk of 
cash paying someone to get a TreeView working since Qt5 doesn’t supply one 
(Don’t get me started on that.. ).

 

Had I known back then what I know *now* I would never have selected QML over 
Widgets for Desktop development. In no way is it ready for anything past some 
trivial applications. Not even close. The idea is great. The vision is cool. 
Our development experience has not been a good one.

 

@Mark Gaiser one of our contractors implemented some code up in main.cpp where 
we press “F7” and the app reloads using the QML files from disk. This helps us 
cycle the theme updates and QML updates instead of having to quit and restart 
each time.

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

On 2/21/22, 6:34 PM, "Interest on behalf of Mark Gaiser" 
 wrote:

 

On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner  
wrote:

Hi,

QML is nice for basic applications but widgets is important for professional, 
technical
and high-density applications. 

But that doesn't matter. From my point of view Qt stopped being developed as a 
desktop
framework a long time ago. Other industries seems to have priority now.

 

Well, it was nearly good enough in the Qt5 days with Controls V1.

All they needed was a better set of controls to accommodate mobile more and 
reduce complexity in V1.

 

What they did - conceptually - with V2 was good.

But it seems like they just left it in alpha quality and call it "ok" to 
replace V1.. That was a mistake.

It needed much more development time to be a proper replacement.

 

We're now like ~8 years past the introduction of the V2 set...

And it still has really severe bugs that just interrupt usability. 8 years...

So I doubt it will be getting any better at all.


On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
> Hi,
> 
> I'm facing so many bugs in QML Controls in Qt6 (they used to be Controls V2 
> in the Qt 5.x
> days) that I don't want to use them at all anymore. They are bugged beyond 
> repair and
> downright unusable for native desktop integration purposes.
> 
> Is there another good open source component set out there that integrates 
> with the
> desktop. Specifically with Windows but preferably also with Linux (kde and 
> gnome) and Mac.
> 
> Using QWidgets should not be an alternative as it slows down development a 
> lot. But given
> the crap that QML Controls is makes me consider switching to QWidgets instead.
> 
> 
> Best regards,
> Mark
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards,
Bernhard Lindner

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

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

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

Re: [Interest] Build Issues with QT 6.2.3

[Michael Jackson]

cmake -G "Unix Makefiles"  

--
Mike Jackson 

On 2/6/22, 10:56 AM, "Interest on behalf of Thorsten Glaser" 
 wrote:

On Sun, 6 Feb 2022, BeneschTech LLC wrote:

> issues with third party code. Indulge us old guys though. We have reasons

Fully agreed!

Say, wasn’t there a way to make cmake and/or ninja generate Makefiles?

Once there (in the one project I had to use cmake so far, Android NDK
stuff, it did that) it’s a matter of using make V=1 VERBOSE=1 to run.
(Plus https://issuetracker.google.com/issues/184060944 an Android-speci‐
fic workaround involving a CMakeSettings.json file to be created, but
that’s probably nowhere near necessary for Qt.)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander 
Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

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


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

Re: [Interest] [External]Re: How to get QtConcurrent to do what I want?

[Michael Jackson]

I've gotten a bit lost in these requirements but having written a large piece 
of open source data analysis software (including image processing and tiling of 
data to form and image) there are certain scenarios when processing an image 
that you can share the entire image with *all* of the threads because each 
thread works on its own small part of the image and does NOT care about any 
other region of the image. This is the "embarrassingly parallel" algorithm you 
always hear about.

Like Konstantin suggested get the total number of "CPUs" that you want to use. 
Tell each thread what area it will work on and send the pointer to the image to 
process to each thread. You can work out the user feedback as the threads go 
through each section. We do this all the time in our program (also built with 
Qt5). Just my 2 cents.

Also an alternate suggestion would be to take a look at Threading Building 
Blocks (TBB). It has worked out very nicely for us and is a compliment to 
QThread in certain scenarios. We use both QThread and TBB in our application.

--
Mike Jackson
https://www.github.com/bluequartzsoftware/DREAM3D

On 2/1/22, 10:21 AM, "Interest on behalf of Murphy, Sean" 
 
wrote:

> On Mon, Jan 31, 2022 at 7:15 PM Murphy, Sean 
 wrote:
> >   1. Creating 60,000 QObjects in a single thread appears to be slow  
> [...]
>
> Ehm, maybe I'm not understanding something, but why do you need objects 
to begin with?

I do need to report progress back to the UI and I mistakenly thought I 
needed to have 
each tile inherit from QObject to provide that functionality. After reading 
up a bit more about 
QFuture and QFutureWatcher and then refactoring yesterday to use those 
classes, as of the 
moment, my tile class no longer inherits from anything, and I'm able to use 
signals from 
QFutureWatcher to relay progress back to the UI. 

> The actual loop is this:
>// generate each tile with its assignment
> [snip]
>
> What's the significance of the tiles? As far as I can tell from your 
requirements, you don't care about
> the "true geometry" of the data.

Either I'm understanding what you mean by "true geometry", or this 
assumption is at least partially incorrect. 
Looking back on my list of requirements I've posted, I left off the last 
step: 

  At the end of all this processing, I do need to produce an onscreen image 
to the user. 

So any way I slice up the work that needs to be done using threads, once 
they are all finished, I do need to 
know what chunk of the original image each thread was working on to know 
where place its normalized pixels 
in what I display to the user.

> At least to me it seems you want something like (pseudo algorithm):
>
> 1) Start QThread::idealThreadCount threads (QThread::create<> / 
std::thread)
> 2) Each thread works on "total samples" / QThread::idealThreadCount 
buffers that are completely independent.
> 2.1) Each thread goes through each sample from a partially mapped (from 
the file) buffer, takes the min/max to get the dynamic range
> 2.2) Sync the threads to get the global min/max
> 2.3) Go through each of the buffers a second time to normalize the 
dynamic range (again no tiles involved, just samples)
> 3) Done.

I think this is an preferable approach to what I was attempting, and I'm 
glad you suggested it. This being my first attempt at this, 
I naively started from asking "what seems like it would be a reasonable 
tile size?", arbitrarily thought "256 pixels square" and worked 
backwards from there, which is how I got into this mindset of "I might have 
60,000+ tiles to deal with". Your approach starts from 
what now appears to me a much better thought of "what's the ideal number of 
threads for your machine? Don't bother creating 
more threads than that because you're not going to benefit by having more" 
and then working forward from there.

> Note: As each thread works on its own piece of data in both cases there's 
no sync required at any one point - 
> you just read/write different parts of the same thing. Which is true both 
for when you load/write from/to a file 
> and from/to memory.

Not sure if I quite understand what you meant by this note? There is the 
sync you pointed out as your step 2.2, and then since I need to 
form the results into an onscreen image (most likely a QGraphicsPixmapItem, 
etc.) there's another sync at your step 3 before I can make
the final onscreen image. Otherwise I think I understand and prefer your 
concept to what I was doing.

Thanks again for your help! Now to test this out in practice... 
Sean

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


___
Interest mailing list

[Interest] QML Application shows white screen during dialog window (macOS)

[Michael Jackson]

We are developing a QML desktop application. At one point we show a dialog 
which on macOS slides down from the top of the main window area. When this 
happens the main window area becomes all white, i.e., nothing is rendered. The 
actual dialog box is fine. When the dialog box is dismissed the main window 
generally goes back to a properly rendered window but sometimes I need to 
resize the main window to trigger the refresh. Has anyone else come across 
this? 


We are using the Qt 5.15.2 prebuilt binaries on macOS 10.15.

 

--

Mike Jackson

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

Re: [Interest] Conda packaging of macOS App troubles

[Michael Jackson]

So to answer my own question after a lot of digging and experimenting we had 
set the macOS SDK to 10.14 for our builds. What was needed was to build against 
the 10.13 SDK but use 10.14 for deployment (TBB needed 10.14 minimum). Odd. 

 

--

Mike Jackson

 

On 8/20/21, 2:51 PM, "Michael Jackson"  wrote:

 

Does anyone on this list have any experience packaging a macOS GUI application 
.app package as an Anaconda package? We recently added python wrapping to our 
application and we are trying to create a package for anaconda. For Linux and 
Windows this all works out just fine. For MacOS we get a package created but 
when a user tries to launch the application it will hang at the first point any 
GUI element is shown. We have been comparing our application to something like 
QAssistant or QDesigner that are already packaged and that work just fine but 
just cannot seem to find the difference. We have looked at info.plist, qt.conf, 
linked libraries through ‘otool’ and a few other ideas but cannot seem to 
figure out what the major difference is.


We did make a trivial Qt widgets application that just shows a QPushButton and 
have successfully packaged that into an anaconda package. I’m also not sure if 
this is the best list for this but I thought I would start here…. 

 

--

Mike Jackson

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

[Interest] Conda packaging of macOS App troubles

[Michael Jackson]

Does anyone on this list have any experience packaging a macOS GUI application 
.app package as an Anaconda package? We recently added python wrapping to our 
application and we are trying to create a package for anaconda. For Linux and 
Windows this all works out just fine. For MacOS we get a package created but 
when a user tries to launch the application it will hang at the first point any 
GUI element is shown. We have been comparing our application to something like 
QAssistant or QDesigner that are already packaged and that work just fine but 
just cannot seem to find the difference. We have looked at info.plist, qt.conf, 
linked libraries through ‘otool’ and a few other ideas but cannot seem to 
figure out what the major difference is.


We did make a trivial Qt widgets application that just shows a QPushButton and 
have successfully packaged that into an anaconda package. I’m also not sure if 
this is the best list for this but I thought I would start here…. 

 

--

Mike Jackson

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

Re: [Interest] Qt 5.15, PySide2, QWidgets not refreshing on Change

[Michael Jackson]

<https://bugreports.qt.io/browse/PYSIDE-695> which is marked as a duplicate of 
<https://bugreports.qt.io/browse/QTBUG-68740>

Reproduced on macOS 10.15 with Pipe installed PySide2, i.e, Qt 5.15

The "fix" is to apply some sort of style sheet to the application. So looks 
like the same bug and should be reopened.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 

On 6/30/21, 12:05 PM, "Sérgio Martins"  wrote:

    On 2021-06-30 16:43, Michael Jackson wrote:
> Replying to my own question (actually, not sure my first message made
> it to the list), a helpful colleague found the following:
> 
> 
https://forum.qt.io/topic/98059/push-button-label-settext-not-refreshing-under-macos
> 
> which leads to https://bugreports.qt.io/browse/QTBUG-68740 and
> https://bugreports.qt.io/browse/QTBUG-68521. I have a small test
> project that shows that those bugs are back with Qt 5.15.2 and 5.13.
> 
> Should I reopen the bug(s), start a new bug? I figure there is no hope
> of getting them fixed with the current emphasis on Qt 6 but at least
> if someone else experiences this issue then it might be nice to have
> the issue documented.


Can you reproduce with the oldtestcase attached to QTBUG-68740 ?
If yes then it's the same bug and it should be reopened.

If only your new testcase can repro then it's a new bug. You reference 
the old bug in case there's any good insights.

I would also test with Qt6, as any fix should go there first.



> I was able to reproduce the issue on macOS 10.14 and 10.15 but not
> macOS 11 (Big Sur) and Windows 10. All were running the same conda
> virtual environment. Same in the sense that the same commands were use
> to generate each environment on each respective system.


Regards,
-- 
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts


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

Re: [Interest] Qt 5.15, PySide2, QWidgets not refreshing on Change

[Michael Jackson]

Replying to my own question (actually, not sure my first message made it to the 
list), a helpful colleague found the following:

https://forum.qt.io/topic/98059/push-button-label-settext-not-refreshing-under-macos

which leads to https://bugreports.qt.io/browse/QTBUG-68740 and 
https://bugreports.qt.io/browse/QTBUG-68521. I have a small test project that 
shows that those bugs are back with Qt 5.15.2 and 5.13.

Should I reopen the bug(s), start a new bug? I figure there is no hope of 
getting them fixed with the current emphasis on Qt 6 but at least if someone 
else experiences this issue then it might be nice to have the issue documented. 

I was able to reproduce the issue on macOS 10.14 and 10.15 but not macOS 11 
(Big Sur) and Windows 10. All were running the same conda virtual environment. 
Same in the sense that the same commands were use to generate each environment 
on each respective system.

--
Mike Jackson

On 6/28/21, 8:46 AM, "Michael Jackson"  wrote:

We have developed a small GUI app using Qt 5.15, PySide2, and Widgets. 
There are a few instances when running the application that QLineEdits or 
QListViews are not updating after we update the underlying model or even just 
do a “setText()” (in the case of QLineEdit). If we resize the app window then 
we see the new values. I’ve not seen this behavior before with our C++ Qt apps 
so I’m wondering if we just missed something that needs to be done for PySide2 
apps? Here is our setup.

MacOS 10.15 and MacOS 11.4
Anaconda virtual environment running Python 3.8. Here are the setup 
commands to build the environment.

  conda create -n easybake python=3.8 tqdm requests
  pip install pyside2
  pip install dataclasses-json

The project is located at 
https://www.github.com/bluequartzsoftware/MetaForge

We have resorted to a few "workarounds" such as setting the widget 
visible(fasle), visible(true) after we do the "setText()". Clearly we are just 
missing something simple. I hope.

Thanks for any help/pointers.
--
Michael Jackson



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

Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

[Michael Jackson]

For our application we grabbed the Qt 5.15 build script that Kitware used for 
universal binary CMake and used that to build Qt 5.15.2 on our M1 mac and have 
been using that for some beta testers. So far no one has complained about M1 
specific issues. We also did *NOT* build all of Qt5, just the parts that we 
needed. Build script below.


=
#!/usr/bin/env bash

# Run this script on a macOS x86_64 host to generate Qt universal binaries.
#
# This script requires the 'makeuniversal' tool from:
#
#   https://github.com/fizzyade/makeuniversal
#
# Build it with an existing local Qt installation first.
#
# Set the PATH environment variable to contain the location of 'makeuniversal'.


umask 022

CpuBrand=`sysctl -n machdep.cpu.brand_string | grep "Apple" | wc -l`
if [ ${CpuBrand} != 0 ];
then
  ARCH=arm64
else
  ARCH=x86_64
fi

set -e
set -x

VERSION=5.15.2

DEV_ROOT=$HOME/DREAM3D-Dev

cd $DEV_ROOT
rm -rf qt-$VERSION-$ARCH
mkdir qt-$VERSION-$ARCH
cd qt-$VERSION-$ARCH
../qt-everywhere-src-$VERSION/configure \
  --prefix=/Users/Shared/DREAM3D_SDK/Qt$VERSION/$VERSION/clang_$ARCH \
  --docdir=/Users/Shared/DREAM3D_SDK/Qt$VERSION/Docs/Qt-$VERSION \
  -platform macx-clang \
  -device-option QMAKE_APPLE_DEVICE_ARCHS=$ARCH \
  -device-option QMAKE_MACOSX_DEPLOYMENT_TARGET=10.13 \
  -release \
  -opensource -confirm-license \
  -gui \
  -widgets \
  -no-gif \
  -no-icu \
  -no-pch \
  -no-angle \
  -no-dbus \
  -no-harfbuzz \
  -skip declarative \
  -skip multimedia \
  -skip qtcanvas3d \
  -skip qtcharts \
  -skip qtconnectivity \
  -skip qtdeclarative \
  -skip qtgamepad \
  -skip qtlocation \
  -skip qtmultimedia \
  -skip qtnetworkauth \
  -skip qtpurchasing \
  -skip qtremoteobjects \
  -skip qtscript \
  -skip qtsensors \
  -skip qtserialbus \
  -skip qtserialport \
  -skip qtwebchannel \
  -skip qtwebengine \
  -skip qtwebsockets \
  -skip qtxmlpatterns \
  -nomake examples \
  -nomake tests \
  -make tools

# Need to install the tools BEFORE generating the docs
make -j -k
make install

# Generate the Docs and install them
make docs
make install_docs


--
Mike Jackson


From: Interest  on behalf of Nuno Santos 

Date: Friday, May 7, 2021 at 6:07 AM
To: Tor Arne Vestbø 
Cc: Qt development mailing list , Qt Interest 

Subject: Re: [Interest] [Development] Mac Big Sur - Qt Open-Source Support For

Tor,

What about building Qt 5.15.X for M1 Macs? 

Is there any kind of wiki resource out there?

Regards,

Nuno


On 7 May 2021, at 10:47, Tor Arne Vestbø  wrote:

Qt 6.0 and above has official support for Big Sur:

https://doc.qt.io/archives/qt-6.0/macos.html

5.15 is not yet officially supported, but should work fine as well, so please 
report any issues in JIRA, thanks!

Cheers,
Tor Arne


On 7 May 2021, at 11:00, coroberti  wrote:

Dear Tukka and others,
Since September Big Sur is a reality.

Which Qt-version supports correctly QWidgets for this platform for
open-source development.

If there's no such version, when the support is planned if ever.

I'd appreciate not to hijack this question for any discussions beyond the
very narrow scope of this question.

Thanks,

Kind regards,
Robert
___
Development mailing list
mailto:developm...@qt-project.org
https://lists.qt-project.org/listinfo/development

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

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


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

Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

[Michael Jackson]

Roland,
I'll start off by acknowledging your points, but we will just agree to 
disagree. I acknowledge that you have a *lot* of years making/maintaining 
software for medical devices. But I'm with Hamish on this. I don't understand.

What you are saying is that Qt was designed "perfectly" from day one with no 
extra API, not one bad API implementation and no cruft. Qt should never be 
updated to run on modern compilers against modern C++ specifications. Updated 
to run on modern operating systems. Qt should not explore adding APIs/Toolkits 
to the Qt ecosystem to allow Qt to be used on the billions of devices that we 
use every day. Qt should just stick with its technology from 20 years ago. TQtC 
shouldn't go after paying customers in order to, you know, pay its developers. 
TQtC should rely solely on an industry that, by your own writings, have a 15 
year horizon. Not much of a business case for that. (For the record, I don't 
particularly agree with TQtC current licensing or LTS strategy.)

I also don't understand your argument that you want to update a medical device 
from 20 years ago with the latest and greatest toolkits. I can't imagine 
anything electronic from 20 years ago being able to actually load and run 
anything like Qt? How is the hardware even powerful enough to do this? You 
can't convince me that the medical hardware device manufacturers were thinking 
15 years into the future for the next upgrade, 15 years ago.

50 Year Old equipment. You make the case even more for TQtC to pursue customers 
with a much shorter timeline. If TQtC concentrated on markets with 20-50 year 
timelines for updates how much revenue do you think they would make? Enough to 
sustain Qt development in any real capacity? Doubtful.

Some of us like to create cross platform desktop applications that inspire our 
users to create the next cool thing. For that Qt is just about the only viable 
toolkit out there although others are coming on strong. We would like to see Qt 
keeping up with the latest C++ specs so we can use all the cool new APIs. Both 
our software development worlds are important to each of us. We are almost 
diametrically opposed in what we want from the same toolkit. Neither is 100% 
right and neither is 100% wrong. Only TQtC can decide where to put their 
resources so that they make enough revenue to continue the development of Qt.

I'm not going to comment on the Fortran thing. It isn't relevant to this 
conversation.

Again, this is *not* an endorsement of the current licensing issues with Qt 
5.15 and 6.0. I'm just enough put off to find something else after 15 years of 
using Qt.
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 

On 3/26/21, 9:45 AM, "Interest on behalf of Roland Hughes" 
 
wrote:


On 3/26/21 6:00 AM, Hamish Moffatt wrote:
> I really don't understand your arguments Roland. You say you need Qt
> support for 15 years, but you can't actually change one bit of your
> software without FDA approval, so presumably this means you aren't
> upgrading Qt anyway. Then after 15 years you want to work on a new model
> of the device, starting with your existing code, and you expect it to
> compile with the latest Qt unchanged?

Stable API.

By definition a Stable API only has additions. In incredibly rare 
isolated cases things get deleted ___AFTER__ they have a direct or 
mostly direct replacement.

I was involved in a discussion a couple months ago with someone who just 
that morning cracked open 50 year old FORTRAN that compiled with the 
latest FORTRAN compiler just fine. The code had been running in 
production unchanged for 50 years. That's ordinary in the deep pockets 
world, not an exception, the rule.

> Someone else was talking about support for RHEL 6. Why do you expect to
> use the latest Qt with an ancient OS? Is it reasonable to expect to use
> new Qt with an ancient OS?

Qt actively pursued these markets and then abandoned them. Multi-million 
dollar investments (if I remember what Scott wrote correctly, a billion 
with a B dollar investment) on long term projects. Well, ordinary term 
for our worlds but beyond the Arc of Time for what Qt now pursues. These 
investments got made because the stuff was supposed to be supported for 
the duration.

Our worlds last longer than a gallon of milk and they were actively pursued.

>
> I see that the latest Microsoft Visual C++ compiler toolset (v142)
> doesn't support building for Windows XP. You can still use an older
> compiler. That seems like a reasonable compromise.
>
When you come from a short lived world, that would seem reasonable. We 
walk in worlds where stuff routinely runs 30-50 years. It's a requirement.

The gist of this thread seems to be, from Th

Re: [Interest] The willy-nilly deletion of convenience, methods

[Michael Jackson]

Having read this entire conversation I find it interesting that we as 
developers are complaining about features being deprecated and removed in Qt 
but yet where is the anger when C++ spec removes features? 

 

https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed

 

http://www.cplusplus2017.info/removed-features-from-c17/

 

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed

 

I have also been caught when trying to upgrade some legacy codes that were 
written well over 15 years ago by compiling with a “modern” C++ Compiler. We 
complain when the API gets bloated and slow then we complain when it gets 
trimmed down to be fast again. Pick something. 

 

I’m not disagreeing with the license issue. I’m not disagreeing with the “Qt6 
is a mess”. Just pointing out that even C++ undergoes changes where features 
that people may have used get’s removed.

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

From: Interest  on behalf of Roland Hughes 

Date: Tuesday, March 23, 2021 at 7:02 AM
To: , 
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods

 

 

On 3/23/21 2:31 AM, interest-requ...@qt-project.org wrote:

On 3/22/2021 7:32 PM, Turtle Creek Software wrote:
Re: willy-nilly

I can relate to anyone who is unhappy about deprecated functions.  It is 
never fun when existing code breaks.  We want to be inventing new stuff, 
not going back and fixing old code just to stay in the same place.  The 
C++ language has been decent about advancing, but still keeping ancient 
code stable.  Windows bends over backwards to stay backwards compatible. 
I think it's a basic courtesy that all platforms owe to developers.  
Programming is hard. Doing things once should be enough.
Amen brother, +100.
 
Life's too short for that BS, and computers are supposed to make our 
lives easier in the first place.
 
20 years in the life of a language or API or library is nothing (I'm 
over 50, which gives me some perspective). Assuming anyone actually uses 
it for more than a weather app or media browser. Something like that 
needs to last for as long as anyone uses it, and if it's time for it to 
die or be replaced then let it go in peace instead of gutting it and 
pretending it's still the same animal.  And yes I do think Windows has 
done us a great service in this regard... just talk to any non-fanboy 
MacOS developer who is older than 30.  And on *nix of course everyone 
still uses utilities written before they were born.  Stability, baby.
 
Dear QtC: Just call Qt6 a new library and make it all clean and sexy and 
commercial, or whatever.  But at least do right by everyone who's put 
their time into earlier versions, including by using them, and finish it 
up in style instead of scandal & annoyance. Not only would all the users 
appreciate it, but it just may make you seem more reliable going 
forward.  For me personally 5.12.x is the last Qt branch I will trust 
(until maybe someday all the 5.15 fixes are OS).
+1000

Amen! Can I get a witness?

Welcome to the north of 50 club, not far from the north of 60 club.

The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up 
mentality. Real products have to have 30+ years of stability, not be gutted 
every few years.

For those too young to understand, this is where AGILE and Iterative 
Development fail spectacularly. You are constantly putting out things that 
aren't going to last. By definition unstable.

30 years is __nothing__ for production systems. It is ordinary for a well 
developed system to run 10+ years without any modifications. Yeah, you really 
do need both doc and comments in the code because even if you wrote it, ten 
years later you are a different person.

You can't chase the phone market __and__ serve actual business.

These are diametrically opposed goals.

When a company puts a surgical robot in the field it has to be maintainable for 
at least 20 years. They can't afford a gut & rewrite. Yes, over the course of a 
20+ year life a robot will "get taught new tricks" but those will be additional 
tricks. Even something as "simple" as a patient monitor will have to have minor 
software upgrades due to new FDA/HIPPA regulations.

Here's the 8000 pound Elephant in the room.

Cross platform isn't needed. Ain't nobody going to put Android or Windows 
behind a touch screen on a medical device. That's always going to be a Yocto 
Linux build. The dev host is always going to be a YABU or some other Linux 
distro. Cross platform has very little meaning in the embedded medical, 
industrial controls, test equipment world.

Cross platform had meaning in the desktop world. It's become a limited meaning 
though. Yeah, it's nice that I can run text editor A on Windows, Linux, and 
that obscure platform. The sa

Re: [Interest] Qt Creator is so buggy and so slow...

[Michael Jackson]

On 3/19/21, 1:50 AM, "Interest on behalf of Jason H" 
 wrote:

...
>
> On Thursday, 18 March 2021 10:38:41 PDT Alexander Dyagilev wrote:
> > Hello,
> >
> > Often it just stops to suggest code, syntax highlighted stops w.
>
> I cannot reproduce your problem of open/close/open.

Same problem here. The problem is real. I'm on a 2019 macbook pro.
The key is to just close the file and reopen it, it doesn't take restarting 
the entire IDE. It happens on small files, < 1000 lines of code, not that 
complicated. It's my most frequent problem.

The other anything problem is when the QtCreator pane insists on showsing 
issues for an old version if the file, even though it's been fixed and compiled 
successfully. This one is more rare though.


I just use terminal to "killall clangd" and the file will get reparsed and show 
correctly the issues. 

--
Mike Jackson


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

Re: [Interest] Compiling/Generating the full set of documentation for Qt 5.15.2

[Michael Jackson]

```make install_docs```

--
Mike J
 

On 1/15/21, 3:42 PM, "Michael Jackson"  wrote:

I’m slowly adding in more parts of Qt 5.15.2 so that our developers can 
have a fuller experience with Qt. One place that I am coming up short in the 
documentation area though. After I get Qt compiled, I do a “make docs” and then 
“make install” but when I open QAssistant I don’t get any of the documentation 
showing up that I would normally expect. This is my simple build script on 
macOS 10.15 catalina with Xcode 12.3 installed. Not sure what else is needed to 
help solve the problem.

set -e
set -x

umask 022

ARCH=x86_64
VERSION=5.15.2

DEV_ROOT=$HOME/DREAM3D-Dev

cd $DEV_ROOT
rm -rf qt-$VERSION-$ARCH
mkdir qt-$VERSION-$ARCH
cd qt-$VERSION-$ARCH
../qt-everywhere-src-$VERSION/configure \
  --prefix=/Users/Shared/DREAM3D_SDK/Qt$VERSION/$VERSION/clang_$ARCH \
  -platform macx-clang \
  -device-option QMAKE_APPLE_DEVICE_ARCHS=$ARCH \
  -device-option QMAKE_MACOSX_DEPLOYMENT_TARGET=10.13 \
  -release \
  -opensource -confirm-license \
  -gui \
  -widgets \
  -no-gif \
  -no-icu \
  -no-pch \
  -no-angle \
  -no-dbus \
  -no-harfbuzz \
  -skip declarative \
  -skip multimedia \
  -skip qtcanvas3d \
  -skip qtcharts \
  -skip qtconnectivity \
  -skip qtdeclarative \
  -skip qtgamepad \
  -skip qtlocation \
  -skip qtmultimedia \
  -skip qtnetworkauth \
  -skip qtpurchasing \
  -skip qtremoteobjects \
  -skip qtscript \
  -skip qtsensors \
  -skip qtserialbus \
  -skip qtserialport \
  -skip qtwebchannel \
  -skip qtwebengine \
  -skip qtwebsockets \
  -skip qtxmlpatterns \
  -nomake examples \
  -nomake tests \
  -make tools

make -j -k
make docs
make install

    --
    Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net





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

[Interest] Compiling/Generating the full set of documentation for Qt 5.15.2

[Michael Jackson]

I’m slowly adding in more parts of Qt 5.15.2 so that our developers can have a 
fuller experience with Qt. One place that I am coming up short in the 
documentation area though. After I get Qt compiled, I do a “make docs” and then 
“make install” but when I open QAssistant I don’t get any of the documentation 
showing up that I would normally expect. This is my simple build script on 
macOS 10.15 catalina with Xcode 12.3 installed. Not sure what else is needed to 
help solve the problem.

set -e
set -x

umask 022

ARCH=x86_64
VERSION=5.15.2

DEV_ROOT=$HOME/DREAM3D-Dev

cd $DEV_ROOT
rm -rf qt-$VERSION-$ARCH
mkdir qt-$VERSION-$ARCH
cd qt-$VERSION-$ARCH
../qt-everywhere-src-$VERSION/configure \
  --prefix=/Users/Shared/DREAM3D_SDK/Qt$VERSION/$VERSION/clang_$ARCH \
  -platform macx-clang \
  -device-option QMAKE_APPLE_DEVICE_ARCHS=$ARCH \
  -device-option QMAKE_MACOSX_DEPLOYMENT_TARGET=10.13 \
  -release \
  -opensource -confirm-license \
  -gui \
  -widgets \
  -no-gif \
  -no-icu \
  -no-pch \
  -no-angle \
  -no-dbus \
  -no-harfbuzz \
  -skip declarative \
  -skip multimedia \
  -skip qtcanvas3d \
  -skip qtcharts \
  -skip qtconnectivity \
  -skip qtdeclarative \
  -skip qtgamepad \
  -skip qtlocation \
  -skip qtmultimedia \
  -skip qtnetworkauth \
  -skip qtpurchasing \
  -skip qtremoteobjects \
  -skip qtscript \
  -skip qtsensors \
  -skip qtserialbus \
  -skip qtserialport \
  -skip qtwebchannel \
  -skip qtwebengine \
  -skip qtwebsockets \
  -skip qtxmlpatterns \
  -nomake examples \
  -nomake tests \
  -make tools

make -j -k
make docs
make install

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 


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

Re: [Interest] Compiling Qt5 (any version past 5.99) for Apple Silicon/M1

[Michael Jackson]

I asked on the CMake list as CMake 3.19.3 is universal binary and the GUI is 
based on Qt5. They replied back with this link:

 

https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.3/Utilities/Release/macos/qt-5.15.2-macosx10.13-x86_64-arm64.bash

 

NOTE: this is a fairly limited build which works for the CMake project. This is 
NOT a full Qt 5.15.2 build but should get you started. It worked to get our 
project built because our project has about the same dependencies as CMake Gui. 
I would like to get QtDesigner built as we need that for our own development. 
QtCreator is next on the list but might prove a bit more time consuming as most 
of Qt will need to be built for that.

 

One thing that I noticed when using VS Code’s built in terminal is that all of 
my projects would build as x86_64 instead of arm64 by default. This is most 
likely a side effect of VS Code running in Rosetta currently. Last note was 
that the 13” MacBook Pro compiled this limited version of Qt 5.15 faster than 
my 2019 top of the line 16” Mac Book Pro and still had 95% of the battery 
remaining… 

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

From: Interest  on behalf of Hamish Moffatt 

Organization: Rising Software Australia Pty Ltd
Date: Wednesday, January 13, 2021 at 5:11 PM
To: 
Subject: Re: [Interest] Compiling Qt5 (any version past 5.99) for Apple 
Silicon/M1

 

On 14/1/21 6:28 am, Michael Jackson wrote:

Has anybody successfully compiled any version of Qt5 as a native arm64 set of 
frameworks on a MacOS M1 machine yet? If so could you share your configure 
command.

 

https://bugreports.qt.io/browse/QTBUG-85279

 

 

Hamish

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

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

[Interest] Compiling Qt5 (any version past 5.99) for Apple Silicon/M1

[Michael Jackson]

Has anybody successfully compiled any version of Qt5 as a native arm64 set of 
frameworks on a MacOS M1 machine yet? If so could you share your configure 
command.

 

Thanks.

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

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

Re: [Interest] Mac debugger always hangs

[Michael Jackson]

I am on a hand built QtCreator 4.14 from Git Hash: c650c9473d

 

cmake build: Don't install highlighting files when using system lib

Eike Ziller   

Dec 18, 2020 at 11:13 AM

 

I have not tried updating QtCreator in a while. I think the LLVM requirements 
changed at some point, and I’m happy with my build at this point.

 

--

Mike Jackson

 

From: "David M. Cotter" 
Date: Monday, January 11, 2021 at 11:41 AM
To: Michael Jackson 
Cc: Interest 
Subject: Re: [Interest] Mac debugger always hangs

 

No, I am on the same exact Xcode. The problem happened when I updated QT 
creator. What I did was downgrade QT creator to 4.13, and now it works. So the 
problem is with 4.14.

-dave




On Jan 11, 2021, at 6:24 AM, Michael Jackson  
wrote:



Have you recently updated your version of Xcode? I had this issue after I 
updated Xcode to 12.3. I ended up having to reconfigure and recompile my 
project and debugging now seems to work. I also compile my own QtCreator so I’m 
not really sure which version I am on but it is in the 4.14 range. And I did 
have the same LLDB hang issue when I switched back to 3.13 (Official Version). 
I rolled back versions of Xcode to 12.1/.2 and still had the hangs. That is 
when I decided to just reconfigure and recompile from scratch our own project. 
Maybe this helps, maybe not.

 

--

Mike Jackson

 

From: Interest  on behalf of "David M. Cotter" 

Date: Sunday, January 10, 2021 at 12:23 PM
To: Interest 
Subject: Re: [Interest] Mac debugger always hangs

 

can anyone experiencing this (or at least feeling my pain) please upvote this 
bug so it is prioritized?

 

how to upvote: click the above link, log in (or create an account) if you 
haven't already, then click "vote for this issue", like this:

 







Yes - I have roughly the same setup and it started recently as well. I have to 
restart Qt Creator when this happens.

 

The solution from StackOverflow (turn off "Show QObject names if available") 
seems to help at least some of the time (but I haven't needed to debug that 
much recently).

 

   https://stackoverflow.com/a/49428585/3601811

 

So it's not just you...

 

 

 

On Sat, Jan 9, 2021 at 2:24 AM David M. Cotter  wrote:

Does anybody else experienced this? Please take a look at this forum post:

https://forum.qt.io/topic/122518/debugger-hangs-on-macos/2


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

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

Re: [Interest] Mac debugger always hangs

[Michael Jackson]

Have you recently updated your version of Xcode? I had this issue after I 
updated Xcode to 12.3. I ended up having to reconfigure and recompile my 
project and debugging now seems to work. I also compile my own QtCreator so I’m 
not really sure which version I am on but it is in the 4.14 range. And I did 
have the same LLDB hang issue when I switched back to 3.13 (Official Version). 
I rolled back versions of Xcode to 12.1/.2 and still had the hangs. That is 
when I decided to just reconfigure and recompile from scratch our own project. 
Maybe this helps, maybe not.

 

--

Mike Jackson

 

From: Interest  on behalf of "David M. Cotter" 

Date: Sunday, January 10, 2021 at 12:23 PM
To: Interest 
Subject: Re: [Interest] Mac debugger always hangs

 

can anyone experiencing this (or at least feeling my pain) please upvote this 
bug so it is prioritized?

 

how to upvote: click the above link, log in (or create an account) if you 
haven't already, then click "vote for this issue", like this:

 




Yes - I have roughly the same setup and it started recently as well. I have to 
restart Qt Creator when this happens.

 

The solution from StackOverflow (turn off "Show QObject names if available") 
seems to help at least some of the time (but I haven't needed to debug that 
much recently).

 

   https://stackoverflow.com/a/49428585/3601811

 

So it's not just you...

 

 

 

On Sat, Jan 9, 2021 at 2:24 AM David M. Cotter  wrote:

Does anybody else experienced this? Please take a look at this forum post:

https://forum.qt.io/topic/122518/debugger-hangs-on-macos/2


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

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

Re: [Interest] Qt 5.15 pull out of open source?!

[Michael Jackson]

Dear Tuukka, 

As an open source developer who has used Qt since 2009, I am still a bit 
confused as to what versions of Qt6 that my open-source project should be using 
over time? For example, we might be lucky enough to port to the 6.0 release, 
and then to 6.1. If 6.2 is LTS and commercial only, what is the next Qt 6 
version that an open-source project would jump to? Would that be 6.3? Is TQtC 
going to do something like the “odd (6.1, 6.3…)” releases are opensource but 
the “even (62, 6.4…)” releases are commercial only? Is there a longer term 
roadmap available that explains TQtC vision on how this will work?

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

From: Interest  on behalf of Tuukka Turunen 

Date: Thursday, January 7, 2021 at 4:38 AM
To: Giuseppe D'Angelo , "interest@qt-project.org" 

Subject: Re: [Interest] Qt 5.15 pull out of open source?!

 

Hi,

 

Apologies for not sending the mail also to the interest mailing list. This is 
nothing new, as this was announced in already February 2020. Otherwise Qt 
continues to be available for open-source users, but the long-term support 
releases of Qt will be available only for the commercial license holders. First 
commercial-only patch release being Qt 5.15.3 planned to be released in 
February 2021. 

 

Qt 5.15.2 continues to be available for all users, so situation is similar as 
with Qt 5.13 and Qt 5.14, for example (no new patch releases). Qt 6.0.0 and 
subsequent patch releases, as well as upcoming Qt 6.1 and Qt 6.2 etc releases 
are also available for open-source users. Eventually we will enter 
long-term-support phase with Qt 6.2 LTS at which point again these are only for 
commercial license holders, but all releases done until that point continue to 
be available for all users. 

 

Yours,

 

Tuukka

 

 

 

From: Interest 
Date: Thursday, 7. January 2021 at 10.45
To: interest@qt-project.org 
Subject: Re: [Interest] Qt 5.15 pull out of open source?!

Hi,

Il 07/01/21 04:03, Jérôme Godbout ha scritto:
> Hi,
> is this any true?
> https://www.phoronix.com/scan.php?page=news_item=Qt-5.15-LTS-Commercial-Phase

Please see the thread on development@ (no idea why the original message 
was not posted on interest@ as well.).

> https://lists.qt-project.org/pipermail/development/2021-January/040798.html


HTH,

-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

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

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

Re: [Interest] Debugging a double dealloc

[Michael Jackson]

AddressSanitizer. (Except on macOS it will not find memory leaks) You should be 
able to find the double free quite quickly. You do NOT Have to rebuild Qt with 
the address sanitizer flags, just your own codes. We just got done using ASAN 
on our own code base and it was able to pinpoint the same kind of issue. The 
issue was in our code but it didn't die until deep inside of Qt code which was 
never helpful. I'm 100% behind ASAN as an excellent code quality tool. We now 
have a nightly CI build with ASAN running to help find new codes that might 
have the same issues as before.

--
Mike Jackson 

On 9/23/20, 8:56 AM, "Interest on behalf of Ben Haller via Interest" 
 wrote:

Thanks Giuseppe; this looks very interesting.  I’d love to be able to run 
Valgrind.

Thanks also to Mitch; I see your email now, and it also looks very useful.  
To avoid spamming the list with thank-yous, I’ll just say in advance, thanks to 
all others who might respond with helpful suggestions.  :->

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 8:41 AM, Giuseppe D'Angelo via Interest 
 wrote:
> 
> Il 23/09/20 14:08, Ben Haller via Interest ha scritto:
>> Thanks for the suggestion.  However, this problem is only on macOS, and 
Valgrind doesn’t appear to run on any macOS later than 10.12 (“preliminary” 
support for 10.13, according to their website; I’m not sure what that means).  
I’m on macOS 10.15.6, and I’m using Qt 5.14.2 which has a minimum macOS version 
of 10.13, so Valgrind seems to be a no-go for at least one reason, perhaps two 
reasons (depending on “preliminary”).
> 
> There is a fork of Valgrind to support more modern macOS versions
> 
> https://github.com/LouisBrunner/valgrind-macos/
> 
> (Note: never used it myself, not a mac user).
> 
> Another option is getting a recent Clang version and rebuilding Qt and 
your app with AddressSanitizer.
> 
> HTH,
> 
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

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


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

Re: [Interest] Qt Creator debugger does not flush "Application Output"on every log call?

[Michael Jackson]

Yes to all

 

--

Mike Jackson 

 

From: Interest  on behalf of "David M. Cotter" 

Date: Sunday, September 20, 2020 at 4:13 PM
To: Qt Interest 
Subject: [Interest] Qt Creator debugger does not flush "Application Output"on 
every log call?

 

Do you develop on mac?

Do you print stuff to console (qDebug) to aid with debugging?

When you hit a breakpoint, do you find that, quite often, your log hasn't been 
flushed? ie: you can't see the latest logging, the "Application Output" is 
stuck somewhere in the past...

Does this happen to you? Seems like a bug.

If this drives you nuts, please upvote this bug i've filed. Thanks.

 

-dave

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

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

Re: [Interest] Crashing in qMetaTypeCustomType_unlocked

[Michael Jackson]

Just to bring this back to life (as we still have not been able to
track down the culprit)

#0  0x7f162f9b0aa8 in qMetaTypeCustomType_unlocked(char const*,
int, int*) [clone .constprop.878] () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#1  0x7f162f9b15f7 in qMetaTypeTypeInternal(char const*) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#2  0x7f162f9a80de in
QMetaObjectPrivate::decodeMethodSignature(char const*,
QVarLengthArray&) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#3  0x7f162f9ae748 in QMetaObject::indexOfMethod(char const*)
const () from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#4  0x7f1629d03fda in QDBusConnectionPrivate::findSlot(QObject*,
QByteArray const&, QVector&) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#5  0x7f1629d047a0 in
QDBusConnectionPrivate::prepareHook(QDBusConnectionPrivate::SignalHook&,
QString&, QString const&, QString const&, QString const&, QString
const&, QStringList const&, QObject*, char const*, int, bool) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#6  0x7f1629d050f1 in
QDBusConnectionPrivate::disconnectRelay(QString const&, QString
const&, QString const&, QDBusAbstractInterface*, QMetaMethod const&)
()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#7  0x7f1629d1685f in
QDBusAbstractInterfacePrivate::finishDisconnectNotify(QDBusAbstractInterface*,
int) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#8  0x7f162f9cad61 in QObject::event(QEvent*) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#9  0x7f162f99e333 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#10 0x7f162f9a0de7 in
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
() from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#11 0x7f162f9f6123 in postEventSourceDispatch(_GSource*, int
(*)(void*), void*) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#12 0x7f162ae70417 in g_main_context_dispatch () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f162ae70650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f162ae706dc in g_main_context_iteration () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7f162f9f575f in
QEventDispatcherGlib::processEvents(QFlags)
() from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#16 0x7f162f99cc0a in
QEventLoop::exec(QFlags) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#17 0x7f162f7cdb6c in QThread::exec() () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#18 0x7f162f7cf0a3 in QThreadPrivate::start(void*) () from
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#19 0x7f162d9996db in start_thread (arg=0x7f162a9a9700) at
pthread_create.c:463
#20 0x7f162eeb888f in gnu_dev_makedev (__major=,
__minor=) at makedev.c:30
#21 0x in ?? ()

That is the latest backtrace from a core dump. The Qt Libraries are
the Release versions so there are no symbols to get values for
unfortunately.

We have tried moving the plugins/bearer to the side but still get a crash.

Any more thoughts?
_____
Mike Jackson

On Mon, Jun 22, 2020 at 1:43 PM Michael Jackson
 wrote:
>
> On 6/22/20, 1:20 PM, "Interest on behalf of Thiago Macieira" 
>  
> wrote:
>
> On Monday, 22 June 2020 09:50:20 PDT Michael Jackson wrote:
> > We are currently experiencing some intermittent crashing in our 
> program. The
> > stacktrace is below. The code was compiled in "Release" mode. This is 
> on an
> > Ubuntu 18.04 (with all updates) and using GCC 8.4.0
> > (https://my.cdash.org/buildSummary.php?buildid=1843613). We use the
> > prebuilt Qt 5.12.8 from the downloads.qt.io website. We are trying to
> > reproduce the bug in a Debug build but no luck so far.
> >
> > I've never really had an issue like this and so I'm just looking for 
> ideas
> > on what it might be? Also note that we build nightly on macOS and 
> Windows
> > and those builds do not have any issues. Most use the same version of Qt
> > 5.12.
>
> Because those are probably not using D-Bus for anything. This is also 
> showing
> "plugins/bearer/../.." which is really weird. I've never seen this show 
> up. I
> don't know if we can attribute this to the NetworkManager bearer plugin 
> (which
> does use D-Bus) or if this is just a red herring.
>
> 

Re: [Interest] Crashing in qMetaTypeCustomType_unlocked

[Michael Jackson]

Could this also be a miss-use of QCoreApplication? We create one but don't 
actually call exec() on it? The source code is at < 
https://github.com/BlueQuartzSoftware/SIMPL/blob/develop/Source/PipelineRunner/PipelineRunner.cpp>

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 

On 6/22/20, 1:20 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 22 June 2020 09:50:20 PDT Michael Jackson wrote:
> We are currently experiencing some intermittent crashing in our program. 
The
> stacktrace is below. The code was compiled in "Release" mode. This is on 
an
> Ubuntu 18.04 (with all updates) and using GCC 8.4.0
> (https://my.cdash.org/buildSummary.php?buildid=1843613). We use the
> prebuilt Qt 5.12.8 from the downloads.qt.io website. We are trying to
> reproduce the bug in a Debug build but no luck so far.
> 
> I've never really had an issue like this and so I'm just looking for ideas
> on what it might be? Also note that we build nightly on macOS and Windows
> and those builds do not have any issues. Most use the same version of Qt
> 5.12.

Because those are probably not using D-Bus for anything. This is also 
showing 
"plugins/bearer/../.." which is really weird. I've never seen this show up. 
I 
don't know if we can attribute this to the NetworkManager bearer plugin 
(which 
does use D-Bus) or if this is just a red herring.

But there's a simple way to test: can you delete the NM plugin and see if 
the 
problem goes away?
 plugins/bearer/*

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



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


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

Re: [Interest] Crashing in qMetaTypeCustomType_unlocked

[Michael Jackson]

On 6/22/20, 1:20 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Monday, 22 June 2020 09:50:20 PDT Michael Jackson wrote:
> We are currently experiencing some intermittent crashing in our program. 
The
> stacktrace is below. The code was compiled in "Release" mode. This is on 
an
> Ubuntu 18.04 (with all updates) and using GCC 8.4.0
> (https://my.cdash.org/buildSummary.php?buildid=1843613). We use the
> prebuilt Qt 5.12.8 from the downloads.qt.io website. We are trying to
> reproduce the bug in a Debug build but no luck so far.
> 
> I've never really had an issue like this and so I'm just looking for ideas
> on what it might be? Also note that we build nightly on macOS and Windows
> and those builds do not have any issues. Most use the same version of Qt
> 5.12.

Because those are probably not using D-Bus for anything. This is also 
showing 
"plugins/bearer/../.." which is really weird. I've never seen this show up. 
I 
don't know if we can attribute this to the NetworkManager bearer plugin 
(which 
does use D-Bus) or if this is just a red herring.

But there's a simple way to test: can you delete the NM plugin and see if 
the 
problem goes away?
 plugins/bearer/*

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


Thank you for the suggestion. I did the following (Hoping I interpreted your 
instructions correctly)

$ cd /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer
$ mv libqnmbearer.so bak_libqnmbearer.so.bak

Kicked off a new build. Results will be at 
<https://dev.azure.com/BlueQuartzSoftware/DREAM3D/_build/results?buildId=279=logs=1ee29c43-a44e-5e49-79a9-6f3da8136d88>.

--
Michael Jackson 
BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 



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

[Interest] Crashing in qMetaTypeCustomType_unlocked

[Michael Jackson]

We are currently experiencing some intermittent crashing in our program. The 
stacktrace is below. The code was compiled in "Release" mode. This is on an 
Ubuntu 18.04 (with all updates) and using GCC 8.4.0 
(https://my.cdash.org/buildSummary.php?buildid=1843613). We use the prebuilt Qt 
5.12.8 from the downloads.qt.io website. We are trying to reproduce the bug in 
a Debug build but no luck so far.

I've never really had an issue like this and so I'm just looking for ideas on 
what it might be? Also note that we build nightly on macOS and Windows and 
those builds do not have any issues. Most use the same version of Qt 5.12.

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./PipelineRunner --pipeline 
/opt/Dashboards/DREAM3D/Support/PrebuiltPipelines/W'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f5c82cf1aa8 in qMetaTypeCustomType_unlocked(char const*, int, int*) 
[clone .constprop.878] ()
   from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
[Current thread is 1 (Thread 0x7f5c7dd1f700 (LWP 14150))]
(gdb) bt
#0  0x7f5c82cf1aa8 in qMetaTypeCustomType_unlocked(char const*, int, int*) 
[clone .constprop.878] ()
   from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#1  0x7f5c82cf2136 in int qMetaTypeTypeImpl(char const*, int) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#2  0x7f5c7d0b3271 in qDBusParametersForMethod(QList const&, 
QVector&, QString&) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#3  0x7f5c7d0b3859 in qDBusParametersForMethod(QMetaMethod const&, 
QVector&, QString&) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#4  0x7f5c7d07a021 in QDBusConnectionPrivate::findSlot(QObject*, QByteArray 
const&, QVector&) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#5  0x7f5c7d07a7a0 in 
QDBusConnectionPrivate::prepareHook(QDBusConnectionPrivate::SignalHook&, 
QString&, QString const&, QString const&, QString const&, QString const&, 
QStringList const&, QObject*, char const*, int, bool) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#6  0x7f5c7d07b0f1 in QDBusConnectionPrivate::disconnectRelay(QString 
const&, QString const&, QString const&, QDBusAbstractInterface*, QMetaMethod 
const&) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#7  0x7f5c7d08c85f in 
QDBusAbstractInterfacePrivate::finishDisconnectNotify(QDBusAbstractInterface*, 
int) ()
   from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
#8  0x7f5c82d0bd61 in QObject::event(QEvent*) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#9  0x7f5c82cdf333 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#10 0x7f5c82ce1de7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) ()
   from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#11 0x7f5c82d37123 in postEventSourceDispatch(_GSource*, int (*)(void*), 
void*) () from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#12 0x7f5c7e1e6417 in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f5c7e1e6650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f5c7e1e66dc in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7f5c82d3675f in 
QEventDispatcherGlib::processEvents(QFlags) ()
   from /opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#16 0x7f5c82cddc0a in 
QEventLoop::exec(QFlags) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#17 0x7f5c82b0eb6c in QThread::exec() () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#18 0x7f5c82b100a3 in QThreadPrivate::start(void*) () from 
/opt/DREAM3D_SDK/Qt5.12.8/5.12.8/gcc_64/lib/libQt5Core.so.5
#19 0x7f5c80d0f6db in start_thread (arg=0x7f5c7dd1f700) at 
pthread_create.c:463
#20 0x00007f5c821f988f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 


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

Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6

[Michael Jackson]

On 6/11/20, 12:46 PM, "Interest on behalf of Frederik Schwarzer" 
 wrote:
Am 11.06.2020 18:36 schrieb Christoph Cullmann:
> On 2020-06-11 18:06, Frederik Schwarzer wrote:
>> Am 11.06.2020 17:32 schrieb Christoph Cullmann:
>> 
>> Hi,
>> 
>> 
>>> I think a lot of developers/companies will have pain because of this,
>>> if they have
>>> 
>>> 1) some large customers staying on Windows 7 until really EOL for 
>>> them
>> 
>> Not really an opinion about this but this changelog entry from a
>> release two weeks ago came to mind.
>> "Updated the included Qt library to version 4.8.7." ;) ... And
>> that company has a big market share.
>> 
>> In the industry lots of companies lag behind ... a ... bit. But I
>> would suspect those who lag behind with their Windows version to also
>> do not mind lagging behind with their Qt versions.
>> And since Qt 5.15 will be supported for quite some time ... But as I
>> said, I am not in favor of or against one or another.
>> 
>> Do you have a customer who actually runs on Windows 7 and is otherwise
>> eager to jump on Qt6 in its early releases? I mean, maintaining old
>> Windows versions will double in price every year now, so there's some
>> pressure at least.
> 
> I think there is a misunderstanding: The customer will get some 
> software to
> use, they don't care if it uses internally Qt X.Y or whatever.

Yep, indeed. I had a different view on the "customer" thing because for 
us, the customers mostly deliver the software. :)

I get your point now.

Cheers
Frederik


Windows 7 is EOL. Period. If it costs you, as a developer, additional money to 
support an EOL'ed, unsupported version of an operating system then you will 
need to pass that onto the customer. By still supporting Windows 7 we, as 
developers, are just enabling those customers to keep from updating. There are 
very few real reasons *not* to update to at least Windows 8. At some point the 
customer needs to understand that they are not going to get any new features. 
They current piece of software will keep working (Assuming a perpetual license) 
but nothing new will be supported. I've had requests to back port our software 
to CentOS 6 and once you explain the cost to them for us to maintain all the 
extra development hardware, extra engineering to develop codes that are not 
supported on the old compilers, it becomes cost prohibitive to maintain those 
versions.

+1 to remove Windows 7 support.
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 




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

Re: [Interest] OSX codesign question

[Michael Jackson]

The application is trying to load the Qt frameworks that are *outside* of the 
.app package. If you do an “otool -L” on the actual executable within the .app 
package (SoundJack.app/Contents/MacOS/SoundJack), all non-system dependencies 
that get listed should start with @rpath/something. If you see *any* kind of 
absolution path in there such as 
/Users/soulalex/Qt/5.12.0/clang_64/lib/QtMultimediaWidgets.framework/Versions/5/QtMultimediaWidgets
 then the .app package has not been properly “fixed up” to create a portable 
.app package.

 

A quick way to verify if you have at least packaged SOundJack correctly is to 
run the macdeployqt application. Now before you start the application rename 
/Users/soulalex/Qt/5.12.0 to /Users/soulalex/Qt/5.12.0.bak and then start the 
application. If it starts OK then you are good, if you get a crash because the 
Qt libraries could not be found then something went wrong. If you are using 
CMake by chance then you can try using the “BundleUtilties” to “fix up” the 
.app package. For our application we ended up doing a combination of 
BundleUtilities and our own custom shell script.

 

 

--

Michael Jackson | Owner, President

  BlueQuartz Software, LLC

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

From: Interest  on behalf of Alexander Carôt 

Date: Wednesday, April 8, 2020 at 12:29 PM
To: Andy 
Cc: qt qt 
Subject: Re: [Interest] OSX codesign question

 

Hej Nuno and Andy,

 

thanks a lot - yes, it is confusing but you helped to achieve progress, 
however, some probably last issue to be solved:

 

What works is this:

 

soulalex@alexandarotsMBP SJC % codesign --deep --force --verify --verbose 
--timestamp --options runtime --sign "52EF48168234769E0FE34C92B157ED7200626FD7" 
./soundjack.app r

./soundjack.app: signed app bundle with Mach-O thin (x86_64) 
[com.yourcompany.soundjack]

soulalex@alexandarotsMBP SJC % codesign --verify --deep --strict --verbose=2 
./soundjack.app 

./soundjack.app: valid on disk

./soundjack.app: satisfies its Designated Requirement

 

So - this seems to be fine - otherwise please complain :-)

 

Now comes the problem:

When I execute the app now it tells me:

 

soulalex@alexandarotsMBP SJC % ./soundjackMac.sh
dyld: Library not loaded: 
@rpath/QtMultimediaWidgets.framework/Versions/5/QtMultimediaWidgets
  Referenced from: 
/Users/soulalex/Desktop/wip/XP-shared/Soundjack/SJC/./soundjack.app/Contents/MacOS/soundjack
  Reason: no suitable image found.  Did find:

/Users/soulalex/Qt/5.12.0/clang_64/lib/QtMultimediaWidgets.framework/Versions/5/QtMultimediaWidgets:
 code signature in 
(/Users/soulalex/Qt/5.12.0/clang_64/lib/QtMultimediaWidgets.framework/Versions/5/QtMultimediaWidgets)
 not valid for use in process using Library Validation: mapped file has no 
cdhash, completely unsigned? Code has to be at least ad-hoc signed.

 

Without signation the code executes just fine.

 

Any idea what to do next ?

 

Thanks a lot in advance again,

best

 

Alex

 

 

 

--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797

  

  

Gesendet: Mittwoch, 08. April 2020 um 14:16 Uhr
Von: "Andy" 
An: "Alexander Carôt" 
Cc: "Nuno Santos" , "qt qt" 
Betreff: Re: [Interest] OSX codesign question

The certificate needs to be added to your Keychain, then you use the name for 
it in the codesign command. I think if you double-click the cert in the Finder 
it will add it to "My Certificates" properly.

 

As Nuno pointed out, the name should look like this:

 

"Developer ID Application: ACME_INC (TEAM_IDENTIFER) )”

 

Where ACME_INC is the name of the organization you registered with Apple, and 
TEAM_IDENTIFER is a random string.

 

When generating a cert on the Apple site there are a few choices that sound 
similar - frankly the whole process is confusing - but the cert must must read 
"Developer ID Application" to do what you want.

 

---
Andy Maloney  //  https://asmaloney.com 

twitter ~ @asmaloney

  

On Wed, Apr 8, 2020 at 4:08 AM Alexander Carôt  wrote:

Hi Andy and Nuno,

 

thanks for your answers - looks like being on a good track now.

 

I think the very last problem for me to fix is choosing the correct file - so 
far I have used the certificate I downloaded from the developer account like 
this:

 

codesign --deep ./myApp -s development.cer

 

but this give me:

 

development.cer: no identity found

 

Do you know how to fix this ? Do I probably use the wrong file or is there 
anything else to be changed ?

 

Thanks again,

best

 

Alex

 

-- 

http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797

 

 

Von: Andy 
Datum: Montag, 6. April 2020 um 13:34
An: Nuno Santos 
Cc: Alexander Carôt , qt qt 
Betreff: Re: [Interest] OSX codesign question

 

I just did this yesterday. I could not get macdeployqt to work either, so I do 
it using the command line in my build process.

 

Here's the command l

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Michael Jackson]

Dear Tuukka,
   Let us take a concrete example of a hypothetical company. The company has 10 
software engineers and 2 projects.

Engineers 1,2,3,4,5 work on proprietary project A that uses Qt commercial 
license. Each engineer (1,2,3,4,5) has a commercial Qt license assigned to that 
engineer. They use QtCreator from the commercial package to develop such a 
software. The proprietary software being developed is for a Desktop application 
and uses Qt5 as part of its development.

Now, Engineers 6,7,8,9,10 all work on an open source project B that does not 
use Qt libraries at all. Those engineers (6,7,8,9,10) all really like QtCreator 
and want to use it to develop that open source library. I, as the company 
owner, instruct those engineers to download the open source version of 
QtCreator and use that open source version of QtCreator to develop their open 
source software.

There is *no* cross over between the 2 engineering groups.

Is this situation allowed by the Qt Commercial license? If it is *not* allowed 
consider me a lost supporter of Qt anything.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 


On 3/30/20, 1:54 PM, "Tuukka Turunen"  wrote:

Hi Michael,

Please read the commercial license agreement and the licensing FAQ. The 
restriction has nothing to do with open-source licensing. It is about a 
company, who is using a commercially licensed Qt not to use parts of the same 
licensed Qt product under open-source license. If there was no such 
restriction, a company could have a team of 10 developers, but only 1 or 2 
commercial license for Qt.

I do understand that it can feel off to have such a restriction for using 
"Qt Creator" when others are using "Qt libraries". The important point is that 
both these are included in the Qt for Application Development product. So both 
need to be used with same type of license: open-source or commercial. 
 
Yours,
 
Tuukka

On 27.3.2020, 20.54, "Interest on behalf of Michael Jackson" 
 
wrote:

OK, Here goes the explanations of how to interoperate with Qt Software 
packages. IANAL. We will start from the easy and work our way towards difficult.

QtCreator: QtCreator is free. You, as a developer of software, can use 
QtCreator as your IDE to develop your own software. The GPL license of 
QtCreator will NOT infect your software. Use QtCreator to create open or closed 
software. Free or commercial. Your choice.

QtCreator as Part of a Commercial Qt License: The only thing this gets 
you is the ability to get some "commercial" support versus just posting on the 
qt-creator mailing list.

Modifying QtCreator: If you are actually modifying QtCreator yourself 
to create a distribution outside of your organization then ANY codes you write 
or modify are subject to the QtCreator license. This has ramifications if you 
happen to have a Qt commercial license.

Using Qt5 in your software project: If you use Qt in your project 
ANYBODY contributing to that same project MUST have the same kind of Qt 
license. Period. Full Stop.

For the original question;
"Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?"

The answer is YES, but the devil is in the details. They *should* be 
able to just download the free version of QtCreator from http://download.qt.io 
and use that version. They can't use the "commercial" version of QtCreator 
unless they have a commercial license for Qt. But if their projects are *not* 
using Qt, then why do they have a commercial license for Qt?


Again, IANAL, but I believe this to be a reasonable summary of the 
licensing of QtCreator and Qt.
--
Mike Jackson 



On 3/27/20, 12:21 PM, "Interest on behalf of alexander golks" 
 wrote:

Am Fri, 27 Mar 2020 17:11:16 +0100
schrieb Jean-Michaël Celerier :

> It is also the license of the binaries that you can download 
there :
> https://download.qt.io/official_releases/qtcreator/4.11/4.11.1/
> 
> And it states quite succintly :
> "This License explicitly affirms your unlimited permission to run 
the
> unmodified Program."
> 
> > but if you just use qtcreator, just use it. its free.  
> 
> well, that is not what
> "
> Anyways, I'll now explain again the answer to the original 
question asked.
> The question was, as I understood it, "Is it allowed that people 
working in

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Michael Jackson]

OK, Here goes the explanations of how to interoperate with Qt Software 
packages. IANAL. We will start from the easy and work our way towards difficult.

QtCreator: QtCreator is free. You, as a developer of software, can use 
QtCreator as your IDE to develop your own software. The GPL license of 
QtCreator will NOT infect your software. Use QtCreator to create open or closed 
software. Free or commercial. Your choice.

QtCreator as Part of a Commercial Qt License: The only thing this gets you is 
the ability to get some "commercial" support versus just posting on the 
qt-creator mailing list.

Modifying QtCreator: If you are actually modifying QtCreator yourself to create 
a distribution outside of your organization then ANY codes you write or modify 
are subject to the QtCreator license. This has ramifications if you happen to 
have a Qt commercial license.

Using Qt5 in your software project: If you use Qt in your project ANYBODY 
contributing to that same project MUST have the same kind of Qt license. 
Period. Full Stop.

For the original question;
"Is it still possible for the developers who don't use Qt libraries in
any way, use Qt Creator IDE for editing and debugging?"

The answer is YES, but the devil is in the details. They *should* be able to 
just download the free version of QtCreator from http://download.qt.io and use 
that version. They can't use the "commercial" version of QtCreator unless they 
have a commercial license for Qt. But if their projects are *not* using Qt, 
then why do they have a commercial license for Qt?


Again, IANAL, but I believe this to be a reasonable summary of the licensing of 
QtCreator and Qt.
--
Mike Jackson 



On 3/27/20, 12:21 PM, "Interest on behalf of alexander golks" 
 wrote:

Am Fri, 27 Mar 2020 17:11:16 +0100
schrieb Jean-Michaël Celerier :

> It is also the license of the binaries that you can download there :
> https://download.qt.io/official_releases/qtcreator/4.11/4.11.1/
> 
> And it states quite succintly :
> "This License explicitly affirms your unlimited permission to run the
> unmodified Program."
> 
> > but if you just use qtcreator, just use it. its free.  
> 
> well, that is not what
> "
> Anyways, I'll now explain again the answer to the original question asked.
> The question was, as I understood it, "Is it allowed that people working 
in
> a project use commercially licensed Qt and some other persons in the same
> project who do not develop Qt use open-source licensed Qt tools?"
> 
> Answer to this is: No, it is not allowed to mix commercial "Licensed
> Software" and the open-source versions provided by The Qt Company in the
> same project."
> 
> seems to mean, which is why I'm wondering.

the problem is, as already stated, that some did not answer your question 
properly.
i understood your question. and as i said, your mixing up things. as we 
say: you mix apples and pears.

you're talking about using an executable X, based on open source software.
you're talking about using an library Y, for which you have a license, 
based on open source software, too.
you're talking about using exec X to use Y somehow.
you're talking about using exec X with other libraries.

now what has tool X todo with library Y? nothing.
well, it happen to be that tool X is written using library Y, but thats of 
no concern here.

the licese for Y only clearifies how you may use/include the library Y into 
your projects, 
and not how to use tool X to build apps using library Y.



other words:
would you ask if you have to use the commercial vs license because you 
bought a qt license?

-- 
/*
 *printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good 
luck!\n",...);
 *linux-2.6.6/drivers/net/wan/lmc/lmc_main.c
 */
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest



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

Re: [Interest] Styling Qt Widgets with Qt Quick

[Michael Jackson]

You probably want to look into using CSS to style the Widgets. Then create a 
loading mechanism to load a new CSS into the application thus changing its 
appearance. This is what we did for our app. There are a lot of subtle 
interactions with CSS and each particular desktop environment which can take 
some time to work through but since you are only working on a Linux 
distribution you should be fine.

--
Mike Jackson 

On 1/7/20, 7:06 AM, "Interest on behalf of Noah Davis" 
 wrote:

Thanks for the suggestion. I had a look and they don't seem to be
using Qt Quick at all though. My goal isn't necessarily to make a
mobile-ish UI either.

What I want to do is make Qt Quick and Qt Widget apps look the same
under KDE Plasma or other Linux desktop environments. Ideally, it
should also be possible to edit the look of the theme without
recompiling the C++ by editing QML files.

On Mon, Jan 6, 2020 at 5:55 PM Jean-Michaël Celerier
 wrote:
>
> > I want to make a Qt Widget style that looks exactly the same as
> controls that are made with Qt Quick/QQC2/Kirigami. Is it possible to
> style Qt Widgets with Qt Quick or will it be possible in Qt 6? If it
> is/will be possible, could it be considered a good idea in the first
> place?
>
> You could look maybe on how Telegram is coded, it's all QWidget and has a
> really mobile-like feel : https://github.com/telegramdesktop/tdesktop
>
> It's using that lib behind the scene : 
https://github.com/desktop-app/lib_ui
>
> Best,
> Jean-Michaël
>
> On Mon, Jan 6, 2020 at 4:14 AM Noah Davis  wrote:
>>
>> Hello,
>>
>> I want to make a Qt Widget style that looks exactly the same as
>> controls that are made with Qt Quick/QQC2/Kirigami. Is it possible to
>> style Qt Widgets with Qt Quick or will it be possible in Qt 6? If it
>> is/will be possible, could it be considered a good idea in the first
>> place?
>>
>> I'm aware of KDE's qqc2-desktop-style (it makes QQC2 look like Qt
>> Widgets) and I've heard that Qt plans to make it easier to synchronize
>> the look of Qt Widgets and Qt Quick in Qt 6, but I don't know the
>> details.
>>
>> Thank you,
>> Noah Davis
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest



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

Re: [Interest] Tricks to improve moc performance?

[Michael Jackson]

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.

 

--

Mike Jackson 

 

From: Interest  on behalf of Adam Light 

Date: Monday, December 9, 2019 at 5:15 PM
To: Qt Interest 
Subject: Re: [Interest] Tricks to improve moc performance?

 

 

 

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 

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

Re: [Interest] Tricks to improve moc performance?

[Michael Jackson]

On 12/6/19, 12:52 PM, "Interest on behalf of Thiago Macieira" 
 wrote:

On Friday, 6 December 2019 01:16:31 PST Kevin Funk via Interest wrote:
> On that note, CMake goes one step further and removes the need to do this
> manually. Using CMake's AUTOMOC feature, CMake will automatically create 
ONE
> mocs_compilations.cpp file per target which in turn includes all generated
> "moc_XYZ.cpp" files.
> 
> Quoting:
> 
> "Header files that are not included by an #include "moc_.cpp"
> statement are nonetheless scanned for Q_OBJECT or Q_GADGET macros. The
> resulting moc_.cpp files are generated in custom directories and
> automatically included in a generated
> /mocs_compilation.cpp file, which is compiled as part 
of
> the target."

That's good, but not ideal.

This solution gets you a single build for all the the mocs, which is good, 
but 
won't generate the best code that Peppe was talking about. You want the moc 
for a given class to be in the class's own .cpp.

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


Dear Thiago, 
Could you expand a bit on your comment? We use CMake for our build system 
and the AUOT_MOC feature. I just would like to know what exactly I am missing 
by doing this.

--
Mike Jackson 


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

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

[Michael Jackson]

From: Interest  on behalf of Elvis Stansvik 

Date: Friday, June 21, 2019 at 7:14 AM
To: Kai Köhne 
Cc: Qt Interest 
Subject: Re: [Interest] notarizing builds for Mac - enabling hardened runtime

 

Den fre 21 juni 2019 09:13Kai Köhne  skrev:

> -Original Message-
> From: Interest  On Behalf Of Hamish
> Moffatt
> Sent: Friday, June 21, 2019 8:42 AM
> To: Qt Interest 
> Subject: [Interest] notarizing builds for Mac - enabling hardened runtime
> 
> Apple says that all apps will need to be notarized (viewed) by them to be run
> on macOS 10.15 once released.
> 
> Apps must have the hardened runtime enabled in Xcode before they can be
> notarized.
> 
> Is there any way to get qmake to enable that project option?

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.

 

This is what I've done at work to prepare our builds for this. We use CMake 
though and we're already running codesign manually.

 

The notarization is annoying and takes around 5 minutes for Apple to run their 
virus scanners or whatever they're doing, so at the moment we're doing it only 
on Git-tagged CI builds (releases), not on every commit. What this gives us 
currently is that the macOS "do you want to run this" prompt will say "Was 
scanned by Apple on blah blah and found to look good" or something.

 

Will be more annoying if/when macOS starts to demand notarized builds, because 
then we'd need to do notarization of every commit, or force testers that wants 
to test a random build to turn off that checking (which I assume is still going 
to be possible through System Preferences).

 

Apple, sigh, I can understand and sympathize requiring signed builds, but this 
mandatory "virus scanned by Apple" is a little silly. As a user I trust the 
virus scanner I pick myself more than some blackbox process on Apple HQ servers.

 

Elvis

 


Regards

Kai

 

 

My guess is that macOS will allow you to “override” the need to have the app 
scanned just like you can do now by right-clicking the app and clicking “open”. 
They would have to or developers wouldn’t be able to run their own apps or 
testers wouldn’t be able to run test apps. I don’t think macOS has gone the 
full “App Store Only” model yet, those days are coming. Still it would be good 
to get a definitive answer through Apple docs as to whether Notarization is 
mandatory or just strongly encouraged.

 

--

Mike Jackson

 

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

Re: [Interest] My first 5 years with Qt and 2 suggestions

[Michael Jackson]

Nice to have such a strong supporter in the Qt community, my opinions are in 
line... 

On 5/8/19, 8:09 PM, "Interest on behalf of Henry Skoglund" 
 wrote:

Hi, 5 years ago I started with Qt, it's been a very nice ride, thank 
you! Looking forward to the next 5. Got 2 suggestions:


1) Make Qt more easily accessable for first timers:

Why not introduce a Qt Starter Pack?

I'm thinking of an *extremely* simplified installation tool. For 
Windows, it could be Qt LTS version bundled with the 32-bit MinGW compiler.

No login, no selection of kits and no selection of a directory where to 
install (instead hardwired to C:\Qt). Just one big button: "Install".

Uninstall is done through the control panel. No updates possible, 
uninstall/download/reinstall only.

Great Idea. One problem with the scheme is that most enterprises do _not_ allow 
write access to the C: drive so the installer must at least allow this one 
single choice to be made.


2) Improved Qt DLL morphology: for a given DLL, today we have very 
coarse naming schemes, it's either Qt4Core.dll, Qt5Core.dll or 
Qt6Core.dll (and similar namings on the other platforms).

On the Qt forums I see questions, they have the MinGW version installed, 
and instead of windeployqt, for deployment they have manually copied the 
DLLs from the QtCreator bin directory --> DLL hell.

This is how we create our own application package. The Qt DLL's are copied from 
the Qt installation into the build directory. Long ago I learned this was 
pretty much the only way to prevent DLL hell. Keep the system path clean, don't 
let anything put their own paths into the System path. At the time we supported 
32 and 64 bit on both VS2008 and VS2012 and it was absolute DLL hell. We 
learned to just NOT put anything on the system path and to create build rules 
to copy the proper DLLs into the build directory so that we knew for sure which 
DLLs were getting loaded.


Or they have a Qt program like Krita installed on their C:, and some 
PATH setting causes Qt DLLs to clash with their Qt installation or 
deployment --> DLL hell.

See above. I would argue if Krita is "installing" Qt DLLs into a system 
directory they are simply doing it wrong. They should package the DLL's into 
their app package and distribute it that way. If the user is adjusting their 
system path to make Krita work, there is something wrong.

Or they have copied Qt5Core.dll with wrong bitness, 64 instead of 32 etc.

This is just a basic mistake that we all make at some point during our 
development. I think we have all done it at some point. I tend to miss the "d" 
in the name when copying the DLLs manually (which is why one creates build 
rules for your build system to always get the correct DLL copied).

At some point some of the issues are just user errors and the Qt devs can't be 
expected to make up for that. Better documentation and examples would help to 
alleviate those mistakes.

For that last syndrome, I remember from my Visual Basic days, there were 
16-bit and 32-bit versions, but Microsoft had different DLL names then, 
either VBRUN40016.DLL or VBRUN40032.DLL. (Today for example 
vcruntime140.dll has the same name regardless of bitness, 32-bit version 
is in C:\Windows\SysWOW64 and 64-bit version is in C:\Windows\System32, 
if this seems logical you need to change medication.)

So my suggestion is, let's reverse this trend, introduce a much more 
fine-grained naming scheme, examples:

Qt5Core.dll for Qt 5.12.3 MSVC2017   32-bit --> QtCore51203MS1732.dll
Qt5Core.dll for Qt 5.12.3 MSVC2017   64-bit --> QtCore51203MS1764.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtCore51203GW7332.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtCore51203GW7364.dll

Qt5Gui.dll for Qt 5.12.3 MSVC2017   32-bit --> QtGui51203MS1732.dll
Qt5Gui.dll for Qt 5.12.3 MSVC2017   64-bit --> QtGui51203MS1764.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtGui51203GW7332.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtGui51203GW7364.dll

and so on.

This naming scheme would eliminate lots of DLL hells occurring today in 
Windows, and would be much more tolerant/allowing to a Windows system 
having multiple Qt installations of different versions.

VS2017 and VS2019 have compatible runtime libraries so your naming scheme 
already causes confusion. Qt 5.12.x are all ABI compatible so 5.12.1, 5.12.2, 
5.12.3 are all compatible so it does not really matter the naming for Qt 
5.12.x. GW is confusing (MGW might be better). QtGui512VC14x64(_debug).DLL 
might be an alternate scheme if you really want to go down that road but the 
current naming scheme I think works for the vast majority of developers (we 
know better) and a "user" of an application built on top of Qt should not have 
to know the 

Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]

[Michael Jackson]

We all get frustrated at times and sometimes that frustration comes out in 
posts (hopefully with a short  tag..) but Roland’s posts 
_always_ have put downs for almost every other kind of developer except those 
in the medical/space community. I consider myself having pretty thick skin and 
I can ignore those posts (Gmail server side rules make sure of this) but at 
some point Roland needs to be told in no uncertain terms that the list is for 
questions/answers not long tirades. I don’t mind discussing the merits of the 
different systems, use-cases of those systems, developer learning and all that. 
Those can be enlightening discussions in and of themselves. But at some point, 
we as a community, just need to let Roland know that his demeanor is not 
conducive to getting responses on the list and soon will no longer be tolerated.

 

-- 

Michael A. Jackson 400 S. Pioneer Blvd
Owner, President   Springboro, Ohio 45066
BlueQuartz Software, LLC   EMail: mike.jack...@bluequartz.net


 

From: Interest  on behalf of René Hansen 

Date: Monday, February 11, 2019 at 10:16 AM
To: Jason H 
Cc: Qt Interest 
Subject: Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple 
right margins]

 

I'm with Jason here.

I use Qt for mobile development as well, and I don't think a ban is the right 
course of action. Choice of words is a pre-eminent selector in deciding which 
posts to take seriously. Using terms in the the manner Roland does about phone 
development, in all likelihood, self-disqualifies any serious consideration his 
posts might have received otherwise. Although a shame, that is repercussion 
enough in my opinion.


/René

 

On Mon, 11 Feb 2019 at 15:07 Jason H  wrote:

The truth is I often enjoy the hyperbole. In my book it's better to have a 
thick skin rather than to go around being offended by everyone and asking for 
them to comply with a fragile nature. However this most recent post put down 
the Qt mobile community of which I am a significant member having been using Qt 
in mobile for about the past 5 years. I have argued repeatedly for more 
attention in the Mobile platforms (except WinRT) and the message was directly 
contrary to that aim. I pointed out (off list) ironically what should happen is 
port the application to mobile and just let Samsung make and revise the 
hardware faster than he ever could. Didn't draw any ire but it didn't go 
anywhere either. I'm starting to wonder if the hyperbole isn't for comedic 
effect. 

My plan of action is that I'm just going to ignore this person's snarky posts 
which comes with the price that I might have the answer to their issue and I 
won't contribute it. 

I on occasion post something snarky because I am frustrated with the problem 
I'm having. I wouldn't want to be banned over it. There is a social capital 
here, add I try to have a positive balance. And I think it's reasonable that 
when you fall below zero, you stop getting replies. I would not bring in the 
CoC just yet. 

> Sent: Friday, February 08, 2019 at 8:18 PM
> From: "Konstantin Shegunov" 
> To: m...@herrdiel.de
> Cc: "Interests Qt" 
> Subject: Re: [Interest] Netiquette [was: Feature Request - QtCreator - 
> Multiple right margins]
>
> >
> > [...]
> > I do appreciate the open discussion style on this list. I even do
> > appreciate a somewhat harsh style, if it has a factual base and is
> > getting straight to the point instead of b*s*ing around. But those
> > lengthy wallpapers our President of Logikal solutions commonly utters,
> > have long since crossed the border from amusing to annoying.
> >
> 
> I, myself, still perceive them more as amusingly misguided, than really
> angering (annoying at times, yes). This is just me, though, I have
> experience with that kind of thing. However, I can very well imagine how
> you, and most certainly others, are finding them taxing; not surprising at
> all.
> Plus, as I rule, I tend to discard anything that references fortran or
> cobol as examples of anything ... ;)
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

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

Re: [Interest] 80 column enforcement under Linux

[Michael Jackson]

I would think that clang-format should be able to help you out with this. It is 
part of the LLVM download.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

On 1/17/19, 11:32 AM, "interest-boun...@qt-project.org on behalf of 
rol...@logikalsolutions.com"  wrote:


All,

Yes, QtCreator will let us set a right margin of 80 columns and can be  
configured to wrap, but, that only helps with new code, not thousands  
of lines of old code. I was hoping Artistic Style would have an option  
to flag physical lines > 80 characters long, but don't see that.

Is there some Linux tool which can be integrated with QtCreator which  
will enforce a maximum physical source line length by flagging it as  
an error or providing some kind of "find instances" search ability? I  
assume there has to be one since BARR-C:2018 (and its predecessors)  
are so widely used.

https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard

Hoping to avoid a "just wrap" solution. Would like to really adhere to  
the spirit of the standard, even if we end up overriding to 130  
characters as quite a few shops do.

Thanks,
-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us

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



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

Re: [Interest] How to inspect a Qt Application memory usage?

[Michael Jackson]

Doesn't Xcode come with the "Instruments" application which is designed to do 
the things that OP is asking about? I have used it in the past for function 
timing and some memory issues but it has been a few years.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

On 10/22/18, 12:26 PM, "Interest on behalf of Elvis Stansvik" 
 wrote:

Den mån 22 okt. 2018 kl 18:04 skrev Nuno Santos :
>
> Elvis,
>
> I have just tried that it resulted in this. I’m not familiar with 
valgrind output. Does this look good to you?
>
>
> --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
> --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 
times)
> --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 
times)
> --45024-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 
times)
> QML debugging is enabled. Only use this in a safe environment.
> ==45024==
> ==45024== Process terminating with default action of signal 11 (SIGSEGV)
> ==45024==  Access not within mapped region at address 0x18
> ==45024==at 0x1077D6E3A: _pthread_wqthread (in 
/usr/lib/system/libsystem_pthread.dylib)
> ==45024==by 0x1077D6BE8: start_wqthread (in 
/usr/lib/system/libsystem_pthread.dylib)
> ==45024==  If you believe this happened as a result of a stack
> ==45024==  overflow in your program's main thread (unlikely but
> ==45024==  possible), you can try to increase the size of the
> ==45024==  main thread stack using the --main-stacksize= flag.
> ==45024==  The main thread stack size used in this run was 8388608.
> --45024:0:schedule VG_(sema_down): read returned -4
> ==45024==
> [1]45024 segmentation fault  valgrind --tool=massif XPTO.app

Hm, I'm not too familiar with valgrind output, but that looks like the
application crashed due to an access violation. Perhaps you should run
it in a memory error checker first to make pinpoint the violation?
Valgrind has one called memcheck (--tool=memcheck).

Elvis

>
> Thx!
>
> Nuno
>
> On 22 Oct 2018, at 16:54, Elvis Stansvik  wrote:
>
> I used valgrind with valgrind --tool=massif myApp to track down a memory 
issue just today actually, and it worked out great, but I don't know if it 
works on macOS (this was on Linux). I used massif-visualizer for visualization.
>
> I've been meaning to check out heaptrack but haven't gotten around to it.
>
> Elvis
>
> Den mån 22 okt. 2018 16:50Nuno Santos  skrev:
>>
>> Hi,
>>
>> What tool(s) do you people suggest in order to investigate where is the 
memory being spent on a Qt application?
>>
>> Thanks!
>>
>> Nuno
>> ___
>> 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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Simple device discovery using UDP

[Michael Jackson]

What you want is this:

https://github.com/nitroshare/qmdnsengine

Don't reinvent the wheel if you don't have to. MIT licensed. No relation to the 
project at all.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

On 10/2/18, 9:43 AM, "Interest on behalf of Jason H" 
 wrote:

I have an app (Desktop) that I want it to know about other running 
instances on the local network. I figured UDP broadcast was a natural choice. I 
tried it, but I never saw anything but my own (local) packets. There's quite a 
few stackoverflow questions, but none used Qt. I'm wondering if it's a 
wifi/router thing?

The hosts are on the same WiFi SSID and address space:
10.31.4.26 host1
10.31.4.202 host2

Both are on my desk. 
HostInfoService::HostInfoService(...) {
...
udpSocket4.bind(QHostAddress::Any, 13999, QUdpSocket::ShareAddress);
connect(, SIGNAL(readyRead()), this, 
SLOT(readPendingDatagrams()));
...
}

void HostInfoService::readPendingDatagrams()
{
for (auto udpSocket: { } ) { //, }) {
while (udpSocket->hasPendingDatagrams()) {
QNetworkDatagram datagram = 
udpSocket->receiveDatagram();
QString host = QString(datagram.data().constData());
messages[host] = datagram.senderAddress();
qDebug() << Q_FUNC_INFO << host << 
datagram.senderAddress().toString();
}
}
}

I also tried on an IPv6 socket, no joy.

Has anyone else done something like this?

___
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

Re: [Interest] Qt 5.11.1 inside of a Docker container

[Michael Jackson]

Just to follow up a bit on this. After taking the advice to use the Qt5 
versions from beineri I ran into the next problem with Docker and Qt5. Qt5.10 
and forward apparently use "statx()" within the moc and uic programs which 
isn't allow by Docker versions before 18.04. My Docker version is 18.06. In 
order to get "statx()" to be allowed to run the Linux distribution needs at 
least libseccomp 2.3.3. That version is not available until Ubuntu 18.10. I 
tried to recompile the newer version of libseccomp and install it onto my 
Ubuntu 16.04 LTS installation but the issues still persist when compiling my 
own code based on Qt. I can drop back to Qt5.9.5 as from what I have read that 
version will work but that leaves me wandering if all of these issues between 
the various parties (Docker, Qt and Linux) would ever work themselves out in 
time? I say this not as a rant or complaint but as a point of reference in case 
anyone else is running into the same problems with Qt and Docker (at least with 
a Ubuntu host)

I am open to suggestions (Looking into OpenSUSE)

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

On 8/21/18, 2:12 PM, "Interest on behalf of Richard Weickelt" 
 wrote:

> I recently had success installing Qt 5.9.2 in a Windows docker
> container using this link as a starting point:
> https://stackoverflow.com/a/34032216/991000

You can also see this approach in action here:
http://code.qt.io/cgit/qbs/qbs.git/tree/docker/stretch/Dockerfile

But pulling packages from https://launchpad.net/~beineri is far more simple
on Ubuntu.

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

Re: [Interest] Qt 5.11.1 inside of a Docker container

[Michael Jackson]

I actually use the --script in one of our "Superbuild" projects that is driven 
by CMake. The important bit is that when those scripts are run (macOS, Linux 
and Windows) there is *always* a GUI environment running. In a Docker container 
there is no GUI environment to run so the --script will not help unless 
something has changed lately with the Qt5 installers.
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>

On 8/21/18, 10:49 AM, "Carel Combrink"  wrote:

Hi,

I recently had success installing Qt 5.9.2 in a Windows docker
container using this link as a starting point:
https://stackoverflow.com/a/34032216/991000

I am on my way home at the moment, but if you do not get right I can
try to assist some more tomorrow.

Regards,
Carel
On Tue, Aug 21, 2018 at 4:39 PM Michael Jackson
 wrote:
>
> I’m a bit new to Docker but this will end up being a Qt question. I have 
been trying to figure out how to install Qt 5.11.1 into a Docker container 
based on Ubuntu 18.04. The first obvious way was to download the Qt installer 
and try running that until one realizes that the installer requires a GUI to 
run, which Docker does not seem to have. Searched around on the internet and 
about the only process seems to just be to outright build the version of Qt 
that you require if it is not provided by the normal packaging system. Qt 5.9.5 
is provided for Ubuntu 18.04. For those that use Docker to host builds is that 
what is commonly done? I thought about just installing Qt 5.11.1 into my host 
environment and then use the COPY command to copy it into the Docker image that 
is being created but something just didn’t seem “right” about doing it that 
way. I have found some scripts that seem to think that they can strip out 
installer components but those scripts don’t seem to work. Has there been any 
movement in the ability to install Qt in a truly headless environment without 
having to build from source?
    > Thanks
> --
> Michael Jackson  


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

[Interest] Qt 5.11.1 inside of a Docker container

[Michael Jackson]

I’m a bit new to Docker but this will end up being a Qt question. I have been 
trying to figure out how to install Qt 5.11.1 into a Docker container based on 
Ubuntu 18.04. The first obvious way was to download the Qt installer and try 
running that until one realizes that the installer requires a GUI to run, which 
Docker does not seem to have. Searched around on the internet and about the 
only process seems to just be to outright build the version of Qt that you 
require if it is not provided by the normal packaging system. Qt 5.9.5 is 
provided for Ubuntu 18.04. For those that use Docker to host builds is that 
what is commonly done? I thought about just installing Qt 5.11.1 into my host 
environment and then use the COPY command to copy it into the Docker image that 
is being created but something just didn’t seem “right” about doing it that 
way. I have found some scripts that seem to think that they can strip out 
installer components but those scripts don’t seem to work. Has there been any 
movement in the ability to install Qt in a truly headless environment without 
having to build from source?

 

Thanks

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

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

Re: [Interest] Interest Digest, Vol 76, Issue 8

[Michael Jackson]

From: Interest  on 
behalf of Roland Hughes 
Organization: Logikal Solutions
Date: Monday, July 30, 2018 at 9:17 AM
To: Qt Interest 
Subject: Re: [Interest] Interest Digest, Vol 76, Issue 8

I would hate to think anyone utilized Eclipse to create QtCreator. I would 
hope, given KDE's ties to Qt that KATE/KDevelop were used to create it.

Um, besides being a bit on the slow side (java….), what was wrong with Eclipse 
for C++ dev? Back when it was around the choices were pretty limited. It still 
has a killer feature that even QtCreator does not have and that is the ability 
to hover over a macro and have the complete (including multiply levels) code 
generation show up. For code basis that heavily use macros this was a really 
great feature to have. And I could just have it use my premade makefiles or use 
my cmake generated makefiles without any complaints or regeneration.

--
Mike Jackson
 


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

Re: [Interest] qmlscene install problems (was: Interest, Digest, Vol 82, , Issue 5)

[Michael Jackson]

From: Interest  on 
behalf of Roland Hughes 
Organization: Logikal Solutions
Date: Monday, July 30, 2018 at 10:52 AM
To: Qt Interest 
Subject: Re: [Interest] qmlscene install problems (was: Interest, Digest, Vol 
82, , Issue 5)

When the virus known as QML was unleashed on the world, the "teaser app" was 
the Welcome screen in QtCreator. It had pretty much the exact same level of 
success as the PowerFailure teaser app. Actually, the PowerFailure teaser app 
worked better. On a large number of YABU distros, QtCreator wouldn't even load, 
just crashed. On others it would start but had other problems. In the YABU 
world, 


qtcreator -noload Welcome

Maybe you should have tried another Linux distribution? I've never had a 
problem loading any of the QtCreators on our Ubuntu boxes (starting with 14.04 
up and through 18.04).

While the jury is still out if QML is a success or not I think that attempting 
to give developers quicker ways to build applications is something that should 
be pursued. What is wrong with wanting a more efficient way to create our 
applications. What is wrong with wanting to make our applications appeal to the 
"younger crowd" by using newer technologies. Just because something failed back 
then does not mean that iterating on that idea (RAD) is bound to failure again. 
As a community of developers we should always be pushing ahead with 
technologies to make our lives easier. Sometimes those technologies work and 
sometimes they don't. As long as we learn from the mistakes and keep forging 
ahead is what matters.

--
Mike Jackson


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

[Interest] Missing Title bar on macOS 10.11+ for Open File Dialogs

[Michael Jackson]

Is anybody else hitting this little gem:

 

https://bugreports.qt.io/browse/QTBUG-59805

 

(Thanks Apple). And if so what are peoples workarounds for it? There is a patch 
in the bug report. I would really rather not compile Qt myself if I don’t have 
to. Thanks

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/24/18, 4:16 PM, "Interest on behalf of Thiago Macieira" 
<interest-bounces+mike.jackson=bluequartz@qt-project.org on behalf of 
thiago.macie...@intel.com> wrote:

On Thursday, 24 May 2018 16:57:03 -03 Michael Jackson wrote:
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> '/tmp/runtime-buildbot'

This one means your environment isn't properly set up. Make sure 
XDG_RUNTIME_DIR is set correctly to the correct path.

> qt.qpa.screen: QXcbConnection: Could not connect to
> display
> Could not connect to any X display.

export QT_QPA_PLATFORM=offcreen

> So what, _exactly_, am I missing. Is there a platform plugin that I need 
to
> force load in these situations?

Yes, the offscreen one.

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

Well I got a bit farther and was able to use the -platform offscreen arguments 
to our command line applications (still worried what will happen when our 
libraries are called from Python) and I got really close. BUT this happens:

"This plugin does not support application fonts"

Some of the "painting" that we do involves fonts (and scaling them up or down 
depending on the size of the output image).

So I would sum up the whole thread as "technically" one can use QtGui 
application but anything past trivial painting isn't practically possible 
across platforms.

--
Mike Jackson


 



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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/24/18, 3:53 PM, "Michael Jackson" <mike.jack...@bluequartz.net> wrote:

On 5/22/18, 3:18 PM, "Interest on behalf of Thiago Macieira" 
<interest-bounces+mike.jackson=bluequartz@qt-project.org on behalf of 
thiago.macie...@intel.com> wrote:

On Tuesday, 22 May 2018 15:38:00 -03 Michael Jackson wrote:
> If it is a raster only then _why_ is it in QtGUI? There is no reason 
for it
> to depend on anything in GUI if there are no accelerated bits of code 
or
> any other codes (I'm sure I am wrong there) that depend on a windowing
> system?

Nothing in QtGui depends on the windowing system. Those bits live in 
the QPA 
plugin or in a separate library loaded by that plugin. This is the 
third time 
I've said so in this thread, including the email you replied to.

QtGui is the library that provides the foundation for all graphical and 
user-
interface functionality. It *integrates* with the windowing system of 
your 
choice by way of a semi-private extension API known as QPA (Qt Platform 
Abstraction). One of those windowing systems is the "offscreen" one, 
which 
connects to no WS server: effectively, a command-line application.

> Bottom Line: I have a reasonable use-case where I need to "draw" into 
a
> "Canvas" from a command line app.

Use QtGui.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
  
Ok, You told me. Multiple times even. So let me try this in a practical 
manner. I re-enabled one of our unit tests that uses QImage which means I have 
to link it against QtGui. Done. It compiles. Great. The unit test attempts to 
run and I get the following:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbot'
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

The top part of the code is:

  // Instantiate the QGuiApplication that we need to get the current path and 
load plugins.
  QGuiApplication app(argc, argv);
  QGuiApplication::setOrganizationName("Your Company");
  QGuiApplication::setOrganizationDomain("Your Domain");
  QGuiApplication::setApplicationName("");

The I try some QImage testing.

The same kind of result I also see on macOS. The "user" running our build not 
is NOT logged in. The test from above was on a Ubuntu 16.04 system running the 
precompiled Qt 5.10.1 binary from http://download.qt.io.

So what, _exactly_, am I missing. Is there a platform plugin that I need to 
force load in these situations?

--
Mike Jackson





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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

On 5/22/18, 3:18 PM, "Interest on behalf of Thiago Macieira" 
<interest-bounces+mike.jackson=bluequartz@qt-project.org on behalf of 
thiago.macie...@intel.com> wrote:

On Tuesday, 22 May 2018 15:38:00 -03 Michael Jackson wrote:
> If it is a raster only then _why_ is it in QtGUI? There is no reason for 
it
> to depend on anything in GUI if there are no accelerated bits of code or
> any other codes (I'm sure I am wrong there) that depend on a windowing
> system?

Nothing in QtGui depends on the windowing system. Those bits live in the 
QPA 
plugin or in a separate library loaded by that plugin. This is the third 
time 
I've said so in this thread, including the email you replied to.

QtGui is the library that provides the foundation for all graphical and 
user-
interface functionality. It *integrates* with the windowing system of your 
choice by way of a semi-private extension API known as QPA (Qt Platform 
Abstraction). One of those windowing systems is the "offscreen" one, which 
connects to no WS server: effectively, a command-line application.

> Bottom Line: I have a reasonable use-case where I need to "draw" into a
> "Canvas" from a command line app.

Use QtGui.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
  
Ok, You told me. Multiple times even. So let me try this in a practical manner. 
I re-enabled one of our unit tests that uses QImage which means I have to link 
it against QtGui. Done. It compiles. Great. The unit test attempts to run and I 
get the following:



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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-Original Message-
From: Interest  on 
behalf of Jason H 
Date: Tuesday, May 22, 2018 at 10:16 AM
To: Thiago Macieira 
Cc: 
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

> >  There is a difference. As you already stated, a QPixmap requires more 
than
> >  a QImage, so what should be provided is a QImage,
> 
> Now think about how it's constructed internally.
> 
> QBrush only exists to paint, which means GUI (QPaintDevice is the basis 
of all 
> GUI). It is meant to paint efficiently. If QPixmap can do that more 
> efficiently, why should it store a QImage instead?

Admittedly I don't understand the nuances of QPixmap. But I know working 
with a QImage should not require a windowing server. 

THIS. I had to refactor a bunch of our code because our application needs to 
create an "image" of some data. I was using QPainter/QImage to do this, but 
then the use case came up of having to run the code on a headless server or 
through command line Python. I would get failures because there was no 
windowing system to use for QImage. I ended finding "libHaru" which allows one 
to "Draw" a PDF without the need for a windowing system. The API is similar to 
QPainter, one can draw basic polygons, fills, brushes, pens, lines. All 
_without_ the need for a windowing system. I didn't really want to bring in 
another dependency but I didn't really have a choice: QImage simply will not 
work in this situation.

For Qt6 what I would like to see is QPainter abstracted out to just an 
interface and have the normal accelerated implementation that we have now in 
QtGui but also have a non-accelerated version living in QtCore or a library 
that does NOT depend on a windowing system. All the other classes that have 
been discussed as having to be moved like the Polygon/Matrix classes should 
also be moved. There are a lot of science type of apps that could instantly 
make use of these kinds of things. Instead I have to bring in something huge 
like ITK just to read/write some images.

My point is that for me, I am ok with a non-accelerated 2D drawing system if it 
does not depend on a windowing system. Qt is a wonderful overall toolkit. It 
isn't *just* a GUI toolkit as another poster has suggested. It is a unifying 
toolkit that is well written and documented that is cross platform.

Just my nickel's worth.
--
Mike Jackson 
 

 


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

[Interest] Removing focus rect on macOS through StyleSheets

[Michael Jackson]

Is the css property "outline: none;" supposed to work on macOS? I can 
programmatically use Widget.setAttribute(Qt.WA_MacShowFocusRect, 0); I was 
hoping to just use the CSS property (which the internet says I should be able 
to do).I have read the docs (maybe not the correct ones) and I am not seeing 
any exceptions for the focus outline on macOS.

Thanks
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net <http://www.bluequartz.net>
 



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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-Original Message-
From: Interest  on 
behalf of Thiago Macieira 
Organization: Intel Corporation
Date: Monday, May 21, 2018 at 9:49 AM
To: 
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

On Sunday, 20 May 2018 21:27:31 -03 Jason H wrote:
> Why is QImage even a GUI type? 

"Has pixels" is the simplest defintion of GUI.

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

 Let's agree to disagree. LibTiff deals with "pixels" and it does not need a 
windowing system or define a "GUI" to do its work.

--
Mike Jackson



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

Re: [Interest] QDatastream, QMap, QImage serialization

[Michael Jackson]

-Original Message-
From: Interest  on 
behalf of Sze Howe Koh 
Date: Monday, May 21, 2018 at 10:17 AM
To: interest 
Subject: Re: [Interest] QDatastream, QMap, QImage serialization

On 21 May 2018 at 17:08, Christian Gagneraud  wrote:
> On 21 May 2018 at 20:12, Jean-Michaël Celerier
>  wrote:
>>> Why is QImage even a GUI type? 99% of what I do with QImage is not for
>>> GUI. I can understand that QPixmap is GUI, but to me QImage is i/o and
>>> pixel/metadata manipulation (using scanline() where appropriate) . Yes,
>>> occasionally I use a QPainter on one, but that does not beed to be 
bound to
>>> a windowing system. A non-GUI raster painter would be sufficient.
>>
>> +1 (and also QColor ! plenty of command-line apps that work with colors 
:p)
>
> +1 (and also QPen and QBrush, they are (should be) just bundled 
properties)
>
> Once i wrote a graphical document format library (load, store and
> models), that could have not depend on GUI at all if it didn't use
> QColor, QPen, QBrush.

I agree that QColor, QRgb, QRgba64, QGradient (and its subclasses),
QGradientStop, and QPolygon are data types that are independent of
GUIs, so they can be simply moved out of the Qt GUI module if desired.

However, other classes can't be cleanly separated from Qt GUI (at
least without significant re-design) because:
* QPixmap is tied to system graphics resources

I agree as that seems like a reasonable abstraction.

* QPaintDevice has the concept of "physical DPI" and "logical DPI"
which are GUI-related.

Why can't QPaintDevice be more of a low level or a "Device" independent kind of 
class? I can write a class that has 2 properties of LogicalDPI and PhysicalDPI. 
My implementation it would be up to the user to set those. If I select a 
different implementation based off a "real" physical system then those values 
are retrieved from the system.

* QPainter depends on QPaintEngine which depends on QPaintDevice

See above.

* QPen depends on QBrush which depends on QPixmap
* QPen and QBrush are useless without QPainter
Maybe, maybe not.
* QImage inherits QPaintDevice
Don't? I just went through a major restructuring of our plugin architecture 
because developers were using QImage to load images (How dare they...) but the 
app crashed when run through a command line because a GUI was not available. I 
understand this is a design decision BUT libTiff sure doesn't need a windowing 
system to load an image.

* QRegion depends on QBitmap which inherits QPixmap


Regards,
Sze-Howe

Best
Mike Jackson



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

[Interest] Qt5 CSS StyleSheet Variables

[Michael Jackson]

Just to confirm, but does Qt accept CSS variables as describe here: 
 ?

I tried and I get the error that the style sheet could not be parsed. I have a 
style sheet with a LOT of color settings and having to do a bunch of 
search/replace to change the colors is error prone at best. 

Thanks
Mike Jackson


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

[Interest] Possible to draw between QWindows

[Michael Jackson]

Possibly strange question that I have googled a bit for but I may not be using 
the proper terminology to get the answers that I am looking for.

I have a QWidget (say a button) in QWindow "A" and I want to perform a drag 
action from that QWidget onto another QWidget in another QWindow "B" (So far 
easy stuff). What I would like to also do while I am dragging is continuously 
draw a nice stylized line from the current location of the mouse back to the 
QWidget where the drag started. Is this even possible? I can't seem to figure 
out if the line would ONLY be drawn inside the QWindows and NOT outside? And if 
that is the case I would assume that I then need to rely on "native" code for 
each platform to perform the drawing? If anybody has a working example of this 
kind of interaction that would also be much appreciated.

Thanks
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


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

[Interest] ComboBox and Menu Changes in Qt 5.10 vs Qt 5.9.x

[Michael Jackson]

I have been testing our application against Qt 5.10.0 and I noticed some visual 
anomalies that I am unsure are bugs or intended design.

The issues are with a QMenu attached to a QButton. In Qt 5.9.x there is a 
little triangle that denotes the menu. In Qt 5.10 there is a much larger "Down 
Chevron". Mainly the image is just too large. We may have to adjust our height 
and width a bit.

The next issue is with the embedded menus. If there is a submenu, the small 
"triangles" indicating that there is a submenu do not show up. Screenshots are 
attached. Maybe there is a new property with Qt 5.10 that we missed that 
addresses this? This was on macOS 10.12 "Sierra" using prebuilt Qt from the 
official download site.

Thanks for any help or clarifications.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net

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

[Interest] Qt5.9 installer's default package selection

[Michael Jackson]

I have noticed in the Qt 5.9 installer (at least for macOS and Linux) that when 
the "wizard" gets to the package selection page the ONLY thing that is by 
default selected is QtCreator and QtSpeech. *Nothing* else is selected? Curios 
as to the reasoning behind this setting. I would almost rather have it install 
everything versus nothing. We have an IT department that just blindly installs 
Qt and we have to call them back to instruct them to click some more buttons 
during the installation.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


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

[Michael Jackson]

Replace "Business" with your choice of:
   Development Group, Individual, Corporation, LLC, Developers in a Room, Grad 
Students, etc.

At some point, supporting "older**" operating systems becomes a detriment to a 
project. You spend more time trying to keep the older systems running using 
outdated compilers and tools than creating new features or fixing other bugs. 
Again, there are reasons to both SUPPORT and NOT to support those systems and 
to each developer their reasons are valid. In a utopian world, all the tool 
vendors/groups would *always* back port their latest and greatest tools to the 
oldest operating systems. But from my 20+ years of experience, this just does 
not happen. Tool/Compiler/Library vendors move their tools forward with new 
features and drop support for "older" operating systems which brings about the 
question that the OP had.

I think your interpretation of a "business" is different than mine? Not sure 
what you mean by your #2 statement? 


** Older is completely arbitrary at this point.
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net

-Original Message-
From: Konstantin Tokarev <annu...@yandex.ru>
Date: Wednesday, November 29, 2017 at 11:24 AM
To: Michael Jackson <mike.jack...@bluequartz.net>, "interest@qt-project.org" 
<interest@qt-project.org>
Subject: Re: [Interest] minimum macOS runtime version for Qt 5.9+



29.11.2017, 19:09, "Michael Jackson" <mike.jack...@bluequartz.net>:
> I vote NOT to. -1. Each business has to decide at what point is 
supporting the older hardware detrimental to their bottom line. For my 
business, I drew the line at 2 major releases behind Apple which aligns well 
with Qt. I service higher education and govt labs where people stay with 
hardware as long as possible for personal or corporate IT reasons. I weighed 
servicing those few clients with NOT having access to things like newer C++11 & 
C++14 because I had to support those older compilers and for my business that 
just didn't make sense. We _want_ to use the newer enhancements to C++ to make 
our developing lives easier and create more solid and stable code that the 
newer C++ and tooling brings. I communicate well in advanced our plans so that 
it isn't a "secret" to anyone. I recognize that _your_ business may have 
different needs and reasons than mine. There is no "correct" answer in this 
discussion. I just need a clear road map from Qt about what versions of Qt will 
su
 pport
>  which operating systems so that I can plan accordingly, and I have not 
had a problem getting that information.
>
> We also had a MacPro4,1 (2009 era, Dual Quad Core) that could not be 
upgraded to macOS Sierra so we turned it into a nice Windows 10 workstation 
instead. Total Cost $150 for the Windows 10 Pro license. Linux would have 
worked also. Those "cheese grader" MacPro machines just keep going. Nothing 
wrong with them.

You seem to ignore facts that
1) many people don't use Qt for business reasons but have completely 
different motivation
2) Qt Project itself is not a business project

    But, as Thiago said, there is no need to vote (because Qt Project is not a 
democracy either)

>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net
>
> -Original Message-
> From: Interest 
<interest-bounces+mike.jackson=bluequartz@qt-project.org> on behalf of 
Pavel Mogilevskiy <pmogilevs...@gmail.com>
> Date: Wednesday, November 29, 2017 at 8:33 AM
> To: "coroberti ." <corobe...@gmail.com>, Hamish Moffatt 
<ham...@risingsoftware.com>, "interest@qt-project.org" <interest@qt-project.org>
> Subject: Re: [Interest] minimum macOS runtime version for Qt 5.9+
>
> +1
>
> Same here. We have users which don't have a chance for some reasons to
> upgrade to the latest OS X version, therefore we are using Qt 5.8
> (instead of Qt 5.9 LTS which we are using across other OSs) to support
> at least OSX 10.9.
>
> So I vote for support older OS X versions as long as possible.
>
> On 11/29/2017 3:08 PM, coroberti . wrote:
> > On Wed, Nov 29, 2017 at 2:22 PM, Hamish Moffatt
> > <ham...@risingsoftware.com> wrote:
> >> On 29/11/17 14:46, Jake Petroules wrote:
> >>> Why do you need to support older versions?
> >> Because my customers are using them, right back to 10.7. They are
> >> educational institutions with whole labs of machines set up the 
sam

Re: [Interest] minimum macOS runtime version for Qt 5.9+

[Michael Jackson]

I vote NOT to. -1. Each business has to decide at what point is supporting the 
older hardware detrimental to their bottom line. For my business, I drew the 
line at 2 major releases behind Apple which aligns well with Qt. I service 
higher education and govt labs where people stay with hardware as long as 
possible for personal or corporate IT reasons. I weighed servicing those few 
clients with NOT having access to things like newer C++11 & C++14 because I had 
to support those older compilers and for my business that just didn't make 
sense. We _want_ to use the newer enhancements to C++ to make our developing 
lives easier and create more solid and stable code that the newer C++ and 
tooling brings. I communicate well in advanced our plans so that it isn't a 
"secret" to anyone. I recognize that _your_ business may have different needs 
and reasons than mine. There is no "correct" answer in this discussion. I just 
need a clear road map from Qt about what versions of Qt will support 
 which operating systems so that I can plan accordingly, and I have not had a 
problem getting that information.

We also had a MacPro4,1 (2009 era, Dual Quad Core) that could not be upgraded 
to macOS Sierra so we turned it into a nice Windows 10 workstation instead. 
Total Cost $150 for the Windows 10 Pro license. Linux would have worked also. 
Those "cheese grader" MacPro machines just keep going. Nothing wrong with them.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net

-Original Message-
From: Interest <interest-bounces+mike.jackson=bluequartz@qt-project.org> on 
behalf of Pavel Mogilevskiy <pmogilevs...@gmail.com>
Date: Wednesday, November 29, 2017 at 8:33 AM
To: "coroberti ." <corobe...@gmail.com>, Hamish Moffatt 
<ham...@risingsoftware.com>, "interest@qt-project.org" <interest@qt-project.org>
Subject: Re: [Interest] minimum macOS runtime version for Qt 5.9+

+1

Same here. We have users which don't have a chance for some reasons to 
upgrade to the latest OS X version, therefore we are using Qt 5.8 
(instead of Qt 5.9 LTS which we are using across other OSs) to support 
at least OSX 10.9.

So I vote for support older OS X versions as long as possible.


On 11/29/2017 3:08 PM, coroberti . wrote:
> On Wed, Nov 29, 2017 at 2:22 PM, Hamish Moffatt
> <ham...@risingsoftware.com> wrote:
>> On 29/11/17 14:46, Jake Petroules wrote:
>>> Why do you need to support older versions?
>> Because my customers are using them, right back to 10.7. They are
>> educational institutions with whole labs of machines set up the same way 
-
>> they probably get one chance a year to upgrade, and for whatever reason 
they
>> haven't so far. I can't stick to old Qt versions either because of 
various
>> bugs. 5.6 LTS has issues with accessibility crashes on newer macOS. 5.8 
is
>> crashing in file open dialogs on 10.13. Thus I'm stuck.
> Exactly, my case with edu users.
> They are using Mac HW for up to 10 years.
> About 1/3 is not upgradeable anymore: 10.7 and 10.8
>
>> I wish there was a bit more of a time window before you deprecate old
>> versions. 10.7 is no older than Windows 7.
> +1
>
> Kind regards,
> Robert
> ___
> 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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QT 5.9.2 Release schedule

[Michael Jackson]

Will the 5.9.2 release have the macOS 10.13 bugs fixed? 

I have been trying to track through all the bug reports but not sure if I have 
verified it or not by myself.

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net

-Original Message-
From: Interest <interest-bounces+mike.jackson=bluequartz@qt-project.org> on 
behalf of Andy <asmalo...@gmail.com>
Date: Thursday, October 5, 2017 at 8:39 AM
To: "Satunin, Konstantin" <konstantin.satu...@intel.com>
Cc: "interest@qt-project.org" <interest@qt-project.org>
Subject: Re: [Interest] QT 5.9.2 Release schedule

Konstantin:


You can see the high-level release plan for 5.9 here:

  https://wiki.qt.io/Qt_5.9_Release


And for more fine-grained information, you can watch the release mailing 
list:

  http://lists.qt-project.org/pipermail/releasing/


According to the latter:

  "Target to get final packages for sanity checking Wed 4th October & get 
the release out during this week if nothing really serious found."


---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney <https://twitter.com/asmaloney>










On Wed, Sep 20, 2017 at 7:37 AM, Satunin, Konstantin 
<konstantin.satu...@intel.com> wrote:

Hi All,
 
We are interested in the bug fix for memory leak 
https://bugreports.qt.io/browse/QTBUG-61754 
<https://bugreports.qt.io/browse/QTBUG-61754> which will be available in 5.9.2 
release.
QT 5.9.2 snapshot version is available since August 30, and QT 5.10 Alpha 
was released last week.
 
Can anybody estimate when 5.9.2 might be released?  
Is it still according to the planned “September 2017” window (only 2 weeks 
left)?
 
Best wishes,
Satunin, Konstantin (Keeper)
SSG - Sensor Developer Products
 



Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


___
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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Flickering when animating QWidget resize

[Michael Jackson]

We also tried an OpenGLWidget with an image being rendered by OpenGL but we 
still get flicker. We are trying to embed the widget in a QScrollArea and then 
resize the QScrollArea any maybe that gives us a reasonable effect.

I would go down the QML road but we would have to port quite a number of custom 
QWidgets to QML to be able to display what we need. I think in the end we will 
rethink the UX and not have anything "Flashy" in our QWidgets based app.

I do appreciate everyone's thoughts and suggestions.

---
Mike Jackson

On 8/25/17, 4:00 PM, "Interest on behalf of Konstantin Tokarev" 
<interest-bounces+mike.jackson=bluequartz@qt-project.org on behalf of 
annu...@yandex.ru> wrote:


25.08.2017, 22:45, "André Pönitz" <apoen...@t-online.de>:
> On Fri, Aug 25, 2017 at 10:26:22AM -0700, Thiago Macieira wrote:
>>  On Friday, 25 August 2017 09:26:22 PDT Michael Jackson wrote:
>>  > In our application, we are attempting to create a "fly out" effect with a
>>  > QWidget based window and when the animation happens the QWidget flickers
>>  > badly. We are usig QProperty animation in an attempt to achieve the 
>> effect.
>>  > Is this not a good idea? Is there a setting that we are missing perhaps?
>>
>>  It's not a good idea to animate QWidgets. They were not designed for that.
>
> And still it works.
>
>>  At the very least, make your animations inside a QGraphicsView. Better yet,
>>  use QML and/or OpenGL.
>
> Simply calling QWidget::update() from a timer works just fine for
> simple effects like e.g. the hover effect on the Examples and
> Tutorials pages on Qt Creator's Welcome screen.
>
> There's no need for QGraphicsView, let alone OpenGL for that.

Still, animations with "moving widgets" work better when there are no really 
moving widgets,
e.g. when widgets content is renderend into image/pixmap before animation 
starts.
Bonus points if this image/pixmap is somehow "hw-accelerated" to achieve fast 
blits.

All this stuff is not easy to get right from the start, and on many devices 
including modern PCs
and many embedded things the only way to achieve this kind of "acceleration" is 
OpenGL

>
> Andre'

-- 
Regards,
Konstantin



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

[Interest] Flickering when animating QWidget resize

[Michael Jackson]

In our application, we are attempting to create a "fly out" effect with a 
QWidget based window and when the animation happens the QWidget flickers badly. 
We are usig QProperty animation in an attempt to achieve the effect. Is this 
not a good idea? Is there a setting that we are missing perhaps?

Thanks for any help.

--
Michael Jackson
BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net


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

Re: [Interest] Mac: a bit of 10.9 love

[Michael Jackson]

I am curious to find out just how many customers of your application 
there are that are _still_ on macOS 10.9?


Even if it is just a few why are you letting just a few customers hold 
you back from using newer compilers, versions of C++, newer tools. Why 
are you letting those few customers make you take your valuable time to 
backport all this stuff? Unless those are customers that are paying you 
a lot of money to keep the compatibility or there is a hard contractual 
requirement to keep the compatibility...


In our own project we tried to maintain that backward compatibility but 
we finally realized that we were just holding ourselves back because we 
didn't have access to all the new C++ features in C++11, 14 and upcoming 
17 specs that we wanted to use. Both to code more efficiently and to 
make our lives easier. We just started punting old compilers and support 
for those. We did one last release based on the older libraries, 
informed our users of the migration to newer tools and have not looked back.


--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net


René J.V. Bertin wrote:

On Thursday August 03 2017 17:11:56 Allan Sandfeld Jensen wrote:


Didn't Qt only drop support for building on 10.9? I am pretty sure
you should be able to build on 10.10+ and deploy to 10.9 if you
wish. Though I can see


Nope, sadly that's not the case (and I doubt it was the intention
either). You can still install Qt 5.9.1, once you figure out how to
run the installer - last time I tried even the MaintenanceTool.app
insisted on self-updating to a new version that crashed immediately
because of missing symbols referenced from the cocoa QPA. I filed a
QTBUG-61800 about that because it made it impossible to update even
supported Qt versions on OS versions not supported by the latest Qt
version.

The workaround trick I found was to force Qt to use the generic Unix
QPA, which is good enough for basic installers but evidently not for
a meaningful user experience.

On Thursday August 03 2017 15:14:52 Alexandru Croitor wrote:

Iirc the minimum deployment version was bumped to 10.10 in qt 5.9.
That was also a change we had to do in webengine


I'm expecting to run into>=10.10 requirements elsewhere in Qt 5.9
when I get around to building it, and I was already afraid that QWE
would require more attention than I really care to give it (it's way
too big to start hacking around in) ... But, "had to" as in "were
obliged to" rather than "chose to"? Why - the BT code that already
required using the 10.10 SDK maybe? All incompatibilities I've seen
in the style and QPA were quite trivial to address (except for those
requiring the "full" 10.10 SDK which 10.9 never got).

With some luck it will still be possible to build QWE 5.8 against Qt
5.9 though, should there be too much to reintroduce (and I wouldn't
mind either dropping BT support either in my build).

R. ___ 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] Headless Install of Qt using a JavaScript File

[Michael Jackson]

I am updating our script file for installing Qt 5.9.1 in an automated 
fashion. We do this by calling the installer with the --script argument. 
Generally works great for the default install. I would like to customize 
the install to remove some of the components. At one point I had code 
like this in my .js file:


widget.deselectComponent("qt.55.qtquick1");
widget.deselectComponent("qt.55.qtscript");
widget.selectComponent("qt.56.qtwebengine");

What values do I use for Qt 5.9.x?

Is there a way to find out what the possible values are? I tried 
guessing at them but what I think are obvious ideas did not work. I want 
to only install qtwebengine and the macOS component. I don't need the 
iOS or Android or any of the "TP" components.


I tried looking through the download.qt.io website by hand looking for a 
meta.xml file or something like that.


Any help is much appreciated.


--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Debugging in Qt Creator and displaying Qt objects d_ptr members in watch window ?

[Michael Jackson]

On Sep 17, 2015, at 11:50 AM, John Weeks  wrote:

> We use our own build of Qt 5.5, including a debug build. Debugging is often 
> painfully slow but mostly works. And with a debug build of Qt we can step 
> into Qt code and (usually) inspect d pointers.
> 
> Be sure that you have gone into the Projects tab in Qt Creator, select the 
> Run half of the button for the kit you're using and turn on the checkbox "Use 
> debug version of frameworks"
> 
> 
> 
> Who else thinks that black Build button looks selected? But it's not- the Run 
> button is active!
> 
> -John Weeks
> WaveMetrics, Inc.

I had not thought about trying the debug versions of the frameworks but I don't 
think (for us) it is the issue. We can not even debug our _own_ codes, let 
alone anything from Qt, but maybe the debug versions have something to do with 
it? Worth a try. Of course trying to build Qt isn't as easy as it used to be 
back in the 4.x days. We depend on QtWebEngine so there is all of that. And our 
packaging system depends on an installation from Digia, not a home built 
installation. I'll have to setup a couple of different sandboxes. One with our 
build and one with the official Digia builds.

Not that I expect this to help at all. The LLDB integration 
is just plain is buggy. I'll assume none of the pertinent developers at Digia 
actually use LLDB to debug. I bet they all use GDB because the LLDB integration 
sucks. Such an evil circle to be in. Clearly no "dog fooding" going 
on.

And yes, the nightly builds of QtCreator are buggy. There is a crasher in the 
Clang code model where it tries to supply the editor with a completion hint but 
crashes instead. And then the editor just gets slower and slower as you type. I 
found a build from Sept 10 that _mostly_ works, at least the editing mostly 
works. Only crashes a few times an hour. Just remember to "save often".

--
Mike Jackson

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

Re: [Interest] Debugging in Qt Creator and displaying Qt objects d_ptr members in watch window ?

[Michael Jackson]

On Sep 17, 2015, at 9:45 AM, Edward Sutton  wrote:

> I spend too much time adding qDebug() statements because Qt objects d_ptr 
> members are invisible to the debugger.
> 
> I use Qt 5.5 Enterprise pre-built to debug OS X, Android, iOS, and on Windows 
> ( MSVC 2013 ).
> 
> Is the only solution to build Qt from source for all 4 platforms ? 
> 
> -Ed
> 

Does building from source actually help? Our team has found the debugging 
situation on OS X basically hopeless. For general debugging we move to Xcode 
where the debugging in stable BUT you can not really inspect any Qt variables 
except for QString. 

If we really need to debug Qt specific variables then we move the whole session 
to Windows and Visual Studio 2013 with the Qt plugin. The debugging experience 
there is the best all around that we have found.

We tried linux with LLDB but the root of the problem is the LLDB integration. 
It just does not work for what ever reason. Variables passed in by reference 
can not be inspected in the debugger. If you try to step "to fast" then LLDB or 
the LLDB Bridge code just hangs. If you "step" before the debugger has loaded 
the symbols then LLDB or the LLDB bridge hangs. If you step, but LLDB or the 
LLDB Bridge is still loading the variables view and you decide to step again, 
then everything hangs.

So basically if you want to really debug there are 2 solutions:
Windows with Visual Studio
Linux with GDB.

LLDB is just out. Xcode, Eclipse, CLion are NOT able to show Qt Variables in 
the debugger. All of the above are with nightly and release versions of 
QtCreator starting at 3.5.0 and newer.

Don't mean to be a complainer here, but just stating the situation as I have 
experienced it since last year. I wonder how much financial resources it would 
take to "purchase" the appropriate Digia engineer for a set amount of time to 
dedicate to fixing these issues?

--
Mike Jackson
Owner, BlueQuartz Software, LLC
Springboro OH USA.

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

[Interest] Application at Idle takes 10% of CPU

[Michael Jackson]

Our application seems to take more cpu than I think it should while just 
sitting Idle. My machine is a MacBook Pro 2.6GHz Core i7 with 16GB Ram. 
Running OS X 10.8.5. Using the Activity Monitor our application takes about 
10-12% of my CPU time. Using the Instruments application to get the heaviest 
functions I see that QImage::copy is taking up a bunch of time:

Running TimeSelfSymbol Name
2218.0ms   57.2%2218.0  QImage::copy(QRect const) const
2218.0ms   57.2%0.0  QImage::detach()
2218.0ms   57.2%0.0   QPainter::begin(QPaintDevice*)
2218.0ms   57.2%0.0
QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, int, 
QPainter*, QWidgetBackingStore*)
2218.0ms   57.2%0.0 QWidgetBackingStore::doSync()
2218.0ms   57.2%0.0  QWidgetBackingStore::sync()
2218.0ms   57.2%0.0   QWidgetPrivate::syncBackingStore()
2218.0ms   57.2%0.0QWidget::event(QEvent*)
2218.0ms   57.2%0.0 QMainWindow::event(QEvent*)
2218.0ms   57.2%0.0  
QApplicationPrivate::notify_helper(QObject*, QEvent*)
2218.0ms   57.2%0.0   
QApplication::notify(QObject*, QEvent*)
2218.0ms   57.2%0.0
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
2218.0ms   57.2%0.0 
QCocoaEventDispatcherPrivate::processPostedEvents()
2218.0ms   57.2%0.0  
QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*)
2218.0ms   57.2%0.0   
QCocoaEventDispatcher::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
2218.0ms   57.2%0.0
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
2218.0ms   57.2%0.0 QCoreApplication::exec()
2218.0ms   57.2%0.0  main
0.0ms0.0%   0.0   Main Thread  0x2f66d0

I figured it was one of our custom paint methods. I went  through our project 
and systematically commented out all of our custom painting codes and there was 
no change. We do use a lot of CSS to style our widgets. Would that account for 
the high CPU usage? This is with Qt 5.4.1 downloaded from Qt.io.

QTimers maybe? We do some animations using QTimer, though that is supposed to 
be on-demand, i.e. it is not a continuous animation.

I replicated the issue on OS X 10.10 with Qt 5.4.2 on that system. As a sanity 
check, QtCreator uses 0% while Idle. So I must be something that we are doing 
wrong in our app. Our application on Windows does not seem to have this issue 
either.

Thanks for any help or insights.
Mike Jackson
BlueQuartz Software
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Application at Idle takes 10% of CPU

[Michael Jackson]

I have tracked it down to our use of a QSplitter. If I hide our left side 
then the CPU usage drops to 0~1% while idle. There is a QFrame Derived custom 
class that is placed into the left side but that custom widget does not do any 
custom painting that I am aware of. Still digging…

Thanks
Mike Jackson

On Jun 27, 2015, at 10:58 AM, Michael Jackson imikejack...@gmail.com wrote:

 Our application seems to take more cpu than I think it should while just 
 sitting Idle. My machine is a MacBook Pro 2.6GHz Core i7 with 16GB Ram. 
 Running OS X 10.8.5. Using the Activity Monitor our application takes about 
 10-12% of my CPU time. Using the Instruments application to get the 
 heaviest functions I see that QImage::copy is taking up a bunch of time:
 
 Running Time  SelfSymbol Name
 2218.0ms   57.2%  2218.0  QImage::copy(QRect const) const
 2218.0ms   57.2%  0.0  QImage::detach()
 2218.0ms   57.2%  0.0   QPainter::begin(QPaintDevice*)
 2218.0ms   57.2%  0.0
 QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, int, 
 QPainter*, QWidgetBackingStore*)
 2218.0ms   57.2%  0.0 QWidgetBackingStore::doSync()
 2218.0ms   57.2%  0.0  QWidgetBackingStore::sync()
 2218.0ms   57.2%  0.0   QWidgetPrivate::syncBackingStore()
 2218.0ms   57.2%  0.0QWidget::event(QEvent*)
 2218.0ms   57.2%  0.0 QMainWindow::event(QEvent*)
 2218.0ms   57.2%  0.0  
 QApplicationPrivate::notify_helper(QObject*, QEvent*)
 2218.0ms   57.2%  0.0   
 QApplication::notify(QObject*, QEvent*)
 2218.0ms   57.2%  0.0
 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
 2218.0ms   57.2%  0.0 
 QCocoaEventDispatcherPrivate::processPostedEvents()
 2218.0ms   57.2%  0.0  
 QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*)
 2218.0ms   57.2%  0.0   
 QCocoaEventDispatcher::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
 2218.0ms   57.2%  0.0
 QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
 2218.0ms   57.2%  0.0 QCoreApplication::exec()
 2218.0ms   57.2%  0.0  main
 0.0ms0.0% 0.0   Main Thread  0x2f66d0
 
 I figured it was one of our custom paint methods. I went  through our project 
 and systematically commented out all of our custom painting codes and there 
 was no change. We do use a lot of CSS to style our widgets. Would that 
 account for the high CPU usage? This is with Qt 5.4.1 downloaded from Qt.io.
 
 QTimers maybe? We do some animations using QTimer, though that is supposed to 
 be on-demand, i.e. it is not a continuous animation.
 
 I replicated the issue on OS X 10.10 with Qt 5.4.2 on that system. As a 
 sanity check, QtCreator uses 0% while Idle. So I must be something that we 
 are doing wrong in our app. Our application on Windows does not seem to have 
 this issue either.
 
 Thanks for any help or insights.
 Mike Jackson
 BlueQuartz Software

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

Re: [Interest] Application at Idle takes 10% of CPU

[Michael Jackson]

Found IT!!. It is a QProgressBar that we are showing even though it has a value 
of 0. if I manually hide it until we start our progress then my applications 
Idle time goes to near 0%.

Seems like a pretty high CPU usage for just putting a QProgressBar into a UI.

Mike Jackson


On Jun 27, 2015, at 11:27 AM, Michael Jackson imikejack...@gmail.com wrote:

 I have tracked it down to our use of a QSplitter. If I hide our left side 
 then the CPU usage drops to 0~1% while idle. There is a QFrame Derived custom 
 class that is placed into the left side but that custom widget does not do 
 any custom painting that I am aware of. Still digging…
 
 Thanks
 Mike Jackson
 
 On Jun 27, 2015, at 10:58 AM, Michael Jackson imikejack...@gmail.com wrote:
 
 Our application seems to take more cpu than I think it should while just 
 sitting Idle. My machine is a MacBook Pro 2.6GHz Core i7 with 16GB Ram. 
 Running OS X 10.8.5. Using the Activity Monitor our application takes about 
 10-12% of my CPU time. Using the Instruments application to get the 
 heaviest functions I see that QImage::copy is taking up a bunch of time:
 
 Running Time SelfSymbol Name
 2218.0ms   57.2% 2218.0  QImage::copy(QRect const) const
 2218.0ms   57.2% 0.0  QImage::detach()
 2218.0ms   57.2% 0.0   QPainter::begin(QPaintDevice*)
 2218.0ms   57.2% 0.0
 QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, 
 int, QPainter*, QWidgetBackingStore*)
 2218.0ms   57.2% 0.0 QWidgetBackingStore::doSync()
 2218.0ms   57.2% 0.0  QWidgetBackingStore::sync()
 2218.0ms   57.2% 0.0   QWidgetPrivate::syncBackingStore()
 2218.0ms   57.2% 0.0QWidget::event(QEvent*)
 2218.0ms   57.2% 0.0 QMainWindow::event(QEvent*)
 2218.0ms   57.2% 0.0  
 QApplicationPrivate::notify_helper(QObject*, QEvent*)
 2218.0ms   57.2% 0.0   
 QApplication::notify(QObject*, QEvent*)
 2218.0ms   57.2% 0.0
 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
 2218.0ms   57.2% 0.0 
 QCocoaEventDispatcherPrivate::processPostedEvents()
 2218.0ms   57.2% 0.0  
 QCocoaEventDispatcherPrivate::postedEventsSourceCallback(void*)
 2218.0ms   57.2% 0.0   
 QCocoaEventDispatcher::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
 2218.0ms   57.2% 0.0
 QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
 2218.0ms   57.2% 0.0 QCoreApplication::exec()
 2218.0ms   57.2% 0.0  main
 0.0ms0.0%0.0   Main Thread  0x2f66d0
 
 I figured it was one of our custom paint methods. I went  through our 
 project and systematically commented out all of our custom painting codes 
 and there was no change. We do use a lot of CSS to style our widgets. Would 
 that account for the high CPU usage? This is with Qt 5.4.1 downloaded from 
 Qt.io.
 
 QTimers maybe? We do some animations using QTimer, though that is supposed 
 to be on-demand, i.e. it is not a continuous animation.
 
 I replicated the issue on OS X 10.10 with Qt 5.4.2 on that system. As a 
 sanity check, QtCreator uses 0% while Idle. So I must be something that we 
 are doing wrong in our app. Our application on Windows does not seem to have 
 this issue either.
 
 Thanks for any help or insights.
 Mike Jackson
 BlueQuartz Software
 

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