Re: [Interest] Hardware accelerated rendering in Qt 5.12.7

2020-04-03 Thread Ramakanth Kesireddy
Is there any attribute that can be set in QWidget which could use hardware
accelerated graphics or opengl paint device in Qt 5.12.7 without changing
the custom widgets deriving from QWidget?

On Tue, 4 Feb, 2020, 13:52 Allan Sandfeld Jensen,  wrote:

> On Dienstag, 4. Februar 2020 03:26:12 CET Ramakanth Kesireddy wrote:
> > Hi,
> >
> > Our existing application is based on c++ widgets(QWidget) using QPainter
> on
> > Qt 5.13. As i understand Qpainter uses raster engine for graphics
> > rendering, Is there any means to make use of hardware accelerated
> > rendering(GPU) other than changing the complete Application code into Qt
> > quick or QGLWidget?
> >
> You can create a QOpenGLWindow or QOpenGLWidget and paint therein.
>
> You can also use QGraphicsView with a QOpenGLWidget as a viewport.
>
> In both cases an accelerated QPainter would then be used.
>
> 'Allan
>
>
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

2020-04-03 Thread Matthew Woehlke
On 02/04/2020 01.39, Tuukka Turunen wrote:
> I know licensing in general can be a challenging topic, but I can't 
> help thinking if some people are intentionally trying to twist
> things around. At least there are quite many who have not been
> talking about this in a friendly tone.

For me, personally, I'm not (intentionally) trying to twist anything...
but "less than friendly"? Sure.

Why? Because every time licensing comes up on the mailing lists, we seem
to get the same answers: "it depends on the particulars of the case" and
"talk to your lawyer". And over and over, I see the same reaction: "we
will no longer use or recommend Qt". (Moreover, this is *in addition* to
technical concerns that various folks, myself included, have expressed.)

This creates an impression that Qt commercial licensing is a legal
minefield, which scares off some people. Some of the "gotchas", combined
with other recent actions (installers requiring an account) creates an
impression of a TQtC that is not particularly friendly to the OSS community.

Is it any wonder people are reacting with a "less than friendly"
attitude? TQtC is coming across as increasingly adversarial; it's no
wonder the community is becoming adversarial right back. In political
terms, recent actions have resulted in a significant drop in TQtC's
approval rating, at least with the OSS community.

If you / TQtC can't understand why this is, well, that's part of the
problem right there.

Apparently TQtC has a healthy commercial relationship with... well,
someone. Unfortunately, Qt OSS seems to be suffering hugely.

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


[Interest] Windows 7: QLocalServer::listen fails with "QLocalServerPrivate::addListener: Access is denied" error

2020-04-03 Thread Alexander Dyagilev

Hello,

We're getting this error from some (currently 2 or 3) of our users on 
Windows 7 machines.


We can't reproduce it.

Any known reason of this? We're using Qt 5.12.7.

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


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

2020-04-03 Thread Christian Gagneraud
On Fri, 3 Apr 2020 at 19:09, Roland Hughes  wrote:
> No, that was never the point of this thread.

Me too:

My first 'commercial' Android app, made with 'pure' commercial Qt SDK,
produced its first crash report:

04-03 11:30:53.384 17079 17115 E AndroidRuntime: Process:
org.qtproject.example.TestApp, PID: 
04-03 11:30:53.384 17079 17115 E AndroidRuntime:
java.lang.UnsatisfiedLinkError: dlopen failed:
/lib/arm/libc++_static.so" has bad ELF magic


The point is not about the crash itself, that was my mistake.

The point is:
I used a 'commercial only' Qt license to produce an Android app, and
the first thing this app says starts with 'org.qtproject', not
'com.foobarbaz'.

I hope you'll find this detail funny!

Chris, NZ, day#8

PS: Please don't ignore people with dual licensed Qt installs
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


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

2020-04-03 Thread Roland Hughes


On 4/2/20 5:00 AM, Tuukka Turunen wrote:

Unless you are in the situation described by the person who originated this 
email thread, I am rather sure you can continue using the GPL version of 
Creator.

The whole point of this email thread was situations where the same development 
project team (creating the same product) would like to mix commercially and 
open-source licensed Qt frameworks or tools. This is not allowed, but also not 
the most common case. Typically either commercial or open-source version of Qt 
is used, which is the way indented.


No, that was never the point of this thread.

    > Correct. All users need to have commercial license. It is not 
allowed for part of the team to use commercial and part use open-source. 
Even though Qt Creator is great, it can feel odd to pay for full Qt 
license and only use the Creator IDE.

    >
    > We have been thinking about selling Qt Creator separately, but so 
far no decisions made on this.


That was the point of this thread. The rest was determining the scope 
because "project" and "company" were tossed around interchangeably.


As to "not answering questions" I assume that was my very relevant 
question about Thiago. If one or more developers at some obscure Intel 
office buy a commercial Qt license does Thiago now have to pay for the 
privilege of working for free?


I haven't noticed an actual answer to that.

As to having all developers on a project using the same IDE, this 
happens almost constantly. In some large companies they let developers 
working on different parts of the project use whatever editor they like 
and they end up with problems. I'm talking about more than just TAB 
sizes and settings.


Code templates come to mind. While in C/C++ world most of these tend to 
be the differing legaleeze comment blocks inserted at the top of Header 
and Source files for other languages they are more involved. Trying to 
keep them consistent across multiple IDEs is a serious issue in the 
medical device world. You can't just paste them in at the end because of 
the formal FDA review process. They had to be in the code and verified 
before QA began formal testing.


Artistic Style (or whatever) coding style enforcement. Many shops use 
the BAAR Standard. If you are using multiple IDEs with multiple hooks 
and required names/locations for the style file they inevitably get out 
of sync and you fail the formal external review, or worse, introduce a 
sleeping bug. Contrary to popular belief those things aren't there just 
to make the code look pretty. Many are there to expose sleeping bugs.


if (a==0)

    do_something();

    do_something_else();

When you use the style manager and BAAR Standard of forcing {} around 
single line blocks it becomes obvious that do_something_else() is 
outside of the if. The indenting seems to indicate someone got in a 
hurry and meant for both to be part of the if. Depending on what 
do_something_else() does this could be a bug that sits out there for 
years in production until it kills someone. Hopefully it does something 
really important and gets caught during formal testing, but I've seen 
too much of this to believe that.


For a time there was a Qt plug-in for Eclipse. Many shops standardized 
on Eclipse, not because it was great, but because it worked well for the 
board level people writing firmware, the device driver developers, and 
with that plugin, well enough for the Qt developers. This meant you 
could formally enforce the coding standards and TAB definitions across 
an entire project. Other shops standardized on Emacs (pre-doxygen wide 
acceptance days) because the word processing capabilities combined with 
template text files that would prompt users for template values when 
creating the document shell, made it easy to keep their project 
documentation complete and in the same source management library.


To really comprehend the importance of this you need to have worked on 
projects in a regulated industry having 50-60 developers. Keeping things 
in sync is mandatory for that approval step where an independent company 
must be able to recreate your development environment from your 
documentation and build your system for deployment. That's an actual 
requirement. For those watching the U.S. News and the invocation of The 
War Powers Act, you can now understand why it exists.


https://www.autoblog.com/2020/03/18/coronavirus-ford-gm-could-build-ventilators/

Automobile manufacturers are being pressed into service to build 
ventilators. They have factories and workers but no medical device 
knowledge. Because of that requirement, in a scant couple of weeks, they 
will be able to build ventilators at the same speed they build Buicks 
and SUVs. Expect a similar order to come down soon for battery powered 
infusion pumps so patients who just need liquid drugs and other fluids 
combined with bed rest can be sent home, freeing up hospital beds and 
reducing hospital risk.


The other question I