Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 27.10.22 um 12:46 schrieb Benjamin B (BBenj):

Hello,

Not sure if it was mentioned, but you can also copy the QSQLite 
plugin, change its name and build it with SQLite and all the options 
you need. Then use it as a Qt SQL plug-in and load it instead of the 
default one.


Thank you for that suggestion, that seems to be indeed a viable option 
(besides linking with the "amalgamation code" and adding the required 
functions via sqlite3_create_function - and probably a bit more 
reliable, too, with respect to "version matching").


In the future the binary distribution of the upcoming Qt 6.5 will enable 
the "math" (and other) functions as well in the Qt SQlite plugin.


Cheers, Oliver

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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 26.10.22 um 19:35 schrieb Mike Chinander:
I think it would be nice to have these math functions generally 
available in queries, but I would like to point out that in your 
example code, the angle you are taking the cosine of is a constant 
rather than a value retrieved from the DB.


Uhm... yeah ;)

Maybe I should have used the well-known value "42" to make it more 
obvious that this query was merely meant for "illustrative purposes" ;) 
It is not my "real-world query", to be clear.


Cheers, Oliver

P.S. But indeed, I used this query to quickly test the existence of 
"math functions" via "DB Browser for SQLite". The used "hard-coded" 
coordinates are *very* roughly where I live ;)


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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 26.10.22 um 18:23 schrieb Thiago Macieira:

On Wednesday, 26 October 2022 07:29:15 PDT Till Oliver Knoll wrote:

I have "github actions" that make it very easy to install a
given "stock binary Qt release" on the desired integration platform

Then please ask whoever is providing those binaries to you to enable the math
functions.


I did. "Ask and you shall receive":

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

:)

Qt 6.5 will provide a Qt SQLite plugin with math (and other) functions 
enabled.


Cheers, Oliver

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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 26.10.22 um 16:01 schrieb Till Oliver Knoll:


I just created a suggestion report here, if anyone wants to contribute 
information about those "math functions":


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


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


That was... quick :)

Thanks!

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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 25.10.22 um 21:49 schrieb Thiago Macieira:

On Monday, 24 October 2022 10:58:56 PDT Till Oliver Knoll wrote:

What is the least complicated way to enable the math functions that come
with SQLite, when it is compiled with the -DSQLITE_ENABLE_MATH_FUNCTIONS
switch?

Solution #1: compile Qt with -system-sqlite (and provide said system sqlite).


Recompiling Qt is something that I try to avoid for now - especially 
given that I have "github actions" that make it very easy to install a 
given "stock binary Qt release" on the desired integration platform 
(that I currently only use for "code analysis", but not actually 
building any binaries - "nightly builds" - meant for distribution).


Or in other words: I am trying to keep my "required build setup" as 
simple as possible.


So compiling the "SQLite amalgation" sources (sqlite3.h, sqlite3.c) 
together with my app and use the *sqlite3_create_function* to add the 
desired "sin, cos and pow" etc. functions seems to be "the lesser evil" 
- albeit also way more fragile (keyword: "SQLite versions need to 
match") than properly recompiling Qt / the Qt SQLite plugin with my own 
desired flags.



This applies to ANY use of SQLite, whether you need the math functions or not.


I am not quite sure whether I understand this statement: what exactly 
does apply to "any use of SQLite"? For instance I can perfectly use the 
provided stock binary Qt SQLite plugin on all platforms (for me: 
Windows, macOS, Linux), without having to recompile any Qt related 
source code - for as long as I am not using math functions, of course. 
So why exactly do you say "whether you need the math functions or not"?


Best,

  Oliver

P.S. On a personal note: Hello Thiago! If there is something "more 
constant than constexpr in C++", then it is Thiago replying to all sorts 
of (broad) topics here on the list (you probably don't remember me, and 
that's okay - it's been a while since I have been actively participated 
on this list ;))
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 25.10.22 um 18:40 schrieb Christian Ehrlicher:

Am 24.10.2022 um 19:58 schrieb Till Oliver Knoll:


Dear all,

What is the least complicated way to enable the math functions that 
come with SQLite, when it is compiled with the 
-DSQLITE_ENABLE_MATH_FUNCTIONS switch?


My empirical experiments with the binary Qt 5.15.2 (open source) 
release (but also some tests with the lastest Qt 6.4 binary release, 
for either Windows or macOS) suggest that the SQLite plugin that 
ships with Qt does not enable those "built in mathematical 
functions", as described here:


https://www.sqlite.org/lang_mathfunc.html

So do I:

  * Recompile the Qt SQLite plugin, with the desired
-DSQLITE_ENABLE_MATH_FUNCTIONS flag?
  o Disadvantages (?):
  + Need to download Qt source code
  + Probably complicates the build process... (I have "build
actions" on github.com that currently "only" need to
install the binary Qt distribution)
  + Feels a bit "overkill"



From my pov this is the correct way to add new functionality to a Qt 
plugin. Even for github you can install your binary Qt distribution 
and then replace the plugin with your own.


Yes, but that would imply that I had a recompiled Qt SQLite plugin in 
the first place, and that I would then also "check-in" somehow into my 
source repository / include into the "github action build step". 
Something I'd like to avoid, if possible.


Also, I am also trying to avoid to recompile Qt on my desktop(s): it is 
a simple "one man open source app", and I try to keep the development 
process (done in my spare time) as simple as possible, for the time 
being. Or in other words: it's been more than a decade ago since I 
compiled Qt from source (what was that, perhaps Qt 4.x?), but that was 
in a "professional environment" ;) I don't even have all the required 
SKDs installed, expecially not on Windows (the target platform - because 
the given "flight simulator" runs there, too - however I mostly develop 
on macOS ;))


In short: I am looking for a solution that - if possible - avoids having 
to (re-)compile Qt from source. For no other reason other than "I am 
lazy" ;)


Are there any disadvantages when the math functions are enabled? Esp. 
regarding to speed?


I can't tell for sure, since I do have little experience with SQLite 
apart from using it, but I would not expect any speed issues when 
enabling those "math functions".


Certainly https://www.sqlite.org/lang_mathfunc.html does not mention 
anything like this. But yes, the code size would grow by some. So if the 
goal of the Qt binary distribution was "minimal size" (which I don't 
believe is a particular goal - developers that /really/ care about size 
recompile Qt anyway with their own custom options, I would expect) then 
one could argue that all external libraries would also be compiled with 
a "minimal feature set". But again, I hope that the "omission" of the 
-DSQLITE_ENABLE_MATH_FUNCTIONS 
<https://www.sqlite.org/compile.html#enable_math_functions> wasn't a 
concious choice.


But perhaps someone else with more experience with SQLite could shed 
some light on this or has some experience why enabling this "math 
option" by default could be a bad choice?



Feel free to open a bug report so we can discuss if this flag can be 
added by default.


I just created a suggestion report here, if anyone wants to contribute 
information about those "math functions":


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


Thanks for your reply!

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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 25.10.22 um 05:24 schrieb Tony Rietwyk:


Hi Oliver,

Can't answer your broader question, but I suspect the reason you are 
seeing "No query Unable to fetch row" - error code: "" is because you 
are not checking for an error after the prepare.


Oh my! I wasn't even aware that a call to QSqlQuery::prepare would 
already validate the given query! And just for my own embarassment I 
also noticed that I am even ignoring the boolean return value of that 
method. And while I do compile my application with various compilers on 
Windows, macOS and Linux and have various "Clang-Tidy and Clazy" and 
some other "modern/core C++" checks enabled, none is complaining so far 
about this "ignored return statement" so far (will go and see whether 
other checks - if enabled - will warn about this. I am pretty sure that 
there must be /some/ code validator test that checks for ignored return 
values).


(In my little defense: I am not executing any user-provided SQL. All SQL 
in my application is hand-crafted and "hardcoded" SQL, and any failure 
would indicate a "programming error" anyway, that hopefully would be 
detected during manual testing - I am talking about a "one man open 
source app", so this is acceptable for my given situation ;))


For the record, this is also (of course, as usually in an excellent 
manner) documented here, so for the record:


https://doc.qt.io/qt-6/qsqlquery.html#prepare

Even noting that "Some databases choose to delay preparing a query until 
it is executed the first time. In this case, preparing a syntactically 
wrong query succeeds, but every consecutive exec 
() will fail."


The fact that the "prepare" already validates the SQL is actually good 
news, because it could help me to "test at runtime" whether the given 
SQLite plugin would support sin(), cos() etc., and if not I could fall 
back to some simpler "distance formula".


So thank you so much to making me aware that I should - at least - also 
check the result of the prepare() statement (even if it is "hardcoded 
and tested SQL"). ;)


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

Re: [Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Am 24.10.22 um 19:58 schrieb Till Oliver Knoll:


However when compiled into my Qt 5.15.2 application with some current 
"test code" like:.


QSqlQueryquery1;
query1.setForwardOnly(true);
query1.prepare(
"selectpower(l.latitude-48.0,2)+power((l.longitude-8.0)*cos(radians(48.0)),2)dist"
"from location l;"
);
constboolsuccess=query1.exec();
 if(success){
...
}else{
qDebug()<<"SQL error:"<Just for the record: if I add the following "test code" to my own 
application:


QSqlQuery query1("select power(5, 2);"); ... ... << 
query1.lastError().text();


then I also get:

SQL error: "no such function: power Unable to execute statement" - error 
code: "1"


So it seems that when trying to generate a prepared statement the error 
message is different - but the root cause seems to be the same: "no math 
functions" available.


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

[Interest] Use SQLite math functions (-DSQLITE_ENABLE_MATH_FUNCTIONS) like sin and cos?

[Till Oliver Knoll]

Dear all,

What is the least complicated way to enable the math functions that come 
with SQLite, when it is compiled with the -DSQLITE_ENABLE_MATH_FUNCTIONS 
switch?


My empirical experiments with the binary Qt 5.15.2 (open source) release 
(but also some tests with the lastest Qt 6.4 binary release, for either 
Windows or macOS) suggest that the SQLite plugin that ships with Qt does 
not enable those "built in mathematical functions", as described here:


https://www.sqlite.org/lang_mathfunc.html

So do I:

 * Recompile the Qt SQLite plugin, with the desired
   -DSQLITE_ENABLE_MATH_FUNCTIONS flag?
 o Disadvantages (?):
 + Need to download Qt source code
 + Probably complicates the build process... (I have "build
   actions" on github.com that currently "only" need to install
   the binary Qt distribution)
 + Feels a bit "overkill"
 * Try to get the "SQLite DB handle" and add my own sin(), cos() and
   power() functions?
 o As described here:
   https://forum.qt.io/topic/71210/sqlite-user-define-functions/3
 + Essentially "QSqlDatabase::driver->handle()", some voodoo
   casting and using sqlite3_create_function()
 o Advantages:
 + Probably can be achieved using the "stock" SQLite plugin
   that ships with Qt, "programatically"
 o Disadvantages (?):
 + Still need to get hold of some SQLite header (for
   sqlite_create_function etc.)
 + Fragile? What if the header mismatches (in the future) with
   the shipped Qt SQLite plugin?
 # Feels "hacky"...
 * Any other "trick" to add those "math extensions" to an existing Qt
   SQLite plugin?

The second option seems more attractive than the first, but nevertheless 
a bit "fragile" (and I have to add functions that would essentially 
"already be in SQLite" (if enabled & compiled)), so feels like 
"re-inventing the wheel"...


Some more details: specifically I am trying to execute a query like:

*select power(l.latitude - 48.0, 2) + power((l.longitude - 8.0) * 
cos(radians( 48.0 )), 2) dist from   location l;*


(Eventually I want to find locations given by their latitude and 
longitude that are within a certain distance of my given location: 
https://jonisalonen.com/2014/computing-distance-between-coordinates-can-be-simple-and-fast/)


However when compiled into my Qt 5.15.2 application with some current 
"test code" like:.


QSqlQueryquery1;

query1.setForwardOnly(true);

query1.prepare(

"selectpower(l.latitude-48.0,2)+power((l.longitude-8.0)*cos(radians(48.0)),2)dist"

"from location l;"

);

constboolsuccess=query1.exec();
if(success){
...
}else{
qDebug()<<"SQL error:"

Re: [Interest] Some Qt classes (QUuid) do not work with std C++ containers (unordered_map)? [C++ question] [SOLVED]

[Till Oliver Knoll]

Am 06.07.21 um 11:30 schrieb Ahmad Samir:
> On 06/07/2021 11:17, Till Oliver Knoll wrote:
>> ...
>> #include  #include  ... // Won't compile
>> std::unordered_map exportPlugins;
>> ...
> Hello. Have a look at
> https://www.kdab.com/qt-datatypes-in-standard-library/
>
> I think that is the issue you're hitting.

From the article: "The Standard Library unordered associative containers
(std::unordered_map, std::unordered_set, and so on), as well as other
third party implementations (like the excellent robin-map
<https://github.com/Tessil/robin-map>), require, by default, a
specialization of std::hash to be available for the key type we want to use"

That's exactly the answer I was looking for :) So thank you so much,
article is now bookmarked!

Yes, the "joys" of C++ and the lack of explicit interface support (I am
thinking of "Java interfaces" now - to my understanding the C++20
"concepts" feature is meant to implement the "interface" concept to
quite some degree). Many STL features "implicitly expect" some features
of a given class/type. That is particularly true when implementing
"iterators", for instance
(https://www.internalpointers.com/post/writing-custom-iterators-modern-cpp)

"C++ expects some properties from an iterator"

What? Why? Which ones?

|struct Iterator { using iterator_category = std::forward_iterator_tag;
using difference_type = std::ptrdiff_t; using value_type = int; using
pointer = int*; // or also value_type* using reference = int&; // or
also value_type& }; |

Aha: so I just have to *know* about the existence of e.g.
"iterator_category". If I don't set it here my iterator code will still
compile - but I can't use my iterator then for some STL algorithms later
on. And it goes on with adding a begin() and end() method, which are -
implicitly - called when doing a "C++ style iteration". So why are they
to be called begin() and end() and return an iterator of some sort?
Because you need to *know* this.

And the problem with this "you need to know" concept seems to go on with
this std::hash to be implemented by any given class to be used in
unordered_map. To be fair, this is also kind of true for the Java
equivalent HashMap - except that every Java Object already implements a
(default) hashCode() method. But yes, you also need to know about its
existence, in order to possibly re-implement that hashCode() method to
get more meaningful hash values for your custom class - so arguably the
C++ compiler barking at me if no such hash method exists is arguably
better than to silently "use the default hashValue() method"?


Anyway, just some random thoughts of mine about this "need to know" topic :)


This question is hence fully answered for me!


So thanks again for the quick reply,

  Oliver

||


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

[Interest] Some Qt classes (QUuid) do not work with std C++ containers (unordered_map)? [C++ question]

[Till Oliver Knoll]

Dear all,

Disclaimer: my C++ knowledge is a bit rusty, especially as far as
standard C++ containers and modern features (C++11, 17, 20) are
concerned. That's exactly the reason why I have started another small
open source project, and also the reason why I now tend to use C++
standard containers (instead of the Qt ones - for no other reason to get
more knowledge about them).

Every then and when I stumble over some Qt classes which do not work
with some given C++ container classes. In some cases I could explain
this for myself based on some "web research", e.g. the "shared data"
concept of e.g. QString does not work with the concept of "unique
pointers" (which are to be stored in some C++ container. And I
intuitively understand that.

But now I stumbled over the following example for which I do not find
any relevant "web research" results (specific to Qt classes). I am
trying to create an unordered hashmap, with QUuid as key, as in:

#include  #include  ... // Won't compile
std::unordered_map exportPlugins;

The compiler (I am currently using the default compiler being used on
macOS 11.4 "Big Sur", with the open source Qt 5.12.2) is complaining
with several error messages (see below for complete error messages), but
they seem to be related to an "implicitly-deleted default constructor"

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/unordered_map:435:
Fehler: call to implicitly-deleted default constructor of
'std::__1::hash'

which seems to be caused by some explicitly deleted default constructor:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/utility:1564:5:
note: '__enum_hash' has been explicitly marked deleted here

Looking at the QUuid class declaration I do not find anything suspicious
at first glance. Specifically I do see a default constructor (but I do
understant that the error message is referring to some other default
constructor of __enum_hash, in the  header). In fact, when I
exchange QUuid with QString, as in:

// This works std::unordered_map exportPlugins;

then everything compiles fine.

This is with a CMake based project, with

set(CMAKE_CXX_STANDARD17)

set(CMAKE_CXX_STANDARD_REQUIREDON)

So this should be using a C++17 compliant compiler.

Questions:

I can use a QString instead of a QUuid here just fine (or use some Qt
container class here instead, namely QMap), but I am curious about
"what's going on here":

* Is this a known limitation of QUuid (and possibly other classes), that
it cannot be used in C++ container classes?

* Or asked differently: why does the "template expansion" (?) get into
the case of __enum_hash (when using QUuid), which apparently has an
explicitly deleted default constructor (or why is the default
constructor of QUuid not sufficient)?

* Is there a way to tell (given the Qt's class declaration) whether a Qt
class is suitable for C++ container classes?

* Or am I doing something wrong here (wrong compiler, wrong project
settings, missing includes, ...)?

As this is most likely a basic C++ noob question I am fine with any RTFM
answers here :) But again, so far I did not find anything related to
QUuid and C++ container classes on the web.

Thank you so much,

Oliver


For reference here are the two error messages that I get with QUuid as
key for unordered_map:

#1

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/unordered_map:435:
Fehler: call to implicitly-deleted default constructor of
'std::__1::hash' In file included from
/Users/tknoll/resources/work/Qt/SkyDolly/src/Plugin/src/PluginManager.cpp:26:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/unordered_map:435:11:
error: call to implicitly-deleted default constructor of
'std::__1::hash' : _Hash() {} ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/memory:1956:3:
note: in instantiation of member function
'std::__1::__unordered_map_hasher,
std::__1::hash, true>::__unordered_map_hasher' requested here
__compressed_pair_elem(__default_init_tag) {} ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/unordered_map:906:5:
note: in instantiation of member function
'std::__1::__hash_table, std::__1::__unordered_map_hasher,
std::__1::hash, true>, std::__1::__unordered_map_equal,
std::__1::equal_to, true>,
std::__1::allocator>>::__hash_table' requested here unordered_map() ^
/Users/tknoll/resources/work/Qt/SkyDolly/src/Plugin/src/PluginManager.cpp:37:5:
note: in instantiation of member function
'std::__1::unordered_map,
std::__1::equal_to, std::__1::allocator>>::unordered_map' requested here
PluginManagerPrivate() noexcept ^

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Am 06.01.21 um 10:45 schrieb Kai Köhne:
>> From: Interest  On Behalf Of Till Oliver 
>> Knoll
>> Subject: Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - 
>> build directories write-protected?
>>
>> Am 31.12.20 um 16:02 schrieb Till Oliver Knoll:
>> Am 31.12.20 um 15:29 schrieb James DeLisle:
>> There are some on-going peculiarities with CMake and translation files, as 
>> evidenced here:
>> https://bugreports.qt.io/browse/QTBUG-76410
>> Thanks for your reply! In fact, the problem is not only related to 
>> translation files (but it occurs there first during a build). 
>> In fact, I "commented out" the generation of translation (*.ts) files and 
>> the problem also occured later on during a "rebuild"
>> (at least with my actual project).
>>
>> Or in other words: the generated CMakeLists.txt (generated by Qt Creator 
>> 4.14.0) simply does not work, neither on Windows > nor on macOS (at least 
>> not on Mojave".
>> There is no other cmake in the PATH (I specifically uninstalled an older 
>> version with "brew uninstall cmake". In fact, there is no > cmake at all in 
>> the PATH right now (I am exclusively building from within Qt Creator for the 
>> time being).
> I can reproduce the problem, but only with CMake 3.19.0.  I cannot reproduce 
> with CMake 3.18.4 nor CMake 3.19.2.

Oh, that's actually good news then :) Thanks for letting me know!

> Feel free to open a bug about this, so it's properly tracked.
>
Will do. However macOS support is currently not that urgent (my app
targets "Flight Simulator 2020" with "SimConnect" which runs on Windows
10 only - so until I have refactored my "connection code" into a proper
plugin I won't be able to compile on macOS anyway ;)), and I can live
with the reported "Windows tweaks" for now (namely "clearing the CMake
configuration/build files before doing a "rebuild all").

And in the meantime I will also get more familiar with CMake, too ;)

Thanks, Oliver

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

Re: [Interest] Qt6 - Making Qt installer package for Windows, Linux and OS X

[Till Oliver Knoll]

Am 09.12.20 um 11:14 schrieb Alexandru Croitor:
> Going forward, i'd expect improvements on "consumption of Qt with CMake" part 
> as well.

I can definitively confirm that creating your own Qt applications using
CMake yourself is not quite the same "out of the box"-experience as with
qmake (at least as far as "template projects setup with Qt Creator" are
concerned). Also refer to my other thread here ("Rebuilding cmake
project (in Qt Creator) fails - build directories write-protected?")

CMake support is just not quite there yet ;)

Cheers, Oliver

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

Re: [Interest] Qt 6.0.0 released

[Till Oliver Knoll]

Am 09.12.20 um 16:04 schrieb ekke:
>
> I'm happy with the new Small Business License for my mobile app
> development. https://www.qt.io/qt-for-small-business
>
Well, here's the new catch (compared to Qt 5 perpetual licenses): if you
stop paying your license fees you now must pull your app(s) developed
with Qt 6 from all app stores (existing users may continue to use your
app, sure), or in other words: you can only sell your Qt 6 based apps
for as long as you keep paying the yearly Qt license fees. That also
impacts giving support for your existing apps: you can only do so for as
long as you have a valid (paid) Qt 6 license.

That might not be a big deal for those small businesses that keep
developing (new) Qt applications, but it may be an additional burden for
others.

Now I am not even critisising this decision: after all, everyone needs
to make (keep making) money. I was just trying to explain why some are
put off a bit by this license policy change decision.

Cheers, Oliver


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

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Am 05.01.21 um 20:09 schrieb Till Oliver Knoll:
> Am 31.12.20 um 16:02 schrieb Till Oliver Knoll:
>> Am 31.12.20 um 15:29 schrieb James DeLisle:
>>>
>>> There are some on-going peculiarities with CMake and translation
>>> files, as evidenced here:
>>>
>>> https://bugreports.qt.io/browse/QTBUG-76410
>>> <https://bugreports.qt.io/browse/QTBUG-76410>
>>>
>> Thanks for your reply! In fact, the problem is not only related to
>> translation files (but it occurs there first during a build). In
>> fact, I "commented out" the generation of translation (*.ts) files
>> and the problem also occured later on during a "rebuild" (at least
>> with my actual project).
>>
>
> Oh dear: the problem also occurs on macOS 10.14 "Mojave"
>
And just for the record: the same "MainWindow" app generated with QMake
compiles, links and runs like a charm , on both Windows and macOS ;)
(The generated compiler/linker commands differ quite a bit as well
between the CMake and the QMake generated variants).

Cheers, Oliver



OpenPGP_signature
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Am 31.12.20 um 16:02 schrieb Till Oliver Knoll:
> Am 31.12.20 um 15:29 schrieb James DeLisle:
>>
>> There are some on-going peculiarities with CMake and translation
>> files, as evidenced here:
>>
>> https://bugreports.qt.io/browse/QTBUG-76410
>> <https://bugreports.qt.io/browse/QTBUG-76410>
>>
> Thanks for your reply! In fact, the problem is not only related to
> translation files (but it occurs there first during a build). In fact,
> I "commented out" the generation of translation (*.ts) files and the
> problem also occured later on during a "rebuild" (at least with my
> actual project).
>

Oh dear: the problem also occurs on macOS 10.14 "Mojave", with a simple
"Qt Widgets application" (as generated from scratch by Qt Creator, with
a single QMainWindow and a translation file (as added by the "New
project" wizard using Cmake):

19:42:58: Führe Schritte für Projekt MainWindow aus...
19:42:58: Starte:
"/Users/tknoll/Qt/Tools/CMake/CMake.app/Contents/bin/cmake" --build .
--target all
[1/5 13.6/sec] Generating
/Users/tknoll/resources/work/Qt/MainWindow/MainWindow_de_DE.ts
FAILED: /Users/tknoll/resources/work/Qt/MainWindow/MainWindow_de_DE.ts
CMakeFiles/MainWindow_de_DE.ts_lst_file
cd
/Users/tknoll/resources/work/Qt/build-MainWindow-Desktop_Qt_5_15_2_clang_64bit-Debug
&& /Users/tknoll/Qt/5.15.2/clang_64/bin/lupdate
@/Users/tknoll/resources/work/Qt/build-MainWindow-Desktop_Qt_5_15_2_clang_64bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file
-ts /Users/tknoll/resources/work/Qt/MainWindow/MainWindow_de_DE.ts
lupdate error: List file
'/Users/tknoll/resources/work/Qt/build-MainWindow-Desktop_Qt_5_15_2_clang_64bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file'
is not readable.
ninja: build stopped: subcommand failed.
19:42:58: Der Prozess
"/Users/tknoll/Qt/Tools/CMake/CMake.app/Contents/bin/cmake" wurde mit
dem Rückgabewert 1 beendet.
Fehler beim Erstellen/Deployment des Projekts MainWindow (Kit: Desktop
Qt 5.15.2 clang 64bit)
Bei der Ausführung von Schritt "Erstellen"
19:42:58: Verstrichene Zeit: 00:00.


Again the same as on Windows:

  FAILED: /Users/tknoll/resources/work/Qt/MainWindow/MainWindow_de_DE.ts
CMakeFiles/MainWindow_de_DE.ts_lst_file 


$> ls -la
total 200
drwxr-xr-x  11 tknoll  staff    352  5 Jan 19:49 .
drwxr-xr-x  15 tknoll  staff    480  4 Jan 17:41 ..
drwxr-xr-x   3 tknoll  staff 96  4 Jan 17:35 .cmake
-rw-r--r--   1 tknoll  staff  40536  5 Jan 19:48 .ninja_deps
-rw-r--r--   1 tknoll  staff   1613  5 Jan 19:49 .ninja_log
-rw-r--r--   1 tknoll  staff  13589  5 Jan 19:48 CMakeCache.txt
drwxr-xr-x  11 tknoll  staff    352  5 Jan 19:49 CMakeFiles
drwxr-xr-x   3 tknoll  staff 96  4 Jan 17:59 MainWindow.app
drwxr-xr-x   8 tknoll  staff    256  5 Jan 19:49 MainWindow_autogen
-rw-r--r--   1 tknoll  staff  33441  5 Jan 19:48 build.ninja
-rw-r--r--   1 tknoll  staff   1562  4 Jan 17:35 cmake_install.cmake

Now at this point I don't see anything special about the CMakeFiles
directory (located in the "build" directory). In fact - unlike as on
Windows 10 - I can delete the entire
build-MainWindow-Desktop_Qt_5_15_2_clang_64bit-Debug folder without
problems.

Of at this point there is no MainWindow_de_DE.ts_lst_file in that directory:


$> ls -la
total 64
drwxr-xr-x  11 tknoll  staff    352  5 Jan 19:51 .
drwxr-xr-x  11 tknoll  staff    352  5 Jan 19:51 ..
drwxr-xr-x   6 tknoll  staff    192  5 Jan 19:51 3.19.0
-rw-r--r--   1 tknoll  staff  15382  5 Jan 19:51 CMakeOutput.log
drwxr-xr-x   2 tknoll  staff 64  5 Jan 19:51 CMakeTmp
drwxr-xr-x   3 tknoll  staff 96  5 Jan 19:51 MainWindow.dir
drwxr-xr-x   5 tknoll  staff    160  5 Jan 19:51 MainWindow_autogen.dir
-rw-r--r--   1 tknoll  staff    589  5 Jan 19:51 TargetDirectories.txt
-rw-r--r--   1 tknoll  staff    287  5 Jan 19:51 clean_additional.cmake
-rw-r--r--   1 tknoll  staff 85  5 Jan 19:51 cmake.check_cache
-rw-r--r--   1 tknoll  staff   2415  5 Jan 19:51 rules.ninja

That explains the "not readable" (follow-up) error message then.

Or in other words: the generated CMakeLists.txt (generated by Qt Creator
4.14.0) simply does not work, neither on Windows nor on macOS (at least
not on Mojave".

There is no other cmake in the PATH (I specifically uninstalled an older
version with "brew uninstall cmake". In fact, there is no cmake at all
in the PATH right now (I am exclusively building from within Qt Creator
for the time being).

Now at this point, if I do:

* Clear CMake configuration

* Run CMake

and build again (with CTRL / CMD + B) then it works with the translation
file:

20:00:54: Running steps for project MainWindow...
20:00:54: Starting:
"/Users/tknoll/Qt/Tools/CMake/CMake.app/Contents/bin/cmake" --build .
--target all
[1/6 2.5/sec] Automatic MOC and UIC for target MainWindow
[2/6 4.4/sec] Generating
/Users/tknoll/resources/work/Q

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Am 31.12.20 um 15:29 schrieb James DeLisle:
>
> There are some on-going peculiarities with CMake and translation
> files, as evidenced here:
>
> https://bugreports.qt.io/browse/QTBUG-76410
> 
>
Thanks for your reply! In fact, the problem is not only related to
translation files (but it occurs there first during a build). In fact, I
"commented out" the generation of translation (*.ts) files and the
problem also occured later on during a "rebuild" (at least with my
actual project).

I believe that some process is trying to re-generate certain cmake
related "build files", or to re-create the output ("bin") directory or
the like. But since some process sets the "archive" flag on certain
(all?) cmake related directories the build process may fail to first
delete and then re-generate the folders in question.

It is just curious that a "Clear Cmake Configuration" (?) actually works
(from within Qt Creator).

Whatever... maybe it works next year :)

Happy New Year to you, too!

 Oliver



OpenPGP_signature
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Am 30.12.20 um 17:34 schrieb Jason H:
> I don't have any specific knowlege, but if it were me, I would check
> Sysinternals diskmon and see where/whow/who is setting the read-only
> flag. (Asuming I checked and the flad is actually set)

Thank you for your quick reply. Before I dig deeper I first wanted to
check whether other people have already encountered this "archive flag /
cannot re-generate source files with cmake" issue as well, or whether
this is just "how cmake is supposed to work" (-> also clear the cmake
"configuration / build files" before a complete rebuild).

And sorry if this is getting off-topic (I am aware that this is possibly
more a cmake related question than Qt), but since cmake is (going to be)
the default build system in Qt 6 (replacing good ol' qmake *sniff* ;)) I
thought it may be worthwile to ask here.

> Also likely - there is a process in that directory that is preventing
> deletion and windows is not reporting it accurately. I've not used
> windows in a while but I remember it being picky about such things.

Yes, I initially was also suspecting some "rogue cmake process" which
was still holding "locks" on certain build files. But checking in the
process monitor ("Task Manager") I did not find any suspicious process
after a build had completed (related to cmake) - at least not my name
(no running / sleeping process had "cmake" in its name).

I can live with the fact that I also need to clear the cmake project
files, as "rebuilding from scratch" is not something that I do regularly
(more so in order to check whether the project "still builds from
scratch"), so I am not inclined to dig any deeper for now. Unless
someone stumbled over the same issue...

And yes, I intend to "outsource" the Windows specific code into a plugin
which is optionally build (= only on Windows, obviously), so I can
switch my "main development" back to Mac / Linux ;)


Many thanks & Happy New Year!

  Oliver



OpenPGP_signature
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Rebuilding cmake project (in Qt Creator) fails - build directories write-protected?

[Till Oliver Knoll]

Dear all,

It's been a while since I asked my last question here - or posted
anything meaningful, for that matter - so first of all "Hello!" and
"Merry Christmas / Holidays" :)

I have started a new Qt 5.15.2 (open source) project on Windows 10 (due
to a dependency on Flight Simulator 2020, specifically SimConnect.dll
;)), and since Qt 6 will default to cmake (as I understand) I also chose
cmake in the Qt Creator 4.14.0.

*The problem: *"rebuilding" (QtCreator: "Build/Rebuild All Projects")
the project fails when trying to generate the translation *.ts files
respectively the correspoding "list" (?) file:


FAILED: C:/dev/Qt/MainWindow/MainWindow_de_DE.ts
CMakeFiles/MainWindow_de_DE.ts_lst_file
cmd.exe /C "cd /D
C:\dev\Qt\build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug &&
C:\Qt\5.15.2\mingw81_64\bin\lupdate.exe
@C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file
-ts C:/dev/Qt/MainWindow/MainWindow_de_DE.ts"
lupdate error: List file
'C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/*MainWindow_de_DE.ts_lst_file'
is not readable.*
ninja: build stopped: subcommand failed.

Initially I thought that this is yet another issue with whitespace in
the build path, but that's not the case (I now moved it from
c:/Users/Oliver Knoll/work/... to c:/dev/Qt/work/... - that is, no
spaces in path anymore).


However I noticed that some directories in the "build" directory
(c:/dev/Qt/build-MainWindow-Desktop_...) have the "Write Protected" flag
set:

.cmake
CMakeFiles
MainWindow_autogen

The Windows 10 "Properties" dialog says: "Write-Protected (only concerns
files in the directory)" (or similar, in German: "Schreibgeschützt
(betrifft nur Dateien im Ordner).

So when trying to manually delete those folders a dialog pops up asking
me for administrator rights, and when I click on Continue (with admin
rights) then another dialog tells me that I need the corresponding
access rights from user "Oliver Knoll" - well, that's exactly my user
(with admin rights).

However I can "cd" into the remaining directories and delete all files
without problems, and after that I can delete the entire build folder at
last.

Back in Qt Creator a CTRL + B (Build Project "MainWindow") then
re-builds the project again.


Another - proper? - solution, in Qt Creator (all in "Build" menu):

* Clean Project "MainWindow"
* Clear CMake Configuration (at that point the subdirectory
.cmake/api/v1/query (and reply) still remains, plus 3 "ninja" related
files and cmake_install.cmake)
* Run CMake
* Rebuild Project "MainWindow"

It works, but... really? 4 steps instead of just one? Is that the proper
"CMake way" (I am totally new to CMake) to rebuild a project from scratch?

The above example refers to a simple "MainWindow" project setup in Qt
Creator as follows:

* New File Or Project
* Qt Widgets Application
* Name: MainWindow (any name)
* Build System: CMake
* Default classes/files, including Generate form
* Add any translation language
* Default Qt Kit: Qt 5.15.2 MinGW 64-bit
* No version control

The above experiments were done with the default generated CMakeLists.txt.


*Development environment:*

* Qt 5.15.2 Open Source
* QtCreator 4.14.0
* CMake 3.19.0 (installed via Qt Installer)
* Windows 10 2004 (all updates installed)
* Except the MS FS2020 SDK (SimConnect.dll) there are no other developer
tools installed (specifically no other CMake, no Visual Studio, no other
compilers etc.)
* "Default Windows Home installation" (one user - Oliver Knoll - with
admin rights; yes, it's a "gaming machine" ;))


*Other:
*

* Most likely not relevant, but: it is a "Windows To Go" installation
(created/installed via tool "WinToUSB"), installed on an external SSD
(which is connected to a Mac ;))

The full compilation error during a "Rebuild" (without clearing the
CMake configuration):

12:02:08: Running steps for project MainWindow...
12:02:08: Starting: "C:\Qt\Tools\CMake_64\bin\cmake.exe" --build .
--target clean
[1/2 54.3/sec] Cleaning additional files...
[2/2 83.6/sec] Cleaning all built files...
Cleaning... 0 files.
12:02:08: The process "C:\Qt\Tools\CMake_64\bin\cmake.exe" exited normally.
12:02:08: Starting: "C:\Qt\Tools\CMake_64\bin\cmake.exe" --build .
--target all
[1/6 2.7/sec] Automatic MOC and UIC for target MainWindow
[2/6 5.1/sec] Generating C:/dev/Qt/MainWindow/MainWindow_de_DE.ts
FAILED: C:/dev/Qt/MainWindow/MainWindow_de_DE.ts
CMakeFiles/MainWindow_de_DE.ts_lst_file
cmd.exe /C "cd /D
C:\dev\Qt\build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug &&
C:\Qt\5.15.2\mingw81_64\bin\lupdate.exe
@C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file
-ts C:/dev/Qt/MainWindow/MainWindow_de_DE.ts"
lupdate error: List file
'C:/dev/Qt/build-MainWindow-Desktop_Qt_5_15_2_MinGW_64_bit-Debug/CMakeFiles/MainWindow_de_DE.ts_lst_file'
is not readable.
ninja: build stopped: subcommand failed.
12:02:09: The process 

Re: [Interest] I love QML

[Till Oliver Knoll]

Am 03.07.20 um 17:46 schrieb joao morgado via Interest:
> When I started using Qt I never touched WIndows MFC again.

Ha! But you actually /did/ touch MFC then ;)

Here's another fan story (even though I am - unfortunately - not working
professionally with Qt for a very long time)...

Back in the days(tm), near the end of my computer science education, I
was so ready to write "real applications". You know, proper GUI, Windows
2000, games, ... enough with "silly Oberon", enough with "command line
exercises" written in C, enough with ugly Motif/C++ feature
extensions... I was ready for the real world!

So I bought a book "GoTo Visual C++ 6" with a "comprehensive
introduction to MFC", shortly around the time before my diploma work
started. I don't know how many hours (possibly days, to be fair ;)) I
had this book in my hands, but the very moment I came across "macro
programming" as in:

  BEGIN_MESSAGE_MAP(...)

    ON_COMMAND(ID_APP_ABOUT, ...)

    // Don't change this generated code!

    ...

  END_MESSAGE_MAP()

or "gems" like

  ON_BN_CLICKED(IDD_BUTTON_0, OnNumber)
  ...
  item.mask = LVIF_TEXT | LVIF_IMAGE;
  ...
  item.pszText = (LPSTR)

I immediately knew: this is not it! I wasn't sure whether I should stick
a needle through the book or burn it entirely... but don't touch that!
(The above code snippets come straight from that book, which is proof
that it still exists - I couldn't make up such evil stuff myself ;))


Having some first experience with Linux and KDE 1.x I had heard about a
thing called Qt (which was at version 2.x at the time, IIRC). My diploma
work in 2001 was about developing a "3d paint editor"
(www.pointshop3.com, for the interested) based on an existing
"point-based software renderer", which was... of course written in C and
MFC - yikes! So my first suggestion to the PhD student who was
overseeing my work was to rip away everything that spelled "MFC", make
it compile with a C++ compiler and use Qt instead. "Go ahead, son. But
if you run into trouble you're on your own!"

Turned out that my decision to use Qt (of which I only knew so little,
but had browsed its excellent documentation, which already convinced me
that I could pull it off - and of course the nice "Java-like" syntax of
its API) was worth pure gold. After just two weeks or so I had the
existing 3D "point-based renderer" compiling and running within a basic
Qt application, with a main window and menu - yesss!

After exact four months I had a "3d paint editor" with selectable
brushes, "gauss texture filtering", a software and OpenGL renderer
(switchable at runtime), and all extendable with plugins. Hadn't it be
for Qt, its excellent API and especially the documentation and examples
I wouldn't have come that far, in so little time!

The application was later ported to Qt 3 by others and made runnable on
Linux as well (I developed it mainly on Windows at the time), and was
extended with some plugins "all over the world" (well, from some
universities in France and Holland at least ;))


Lessons learned: a clean API and a great documentation with examples is
what makes a great toolkit! And of course its functionality ;)

Hooray for Qt! :)


Cheers, Oliver


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

Re: [Interest] Qt-12 with Dark Theme on MacOS Mojave

[Till Oliver Knoll]

> Am 21.12.2018 um 08:26 schrieb coroberti . :
> 
>> On Thu, Dec 20, 2018 at 9:33 PM Mike Krus  wrote:
> 
>> Hi
>> 
>> I’ve been tracking QEvent::PaletteChange events, like this:
>> 
>> bool MainWindow::event(QEvent *event)
>> {
>> if (event->type() == QEvent::PaletteChange) {
>> QPalette p = palette();
>> m_clearColor = p.color(QPalette::Base);
>> emit clearColorChanged(m_clearColor);
>> }
>> 
>> return QMainWindow::event(event);
>> }
>> 
>> Event gets sent when switching between themes…
>> 
>> Of course, I’m just using the base colour as is, not trying to figure out if 
>> it’s light or dark…
>> 
>> Hope this helps,
>> 
>> Mike
>> 
>> > On 20 Dec 2018, at 18:48, coroberti .  wrote:
>> > 
>> > Hi,
>> > Qt-12 well manages the colors of QWidgets - great job of Qt-developers. 
>> > Thank you!
>> > 
>> > When some background colors are managed by the application,
>> > how to figure out whether it's Light or Dark theme currently in use?
>> > 
>> > Another question is how to get notification about the switch between the 
>> > themes?
>> 
> 
> Hi Mike,
> Thank you for your reply and the proposed direction.
> 
> It looks like what's left for me is to explore how to figure out from 
> QPalette mapping to the standard themes.

A practical approach could be:

* If the background colour („background role“) is „darker than some threshold 
(brightness)“, then the user selected dark mode
* Otherwise light mode

:)

Cheers, Oliver___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] need a QT 5.12.0 MinGW 32bit release for windows in all the upcoming QT versions

[Till Oliver Knoll]

+1

> Am 17.12.2018 um 13:30 schrieb André Hartmann :
> 
> +1
> 
>> Am 17.12.18 um 12:44 schrieb Frank Hemer:
>> +1
>>> On Monday, 17 December 2018 08:11:34 CET Amr Kamal wrote:
>>>  Hello,
>>> 
>>> when Downloading the last version of QT 5.12.0 it only provides MinGW 64bit
>>> for windows  which makes some problem with previous projects that used
>>> 32bit version especially if there is any kind of third-party library, at
>>> the same time the need of using one updated version from QT, because of
>>> that the only solution now, is to compile it with MinGW 32bit which takes a
>>> very long time, need a lot of dependencies, and most of the users can't do
>>> this, or using old versions of QT.
>>> 
>>> so please consider this suggestion in the next version, as it's very needed
>>> one it's great to have a 64bit version but 32 is very good working on all
>>> platforms.
>>> 
>>> Thank you very much.
>> ___
>> 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] Is it ok to use QLibrary to load and unload different shared libraries in sequence?

[Till Oliver Knoll]

> Am 26.10.2018 um 18:21 schrieb Thiago Macieira :
> 
> On Thursday, 25 October 2018 00:03:32 PDT Roland Winklmeier wrote:
>>> The problem might be a number of different things. In general, don't
>>> unload
>>> libraries. If your design requires it, rethink and redesign.
>> 
>> It was more like a safety feature. Technically I don't have to unload the
>> other dlls. I could also keep the previous one loaded, but I was concerned
>> about potential conflicts. I'm not an expert in these things, but if there
>> are two or even more shared libraries loaded into the same process that are
>> almost identical and therefore many common symbol names (the library is
>> proprietary so I have no way to check, but the publisher says so) can I run
>> into issues? If not, I would not bother unloading them.
> 
> Loading two versions of the same library is even worse and far more likely to 
> cause problems. When I suggested you redesign, that would be part of it and 
> you'd need to figure out a way so that you only ever load one and don't 
> unload 
> it.

The OP wrote: „Now I would like to add the feature to switch versions at 
runtime“

It is my understanding that we are talking about 3rd party libraries over which 
the OP has no source control, so there is nothing to redesign.

Also we are talking about „the same library, im different versions“, or in 
other words: „4.1 being mostly the same as 4.0, but with added features“ (but 
each implementation in its distinct DLL, of course).

I‘m not sure what would happen if you would load those two DLLs (with „mostly 
the same exported symbol names“): I‘m pretty sure that at link time for sure 
would get „duplicate symbols“ linker errors. But when using QLibrary? You would 
explicitly lookup (resolve) the required symbols „by application logic“ (dlopen 
etc.), and assign them to distinct function pointers etc., so maybe that would 
even work.

(In fact, it /must/ work: for „plugins“ you typically have a „create“ and 
„destroy“ C-syle function that are dynamically resolved, and of course each 
such „plugin“ (DLL) has those same function declarations).

But I would /still/ want to unload a „plugin“ that is no longer required, 
especially for „design“ reasons. Why would you want to keep that „dead code“ in 
memory if the user has decided - at runtime - to use „v4.1“ now instead of the 
previous 4.0 (or 4.2)? Waste of resources.

(The argument „what if the user wants to switch back fast?“ could be solved 
with a simple QTimer and „5 minutes idle plugins get kicked“ approach).

Whether or not the same QLibrary instance can be used to repeatedly load/unload 
different DLLs I don‘t know: according to Thiago „yes“, and I‘d certainly 
expect so, too.

Cheers,
 Oliver


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

Re: [Interest] QtCreator 4.7.1 / Qt 5.12. Beta 1 (Android, iOS, macOS)

[Till Oliver Knoll]

> Am 13.10.2018 um 12:25 schrieb ekke :
> 
> I'm just testing Qt Creator 4.7.1 / Qt 5.12 Beta 1 with my QtQuickControls2 
> Apps for Android / iOS. 
> 
> macOS also used, but only because testing is really fast on macOS
> 
> Xcode 10.0, macOS 10.13.6
> 
> ---
> 
> macOS: getting warnings
> 
> Qt has only been tested with version 10.13 of the platform SDK, you're using 
> 10.14. 
> This is an unsupported configuration. You may experience build issues, and by 
> using
> the 10.14 SDK you are opting in to new features that Qt has not been prepared 
> for.
> Please downgrade the SDK you use to build your app to version 10.13, or 
> configure
> with CONFIG+=sdk_no_version_check when running qmake to silence this warning.
> 
> I'm still on macOS 10.13.6 and don't use any new things as dark mode.
> 
Not sure, but does Xcode on 10.13.6 already support the SDK 10.14? If so, that 
may be your answer then.

To add to that: I re-compiled my QWidget based application on macOS 10.14 
(Mojave), using latest Qt 5.12 Beta and latest everything (Xcode, Qt Creator)...

Did not modify my *.pro (qmake) files and got the same warning (so yes, I was 
using the latest SDK 10.14).

Bravely ignored the warning and launched the application. Runs fine, even the 
toolbar is rendered „dark“ (when macOS „dark mode“ is enabled). Nice. Haven‘t 
done extensive testing yet, such as toggling dark mode. But the (simple: 
QGraphicsView, QWidgets, the usual QContainers, no other fancy Qt modules) 
application behaves as expected.

FWIW.

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

Re: [Interest] Qt and Open SSL

[Till Oliver Knoll]

> Am 15.10.2018 um 02:42 schrieb Christopher Probst :
> 
> Also want to confirm that even though is says 32, ssleay32.dll and 
> libeay32.dll are not necessarily compiled with a 32 compiler?

Didn‘t you just say that you compiled those libs yourself? So you should know ;)

In all other cases:
  
https://stackoverflow.com/questions/495244/how-can-i-test-a-windows-dll-file-to-determine-if-it-is-32-bit-or-64-bit

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

Re: [Interest] Swift?

[Till Oliver Knoll]

> Am 10.08.2018 um 15:08 schrieb Jason H :
> 
> What is the status of using swift in Qt for Apple platforms?

Last time I checked there was no such thing as „Swift++“ (in analogy to 
ObjC++), which makes it impossible to „mix and match“ Swift code with C++.

The common denominator is C, so you could write „C function wrappers for your 
C++ classes“ (and vice versa for your Swift classes).

Or still use ObjC++ to glue the C++ and Swift world.

In any case you‘re dealing with 3 distinct languages (where C is admittedly 
„kind of C++ without the ++).

Not sure what would be less pain: C („no objects/classes -> cumbersome wrapper 
API) or ObjC++ („from which you actually want to get away by using Swift“).

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

[Interest] [Very OT] Re: WebGL platform and audio

[Till Oliver Knoll]

> Am 23.04.2018 um 17:58 schrieb Glen Mabey :
> 
> Jesus,
> 
> Thanks for your reply.  I've followed your suggestion and created an issue.  
> Anyone monitoring this thread should be able to vote for it here:
> 
> https://bugreports.qt.io/browse/QTBUG-67896

„... he audio comes out on the machine running the executable and not the one 
running the webbrowser.“

Ha! I just had to imagine a „Qt server“ serving Doom, and lots of players 
playing without sound in their browser... leaving the administrator wondering 
where all that chainsaw screaming, shouting, growling and shooting comes from: 
„What‘s all that noise coming from my server room all of a sudden?!“

;)

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

Re: [Interest] Future of Qt [was: Future of Qt3d]

[Till Oliver Knoll]

> Am 08.11.2017 um 11:54 schrieb Alexander Ivash :
> 
> This is really confusing.
> 
> From one side,
> 
>>> What you **don't** say is, that you "genuinely wish to treat the Qt
>>> Project as an Open Governance project and that external contributions
>>> are welcomed and valued."
>>> 
>>> There must be a reason not to write this sentence.
>> 
>> Because it goes without saying.
> 
>> Correct, it does go without saying.
> 
>  but from the other:
> 
>> The Open Governance model is the foundation of how we develop Qt. It offers 
>> tremendous value to our users and customers. It’s also one of the big items 
>> that differentiates Qt from all it’s competitors. And changing that would be 
>> negative for everybody, including The Qt Company.
>> 
>> So, speaking for The Qt Company: No, there are definitely no plans to change 
>> that.
> 
> So what does it mean in total? Qt stays Open Governance-driven, but no
> 'genuinely' ? Or genuinely but external contributions are not
> welcomed? :)
> 
> p.s. This is not trolling of any kind, I'm really confused.

Why the confusion? In the first paragraph that you quoted they confirm that "it 
goes without saying" that they [The Qt Company] /continue/ to treat the Qt 
Project as an Open Governance project and that external contribution are 
welcomed and valued."

That's the confirmation.

In the second paragraph that you quoted they explain the "why": "The Open 
Governance model is the foundation of how we develop Qt. It offers tremendous 
value to our users and customers. [...]"

That's the explanation.

There is no reason for you to put a "but" in between. There is no contradiction 
here. Except if you genuinely wish that the word "genuinely" is inserted 
somewhere here, and why that word would matter for you ;)

Now as for the matter of Qt3d: it seems that there are 
"project/contribution"-specific issues that need to be solved, and that we can 
only speculate about. Me too hopes that those get resolved to the satisfaction 
of all parties.

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

[Interest] [OT] Re: Interest Digest, Vol 69, Issue 11

[Till Oliver Knoll]

> Am 08.07.2017 um 22:08 schrieb Roland Hughes :
> ...
> If you are really old like I am you remember a time when we had feeble 8086, 
> 80286 based desktops and just down the hall there were Sparc Stations and all 
> of these other high end engineering workstations. 

Hey! I /do/ remember at least 80286 CPUs (*). You're not /that/ old!

;)

Cheers,
  Oliver

(*) I never had one, but friends of mine had. At that time I had the "computer 
of the future": the Amiga. Beat the Atari ST in every way, except perhaps 
screen resolution. But who fancies monochrome anyway ;) What will quantum 
computer owners brag about in the future? "My quantum CPU has more multiple 
states than yours"? ;)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Using Widgets for new projects

[Till Oliver Knoll]

> Am 17.05.2017 um 03:14 schrieb Tuukka Turunen :
> 
>  
> Hi,
>  
> If you make a desktop application widgets are often a solid choice – 
> especially if you want the application to look like other apps in that OS and 
> not create your own style for the app. Qt Creator, for example, is an 
> application that uses widgets extensively.
>  
> You may want to check out our on-demand webinar (read: video) about the 
> topic: 
> https://www.qt.io/event/the-curse-of-choice-an-overview-of-gui-technologies-in-qt/
>  
> Yours,

To add to this: if you want to stay "within the same technology" (read: "C++ 
and Qt extensions like MOC) then QWidgets may also win this decision. You can 
easily design your GUIs within Qt Designer (Qt Creator), but just as easily 
interact with the (generated C++) widgets "in your familiar language", without 
the need to "bridge and cast" between the JavaScript and C++ object worlds.

You can even create new (or dynamically modify existing) widgets 
programatically very easily, having the well-established parent-child paradigm 
in mind (in short: "the parent takes care of deallocating its children, when 
time comes" - just like we know it from most QObject hierarchies).

You can also animate your widgets *to a certain degree*, but (only) 
programatically, using the Qt animation framework, which "animates properties 
that you choose". But once you go this animation path further, you'd probably 
have wished to have started with QML, which really shines in this aspect 
(animation), as you simply *declare* the start- and endstates, and QML does the 
rest.

The good thing: you can easily "mix" those technologies.

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

Re: [Interest] QMake

[Till Oliver Knoll]

> Am 08.05.2017 um 20:49 schrieb Hamish Moffatt <ham...@risingsoftware.com>:
> 
>> On 08/05/17 21:38, Till Oliver Knoll wrote:
>> 
>> 
>> Am 08.05.2017 um 04:12 schrieb Hamish Moffatt <ham...@risingsoftware.com>:
>> 
>>>> On 08/05/17 17:07, Igor Mironchik wrote:
>>>> Hi,
>>>> 
>>>> Is it possible to set in qmake project file to put executable right in "." 
>>>> directory and   don't use "debug" and "release" subdirs?
>>> 
>>> Which platform? It does that on linux.
>>> 
>>> Maybe you can use the DESTDIR variable to control where it's output. (I had 
>>> trouble with that on Windows or Mac, I can't remember which.)
>>> 
>>> The inconsistencies between platforms are annoying.
>> 
>> There are no inconsistencies. Qmake puts all command line executables in 
>> ".", unless otherwise specified by DESTDIR, as correctly observed.
> 
> No it doesn't, which is what Igor posted about in the first place. On Windows 
> it puts them in Debug and Release subdirectories.
> 
> André pointed out that the difference is that debug_and_release is on by 
> default on Windows. You can enable it on Mac, which moves where the object 
> files go, but the .app is still written to the main output directory instead. 
> Except if you use "-spec macx-xcode" and build with xcodebuild, then the .app 
> goes into Release/ instead.

Oh, my bad then. Since I /always/ specify DESTDIR myself - with debug and 
release specific paths set by myself - I haven't noticed that behaviour. For 
sure didn't expect it either ;)

Also, I am using the plain vanilla MinGW based binary Qt build, so there it 
might yet again be different: I actually /thought/ the final binary would be 
placed in "." when no DESTDIR was set (and when building "on the console", that 
is not "within Qt Creator".

But again, not sure anymore. My apologies.

Bottom line: always set DESTDIR, debug/release specific, to be in control.

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

Re: [Interest] Args

[Till Oliver Knoll]

> Am 08.05.2017 um 08:26 schrieb Till Oliver Knoll 
> <till.oliver.kn...@gmail.com>:
> 
> 
> 
> Am 08.05.2017 um 07:16 schrieb Philippe <philw...@gmail.com>:
> 
>>>> There is probably a reason why completely new languages like Swift come
>>>> completely without exception handling 
>> 
>> Quote from Apple doc:
>> 
>> "Swift provides first-class support for throwing, catching, propagating,
>> and manipulating recoverable errors at runtime."
>> 
>> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
>> 
> 
> Interesting. That must be a "recent addition to Swift (3.0?)", as that 
> clearly wasn't there from the very beginning (hence the outcry in the former 
> ObjC community).

Since Swift 2.0 actually:

https://www.hackingwithswift.com/new-syntax-swift-2-error-handling-try-catch

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

Re: [Interest] Args

[Till Oliver Knoll]

> Am 08.05.2017 um 08:26 schrieb Till Oliver Knoll <till.oliver.kn...@gmail.com>
> 
> This sums up my previous point pretty nicely:
> 
> "Java exceptions ceased to be exceptional at all, they became commonplace. 
> They are used from everything from the benign to the catastrophic, 
> differentiating between the severity of exceptions falls to the caller of the 
> function."

And this:

"For example in C++ you might throw an exception when you can’t convert from an 
enum to its string equivalent, or in Java when parsing a date from a string. In 
an internet connected world, where every input from a network must be 
considered hostile, is the failure to parse a string into a date really 
exceptional? Of course not."

[https://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right]

Cheers,
  Oliver

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

Re: [Interest] QMake

[Till Oliver Knoll]

> Am 08.05.2017 um 04:12 schrieb Hamish Moffatt :
> 
>> On 08/05/17 17:07, Igor Mironchik wrote:
>> Hi,
>> 
>> Is it possible to set in qmake project file to put executable right in "." 
>> directory and don't use "debug" and "release" subdirs?
> 
> Which platform? It does that on linux.
> 
> Maybe you can use the DESTDIR variable to control where it's output. (I had 
> trouble with that on Windows or Mac, I can't remember which.)
> 
> The inconsistencies between platforms are annoying.

There are no inconsistencies. Qmake puts all command line executables in ".", 
unless otherwise specified by DESTDIR, as correctly observed.

When compiling "within Qt Creator" those settings are usually overruled by the 
(local, per user) project settings, which are initialised the first time you 
open (or create) a *.pro project file.

Furthermore, when compiling a "normal" application on macOS the executable is - 
by default - placed in an "app bundle" (which by itself is placed in DESTDIR).

That's no "inconsistency", but "expected platform-specific behaviour".

Refer to

  http://doc.qt.io/qt-5/osx-deployment.html

for more details.

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

Re: [Interest] Args

[Till Oliver Knoll]

Am 08.05.2017 um 07:16 schrieb Philippe :

>>> There is probably a reason why completely new languages like Swift come
>>> completely without exception handling 
> 
> Quote from Apple doc:
> 
> "Swift provides first-class support for throwing, catching, propagating,
> and manipulating recoverable errors at runtime."
> 
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
> 

Interesting. That must be a "recent addition to Swift (3.0?)", as that clearly 
wasn't there from the very beginning (hence the outcry in the former ObjC 
community).

This sticks out for me:


"Note: Error handling in Swift resembles exception handling in other languages, 
with the use of the try, catch and throw keywords. Unlike exception handling in 
many languages—including Objective-C—error handling in Swift does not involve 
unwinding the call stack, a process that can be computationally expensive. As 
such, the performance characteristics of a throwstatement are comparable to 
those of a returnstatement."

But yes, for all practical matters that means that Swift has exception handling 
now :)


But then there's another new language Go which also "got rid" of exceptions 
(because it can "afford to": it doesn't have a huge legacy API like Cocoa/ObjC 
to satisfy) from the very beginning:

https://dave.cheney.net/2012/01/18/why-go-gets-exceptions-right

That's a nice read btw which I just found.

This sums up my previous point pretty nicely:

"Java exceptions ceased to be exceptional at all, they became commonplace. They 
are used from everything from the benign to the catastrophic, differentiating 
between the severity of exceptions falls to the caller of the function."

;)

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

Re: [Interest] Args

[Till Oliver Knoll]

> Am 08.05.2017 um 01:48 schrieb Igor Mironchik :
> 
> Hi,
 Using exceptions in arguments parser is something that just cannot be 
 justified.
 
>>> Why not?
>> Even in the danger of starting a huge debate about "exceptions vs return 
>> error code" here are my thoughts about it:
>> 
>> Exceptions should just be used for... well, /exceptional/ cases.
>> 
>> So what would be an "exceptional case" for a command line parser then? 
>> Certainly not wrongly provided arguments. Humans tend to misspell words all 
>> the time, so that's "the norm": business as usual for a command line parser 
>> to validate the input and inform the user appropriately (with a usage help, 
>> similar spelled commands etc.). Nothing which cries "exception!" here IMHO.
>> 
>> The only thing I could think of in a 10 second brainstorming which could be 
>> considered "exceptional" is when e.g. "stdin" (or some socket even from 
>> which to read commands, but even this would be a bordercase, as it could be 
>> considered "normal" that a socket cannot be opened) cannot be opened for 
>> reading (which is somewhat a constructed example, as arguments are usually 
>> passed as input parameters to main() anyway - but you get the idea).
>> 
>> The internet is full of articles - and opinions - about when to use 
>> exceptions, and when not (and we haven't even touched the topic of 
>> "unchecked vs checked exceptions" - at least in the Java camp that's all the 
>> rage ;)).
> 
> I will not start that holly war about what you said :) I just say that I 
> will think about more and more user friendly messages on wrong user input.

Hold on: the one (exceptions vs return error codes) has /nothing/ to do with 
the other (user-friendly error messages). Just to be on the same page here...
 
> I wanted to simplify a life of a developer and a user of console application. 
> But developer will be informed about "errors" through the exceptions.

Yes, your intentions were clear. But did you just read what I wrote about 
/when/ to use exceptions?

In fact, you're not - necessarily - simplifying "the life of a developer" by 
using exceptions. Au contraire, you force them to use patterns like RAII (which 
is mostly a good thing by itself), think about whether their code is 
"exception-safe" etc.

There is probably a reason why completely new languages like Swift come 
completely without exception handling - which raises interesting questions (pun 
intended), as the main "GUI framework" (Cocoa/ObjC based) still uses - and 
throws - exceptions then and when... but that's yet another story ;)

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

Re: [Interest] Args

[Till Oliver Knoll]

> Am 04.05.2017 um 05:44 schrieb Igor Mironchik :
> 
> 
> 
> 2017-05-04 11:41, Konstantin Tokarev пишет:
>> Using exceptions in arguments parser is something that just cannot be 
>> justified.
>> 
> 
> Why not?

Even in the danger of starting a huge debate about "exceptions vs return error 
code" here are my thoughts about it:

Exceptions should just be used for... well, /exceptional/ cases.

So what would be an "exceptional case" for a command line parser then? 
Certainly not wrongly provided arguments. Humans tend to misspell words all the 
time, so that's "the norm": business as usual for a command line parser to 
validate the input and inform the user appropriately (with a usage help, 
similar spelled commands etc.). Nothing which cries "exception!" here IMHO.

The only thing I could think of in a 10 second brainstorming which could be 
considered "exceptional" is when e.g. "stdin" (or some socket even from which 
to read commands, but even this would be a bordercase, as it could be 
considered "normal" that a socket cannot be opened) cannot be opened for 
reading (which is somewhat a constructed example, as arguments are usually 
passed as input parameters to main() anyway - but you get the idea).

The internet is full of articles - and opinions - about when to use exceptions, 
and when not (and we haven't even touched the topic of "unchecked vs checked 
exceptions" - at least in the Java camp that's all the rage ;)).

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

Re: [Interest] Qt at the C++20 era

[Till Oliver Knoll]

> Am 01.05.2017 um 17:51 schrieb Jean-Michaël Celerier 
> :
> 
> https://twitter.com/anastasiak2512/status/858809432792338432
> https://twitter.com/sebrose/status/858347156427636738
> https://twitter.com/hatcat01/status/858360761424523266
> 
> I think that the Qt project, community, and company would have everything to 
> win to put its weight behind such a proposal.

Interfaces. Signals and slots. And properties (aka "introspection").

And all this in C++ by 2020! (Like 30 years later than Qt introduced 
signal/slots).

Awesome times :)

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

Re: [Interest] Qt "Desktop App" for Microsoft Store

[Till Oliver Knoll]

Am 30.04.17 um 08:57 schrieb Robert Iakobashvili:
> Hi,
> 
> Has anybody tried to make and publish a Qt-based Windows "Desktop App"
> at the Microsoft App Store?
> 
> Any experience you have to share?

I personally have no experience to share, however it seems pretty well
described in the Qt docs:

  http://doc.qt.io/qt-5/winrt-support.html

Cheers, Oliver

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

Re: [Interest] Crash with Qt application that use OpenGL

[Till Oliver Knoll]

[with reference to:
http://lists.qt-project.org/pipermail/interest/2016-October/025009.html]

Am 21.04.17 um 15:17 schrieb Xavier Bigand:
> This is not directly related, but that it is why I thought it was a Qt
> bug. It it so easy in OpenGL to use badly API and having a good result
> that will work on almost all configurations.

While it is not (directly) related to the nVidia driver crash that you
are observing it demonstrates nicely my prior point "a driver must not
crash" by example. Even if you feed the driver with bogus data.

When you look at the actual Qt bug report that resulted out of this:

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

"it will call API glVertexAttribPointer but input parameter pointer is a
pointer to system memory vertex data, which violates spec because
OpenGL 4.1 context needs to bind a vertex buffer before calling
glVertexAttribPointer, so AMD OGL driver will report the following error
" glVertexAttribPointer in a Core context called without a bound
Vertex Array Object [which is now required for Core Contexts]"

Yes, Qt uses the OpenGL API wrong here (for the simple reason that the
code in question was written against OpenGL 2, where it was perfectly
valid - jut not with a "Core Context" anymore).

But note the two points:

  1. "which violates spec" and
  2. "AMD OGL driver will report the following error"

This is how a properly validating driver is supposed to behave :)

Disclaimer: I am neither working for AMD nor nVidia and I acknowledge
that both drivers may have their quirks ;)

> 
> Dislike in Vulkan there is no way to check if APIs are correctly used,
> so when we test our engine we can't really expect that it will run
> everywhere just because it runs on our computer.

"There is no way" because with Vulkan most of what the driver did
previously - that includes input validation -  is now in the
responsibility of the application itself.

In fact, the application is now in control of the "command queue", and
as such also responsible that the "data types fit together" and the data
arrives in the proper order (or is otherwise synchronised with
"barriers"). The Vulkan driver only does the bare minimum, but if you
pass it a pointer which points into system RAM instead of GPU RAM (when
such one is expected) then Bad Things Happen(tm).

That's why people say you are "closer to the metal" - there is much much
much less between the GPU and your application. Namely much less
validation (which in OpenGL is required by the specs, see above).

Simply said: most of the code (logic) which was previously in the OpenGL
driver is now in your application (which knows much better about the
nature of the data it wants to render, and hence can also spare most of
the input validation which - again by the specs - a former OpenGL driver
always *had* to do).

So it is not quite correct when you say "there is no way to check if the
API is used correctly" - it just happens that it is YOUR application now
that is supposed to validate the data (or at least it has to know
exactly what it does ;)).


Cheers, Oliver


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

Re: [Interest] Crash with Qt application that use OpenGL

[Till Oliver Knoll]

> Am 20.04.2017 um 21:04 schrieb Xavier Bigand :
> 
> It is not necessary a bug from Nvidia, it can comes from bad parameters to 
> functions like glDrawElements. Nividia drivers don't check a lot the 
> parameters and given wrong values can cause buffer overflows,...

Still a bug in nVidia code then. Again, an OpenGL driver is *not* supposed to 
crash, even with bad input. That's what the OpenGL standard mandates...

And buffer overflows, God beware :) Report this to nVidia asap (you might get a 
reward for discovering a security hole ;)).

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

Re: [Interest] Crash with Qt application that use OpenGL

[Till Oliver Knoll]

> Am 20.04.2017 um 19:27 schrieb Xavier Bigand :
> 
> ...
> 
> It seems to be specific to the following configuration:
>  - Nvidia geforce 1060 or 1070 at least (can't reproduce with a 980 GTX)

So you actually tried with another GPU (possibly different driver) and said 
yourself that you cannot reproduce this. So why suspect Qt/QML in the first 
place? I do not understand this logic...

Did you try upgrading (or even downgrading) the driver? That is, what one 
usually does first when encountering GPU driver related crashes? What was the 
outcome?

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

Re: [Interest] Crash with Qt application that use OpenGL

[Till Oliver Knoll]

> Am 20.04.2017 um 19:27 schrieb Xavier Bigand :
> 
> Hi,
> 
> 
> I think that I have found a crash in the nvidia drivers made by QtQuick.
> 
> On the computer on which our application crash at startup in the nvoglv32.dll 
> QtCreator crash too in the same way, that it why I suspect that it comes from 
> Qt.

Hold on... you have a "crash" caused by a given library (here: nvogl32.dll) 
which makes several other applications go down, and you suspect the /other/ 
applications of being the culprit? What's the reasoning behind that?

Even if you throw bad OpenGL at a driver that driver is *never* supposed to 
"crash".

So why not at least try the same applications with another GPU/driver first?

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

Re: [Interest] qobject_cast

[Till Oliver Knoll]

> Am 20.04.2017 um 08:05 schrieb nikita baryshnikov :
> 
> Hi, Igor
> 
> Your example is incorrect, cause you forget about Q_OBJECT macro in
> Channel class

That's what I just wanted to add as a general remark, because it is a common 
pitfall (at least for me): /every/ class which - directly or indirectly - 
inherits from QObject must have a Q_OBJECT declaration, /even/ if it doesn't 
emit or consume Qt signals or provides slots. IF that class is expected to 
behave nicely with said qobject_cast "and friends" (which is almost alway a 
desireable feature).

Q_OBJECT not only provides the glue to provide "slot" methods, but also 
generates the required meta information.

In fact, IIRC that's another advantage of qobject_cast over dynamic_cast: it 
works by design "across library boundaries" (dynamic_cast might or might not 
work, depending on whether the libraries share the same address space or other 
compiler-specific settings). 

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

[Interest] Google "guetzli" JPEG encoder Qt image plugin

[Till Oliver Knoll]

Hi all,

A simple QImageIOPlugin based JPEG "Guetzli" encoder is available here:

  https://github.com/till213/GuetzliImageIOPlugin

Guetzli-generated images are typically 20-30% smaller than images of equivalent 
quality generated with libjpeg. All credits go to Google Research Europe here. 
Also refer to 
https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html?m=1

The plugin supports writing JPEG images with the "quality" option (lowest 
possible value: 84). It takes a lot of CPU time and memory, so feel free to 
experiment :)


The plugin is currently developed on macOS, Windows 10 (MinGW) and FreeBSD 
using (at least) Qt 5.6.2 (lower 5.x Qt releases work probably, too), using the 
Qt Open Source License LGPL 3. The Google Guetzli encoder comes with its own 
Apache License 2.0.


Have fun,
  Oliver

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

Re: [Interest] macdeploy and lib dependencies

[Till Oliver Knoll]

> Am 10.10.2016 um 08:37 schrieb Nuno Santos :
> 
> Libs like libssl, libcrypto, libxml2, libplist, etc, All the dependencies of 
> libimobiledevice which is the lib I’m linking to. In the QtCreator project I 
> link with libimobiledevice and macdeployqt is able to copy and rereference 
> it, but it doesn’t do to the others making the bundle invalid in a another 
> system

AFAIK macdeploy*qt* will only deploy Qt libraries. Those link against *system* 
frameworks which you do not need to worry about (when it comes to deployment).

I don't know about libimobiledevice, but that doesn't sound like a genuine Qt 
library to me.

Means: you need to deploy it (and its dependencies) yourself. The 
"install_name_tool" is your friend here.

(And are we really talking about *desktop* Macs here?)




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

Re: [Interest] SSL broken hard on OSX

[Till Oliver Knoll]

> Am 21.09.2016 um 20:07 schrieb Jason H :
> 
> 
>>> Does anyone know how I can fix (not hide) these issues?
>> 
>> Option 1) upgrade OpenSSL
>> 
>> Option 2) use the native backend (SecureTransport) for SSL, not OpenSSL. 
>> SecureTransport is the default in Qt 5.6.
> 
> Thanks Thiago! But instructions are there instructions? Questions I have:
> 1. Which OpenSSL? 

The latest, stable version currently available on https://www.openssl.org/

;)


> a. How do I identify which OpenSSL Qt is using

By understanding how Qt locates dynamic libraries (using dlopen and friends).

http://doc.qt.io/qt-5/ssl.html

So it depends on the platform and "where Qt looks first".

> b. How do I upgrade it? (Brew?) 

Also possible. But be aware that when you distribute your application that you 
need to bundle the libs with your application bundle.

You may need to become friends with the "install_name_tool" in that case: 
http://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-executable-to-search-for-dylib-in-mac-os-x

> c. Must I specify a custom version in the .pro

Qt searches "dynamically" (dlopen) for suitable libraries (I think in the Qt 
docs "How to deploy your Qt application" it is described in detail). You can 
also define the OpenSSL library at compile time.

http://doc.qt.io/qt-5/ssl.html

> 2. How do I use SecureTransport in Qt? (I googled)
> a. Is this a .pro option?

Should be working "out of the box" when using Qt 5.6 and QSslSocket.

> b. Is this a recompile Qt thing?

Should be the default compile option since Qt 5.6 - so I strongly assume the 
stock Qt binary is compiled like this.

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

Re: [Interest] SSL broken hard on OSX

[Till Oliver Knoll]

> Am 21.09.2016 um 20:01 schrieb Thiago Macieira :
> 
>> On quarta-feira, 21 de setembro de 2016 19:52:45 PDT Jason H wrote:
>> I am on OSX 10.11.5. I've been using SSL successfully for a while, and I
>> fell into a habit of ignoring qt.network.ssl warnings: qt.network.ssl:
>> ...
>> 
>> But it seems now TLS is no longer working at all. I can't do any work
>> because everything happens over SSL, specifically TLSv1_2.
>> 
>> Does anyone know how I can fix (not hide) these issues?
> 
> Option 1) upgrade OpenSSL

Just to add to this: using OpenSSL on OS X/macOS is highly discouraged by Apple 
these days.

The stock version is some stoneage 0.9.8zf version, and recent Xcode/platform 
SDKs don't even ship with OpenSSL headers:

https://forums.developer.apple.com/thread/3897

"Since the version of openssl shipping with El Capitan is 0.9.8zf, it's not 
much use anyway since it doesn't include TLS 1.2."

and

"Sadly, it looks like we're not supposed to use it any more.  As you say, it's 
included in the 10.10 SDK, but is deliberately missing from the 10.11 SDK."


So you need to build your own OpenSSL library from its latest sources and 
bundle it with your application. Taking the responsibility to update your 
application each time a critical error is found in OpenSSL.


> 
> Option 2) use the native backend (SecureTransport) for SSL, not OpenSSL. 
> SecureTransport is the default in Qt 5.6.

On the other hand if you do as Thiago suggests (and I join in here), then the 
OS vendor takes care of keeping a security relevant component up to date, 
namely SecureTransport.

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

Re: [Interest] Swift and Qt? (formally?)

[Till Oliver Knoll]

Am 19.09.16 um 18:52 schrieb Robert Iakobashvili:
> On Mon, Sep 19, 2016 at 5:25 PM, Jason H  wrote:
>> There is a 9-month old github; https://github.com/msorvig/qt-and-swift for 
>> integrating the two.
>>
>> Are there any plans for formal Qt support of Swift? Obj-C is painful.
> 
> +2

As far as I know there is no "Swift++" compiler available, that is a
compiler which can compile "Swift + C++", right? In analogy to ObjC++.

So unless that's the case the common denominator between "Qt" and
"Swift" is C. Of course one could "wrap" the Qt objects - somehow - into
C structures and make them "look" like objects (and vice versa). But
that would be a clumsy approach.

So unless we do have C++ support in Swift my guess is that Qt can do
little here.


Cheers, Oliver

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

[Interest] FYI: Qt 5.6.1 on macOS "Sierra" - Maintenance Tool runs again

[Till Oliver Knoll]

Hi all,

For those interested: the MaintenanceTool.app of the stock Qt 5.6.1
binary runs again on the latest public beta of macOS 10.12 "Sierra".

It used to segfault as soon as you would double-click on it on previous
beta versions of "Sierra".

Apparently someone at Apple /did/ notice my crash reports after all ;)

Everything else (Qt Creator, my own application) runs as expected so far
(with the little tests I did).

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

[Interest] [OT] Re: [QtCharts] Logarithmic QDateTimeAxis

[Till Oliver Knoll]

> Am 27.06.2016 um 21:55 schrieb Thompson, Adam B. :
> 
> ..., but we plan to move to Qt 5 when we have time/funding. ...
>  
> Some of our data sets are time-dependent and are often extrapolated hundreds 
> or thousands of years in the future. 

So I guess eventually you /will/ have time and funding?

Just tell your financial guys that they'll need to "extrapolate their budget a 
couple of thousands of years into the future, too" and compare that to the tiny 
little speck of money that it would cost /today/ migrating your project to Qt 5.

Problem solved.

;)

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

[Interest] [OT] Re: Utilizing the GPU, how to start?

[Till Oliver Knoll]

> Am 12.07.2016 um 11:41 schrieb Sze Howe Koh :
> 

>  Note that it is currently summer holidays in Norway, so
> most of the staff are on leave till the end of July. 

They have summer in Norway?

*duck and cover*

;)

Cheers,
  Oliver

P.S. At least "our" summer in Switzerland is terribly letting us down again 
currently.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt ownership model

[Till Oliver Knoll]

> Am 05.06.2016 um 14:49 schrieb Thiago Macieira :
> 
>> Em sábado, 4 de junho de 2016, às 15:55:47 BRT, Антон Жилин escreveu:
>> 3. Widgets without a parent are usually used with QSharedPointer:
>> auto obj = QSharedPointer::create(...);
>> -- Not so great, it is verbose and does not line up with standard library
> 
> All those class names and function names with capital letters don't line up 
> with the standard library, so the argument is not accepted.

And that's why I /love/ Qt so much and would choose it anytime again over an 
API that_looks &*like_this();

A small performance penalty is always accepted, in exchange for readability and 
ease of use.

;)

Just my 0.02$

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

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 16.03.2016 um 23:41 schrieb Bob Hood :
> 
>> On 3/16/2016 3:37 PM, André Pönitz wrote:
>>> On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
 I can connect to Foo::bar either way. If I don't intend to ever use
 the old-style connect syntax, is there a reason to have "public
 slots:" anymore?
>>> One reason that for me it’s fundamental: Readability of your code !!!
>> It doesn't make the code more readable then a comment
>> 
>>// This is a slot !!!
>>void foo();
> 
> I would argument that it does when you have legions of people out there 
> already conditioned to this:
> 
>...
>public slots:
>void  bar();
>void  foo();
>   

This.

:)

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

Re: [Interest] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)?

[Till Oliver Knoll]

Am 17.03.2016 um 23:21 schrieb René J. V. Bertin :

>> ...
> 
> So, does this mean that font rendering can use Freetype instead of CoreText 
> now, 
> and thus potentially benefit from the rendering quality provided by the 
> Infinality patches (as well as better support for less common font weights)?

According to

  https://wiki.qt.io/New_Features_in_Qt_5.6

"Optional support for using FreeType on Mac OS X" is now available.

Cheers,
  Oliver

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

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 16.03.2016 um 22:37 schrieb André Pönitz :
> 
> On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:
>>> I can connect to Foo::bar either way. If I don't intend to ever use
>>> the old-style connect syntax, is there a reason to have "public
>>> slots:" anymore?
>> 
>> One reason that for me it’s fundamental: Readability of your code !!!
> 
> It doesn't make the code more readable then a comment
> 
>   // This is a slot !!!
>   void foo();

Extend your example to a dozen or so slots and you'd quickly agree that

private slots:
  void foo();
  void bar();
  void baz();
  ...

is much more readable, as compared to, say, repeating your comment or writing 
something like "The following 12 methods are slots (but the 13th isn't! And I'm 
pretty sure that the next Joe Programmer will insert his/her 
"barFooWhichIsNotASlot()"-method randomly between the first 12 methods 
anyway... so whatever!)"

Off course you can try to emphasise your slots with nice ASCII art comments, 
start a fight with your colleagues about the style guide for comments...

Or just write

  private slots:

;)

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

Re: [Interest] Are slots even needed these days?

[Till Oliver Knoll]

> Am 17.03.2016 um 07:39 schrieb André Somers :
> 
> ...
> I find that much more readable than having to look in some signals section to 
> find if there is a notification signal, and then in some slots section to see 
> if the setter is perhaps declared as a slot or not. 

That's an entire different view than what I've had so far (since so far I've 
never used those new "PFM"-style connections. What does it even mean? "Printing 
with Manual Formatting"? ;))

And I must say André's point makes very much sense, too :)

And if I'm not completely mistaken with the old style connections an explicit 
[private|protected|public] slots: section is always needed, in order for the 
moc to recognise the method to be a "slot", no?

Or is this also just syntactical sugar when it comes to /connecting/ a slot 
(ignoring the generated meta data for the moment)?

For instance I know that the private|public specifier has absolutely no 
influence on the "connectability" of a slot, that is you can connect a signal 
to a private slot from /outside/ the class...

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

Re: [Interest] How to properly delete qApp?

[Till Oliver Knoll]

> Am 16.03.2016 um 13:01 schrieb Till Oliver Knoll 
> <till.oliver.kn...@gmail.com>:
> 
> 
> ...
> 
> Oh, and somewhat related: just make double-sure on OS X that your Qt plugin - 
> specifically all GUI and paint operations - happen in the /main/ thread of 
> the host application (if that's possible at all, i.e. you control/own the 
> host app, too). It won't work otherwise (unless you hack your own Cocoa event 
> queue for the host application, and even then you're in a mine field whenever 
> calling other Cocoa APIs... just google for "Qt event queue thread OS X" or 
> the like...)

Just to clarify: this is not a limitation of the Qt implementation on OS X 
(iOS), but really a limitation (by design) of the underlying Cocoa.

And yes, having a Qt event loop running in a thread other than the "main" 
thread /does/ work on Windows and Linux (possibly/likely other Unix) - just not 
on OS X/Cocoa.

Here's a link for starters:

  
http://stackoverflow.com/questions/22289423/how-to-avoid-qt-app-exec-blocking-main-thread

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

Re: [Interest] How to properly delete qApp?

[Till Oliver Knoll]

> Am 16.03.2016 um 11:51 schrieb Nuno Santos :
> 
> Hi,
> 
> My application is targeted to run as a software plugin inside another third 
> party application. When a instance of my plugin is instanciated I check if 
> qApp exists. If so, I will use that pointer, otherwise I will reuse the 
> pointer. I also increment a counter to know how many instances of my 
> plugin are active. When the plugin is deleted I check the counter. If it gets 
> to zero I will delete qApp.

I don't think you're supposed to delete qApp (btw which is just a convenience 
macro for QCoreApplication::instance, since Qt 5.x I think).

The way to end a Qt application is to tell it to QCoreApplication::exit which 
will then leave the (existing) Qt event loop with the given return code.

GUI applications usually QGuiApplicatiob::quitOnLastWindowClosed.

Once the Qt event queue is left Qt does all cleanup (or doesn't: there's quite 
a bit of discussions every then and when about memory leaks when Qt apps quit: 
but since they quit anyway those "global left-overs" are considered "to be 
dealt with by the OS - there are arguments for and against this practise...).

In any case, you shouldn't interfere with the Qt cleanup. Specifically the 
global Qt app instance "belongs to Qt".


Why do you query the state of qApp anyway? Do you have multiple instances of 
your Qt plugin (in a possibly non-Qt host application) and want to prevent the 
launch of the Qt event queue multiple times?

Oh, and somewhat related: just make double-sure on OS X that your Qt plugin - 
specifically all GUI and paint operations - happen in the /main/ thread of the 
host application (if that's possible at all, i.e. you control/own the host app, 
too). It won't work otherwise (unless you hack your own Cocoa event queue for 
the host application, and even then you're in a mine field whenever calling 
other Cocoa APIs... just google for "Qt event queue thread OS X" or the like...)

Cheers,
  Oliver

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

Re: [Interest] Translating plural with is/are

[Till Oliver Knoll]

> Am 07.03.2016 um 19:56 schrieb Jason H :
> 
> 
>> 
>> If you provide a translation file, the message with %n will be translated 
>> according to the language's plural rules. For English, you'll have two 
>> translations for the same source message.
>> 
>>"At least one upper case character is required" (a)
>>"At least %n upper case characters are required" (b)
>> 
>> QTranslator takes care to apply the correct selection based on the number 
>> that 
>> you passed.
> 
> Ok I'm getting there, but how do I specify this string (a) or that string (b)?
> What's the qsTr() line look like?
> qsTr( ? )

http://doc.qt.io/qt-5/i18n-plural-rules.html

and

http://doc.qt.io/qt-5/i18n-source-translation.html

-> chapter Handling Plurals

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

Re: [Interest] Minimum required OS X SDK for Qt 5.6?

[Till Oliver Knoll]

 

> Am 02.03.2016 um 20:20 schrieb NoRulez :
> 
> Hello,
> 
> what is the minimum required Mac OS X SDK?
> I tried it with MacOSX10.8.sdk and C++11 enabled but it fails with (I
> think that C++11 is not fully supported in 10.8):

Just to clarify: you need to distinguish between "(Minimum) BUILD  SDK" and 
"Minimum DEPLOYMENT Target".

See here: 
http://lists.qt-project.org/pipermail/interest/2014-October/013718.html

QMAKE_MAC_SDK and QMAKE_MACOSX_DEPLOYMENT_TARGET is what you're after.

Usually you want to build against the latest SDK (e.g. "macosx10.11"). Setting 
the Deployment Target to a lower value (e.g. "10.8") will "weak-link" any 
symbols which were not available on that target. Off course if you want to use 
features of a later SDK you need to dynamically check for their existence.

(I am not an Xcode/Cocoa/ObjC expert, so not 100% sure about the "weak-linking 
part" - but as long as you don't use Cocoa directly, but Qt exclusively, you 
don't need to bother anyway: Qt does it all for you, down to the lowest 
supported OS X).

Not sure about C++11 support (in case that's the problem here anyway), but 
according to 

  http://blog.michael.kuron-germany.de/2013/02/using-c11-on-mac-os-x-10-8/

it should be supported since OS X 10.7.

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

Re: [Interest] Pixmap redraw on OS X Retina display zoomed-in 4x?

[Till Oliver Knoll]

> Am 22.01.2016 um 20:44 schrieb Edward Sutton :
> 
> 
>> On Jan 22, 2016, at 1:30 PM, Jason H  wrote:
>> 
>> >Look for something called DevicePixelRatio... Also QML Screen attached 
>> >property/element. It might be a shortcoming in Qt, but you should be able 
>> >to work around it.
> 
> Thanks Jason.  I have same issue on iOS as well.
> 
> I will Google Qt examples for DevicePixelRatio. I am puzzled why Qt scaling 
> does not occur automatically?  
> 
> Maybe it does automatically scale for QML.  I am using QWidgets.

Just a shot into the blue: at least on OS X have to be made "Retina ready" by 
setting some property in the Info.plist file, something like 
"NSHighResolutionCapable" (true). Plus the "principal class" (?) has to be set 
there as well, as a precondition.

Off course /not/ setting those values should not result in "4x magnified 
images" on a retina screen. Sounds like Qt thinks it needs to draw the @2x 
image resources, whereas OS X treats the application as "non-retina capable".

What about plain text (in widgets)? Does it look "retina-like"? Or pixelated 
(which would indicate that the OS treats the app as "non-retina capable") on 
the retina screen?

Maybe just some hope: my own QWidget/QGraphicsView based app looks fine, 
including QGraphicItems in the QGraphicView. Latest Qt 5.5.1 stock binary, El 
Capitan.

Even moving the app between retina/non-retina screens works as expected: the Qt 
app redraws itself with the appropriate resolution as soon as more than 50% of 
the window overlap with the "other" screen.

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

Re: [Interest] [Announce] Qt 5.6 Beta released

[Till Oliver Knoll]

> Am 18.12.2015 um 10:18 schrieb List for announcements regarding Qt releases 
> and development :
> 
> Hi all,
> 
> 
> Qt 5.6.0 beta is finally out, see 
> http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ .
> 
> 
> It was quite hard at this time ;) Big thanks to everyone involved!
> 
Xmas present very much appreciated though ;)

Have a well deserved holiday season!

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

Re: [Interest] Convertion between QImage to QPixmap taking to much time.

[Till Oliver Knoll]

> ...
> 
> When I put the timer to see how much time Qt spending to create QPixmap, I 
> realize that I converting  from Qimage to QPixmap taking ~20 times more time 
> than crating Qimage from buffer.

Yes, I guess that's perfectly possible. That depends off course on the original 
data layout and the native pixmap format of the target platform (btw what 
platform are we talking about?).

Bytes might need to be swizzled, padded, memory aligned etc.

You might try to directly load the raw data into a QPixmap, if all you want is 
to display the data anyway:

  http://doc.qt.io/qt-5/qpixmap.html#loadFromData

You can try with different raw formats/byte ordering (if possible), to see 
whether that makes any difference in conversion time.

If all that fails try with OpenGL (textures).

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

Re: [Interest] Is here memory leaks?

[Till Oliver Knoll]

> Am 08.10.2015 um 22:21 schrieb Thiago Macieira :
>  Leaks-because-of-exit don't 
> count, except for pedantism.

Sorry to be pedantic one here, but leaks mean that d'tors are not called, even 
when at process exit memory is reclaimed by the OS. And not calling a d'tor 
could imply that not just memory is leaked, but other resources, too. E.g. file 
locks could remain in place (even though I think most/all OSs also reclaim open 
file descriptors, but not sure...), network connections could be terminated 
"unexpectedly", transactions could remain open etc.

Not saying that this is the case with Qt objects, but I am the pedantic one who 
deletes (tries to ;)) every single object that got allocated in my code at 
program exit...

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

Re: [Interest] OS X 10.11 'El Capitan' and Qt 5.5.0 - first experience

[Till Oliver Knoll]

>> Am 03.10.2015 um 19:24 schrieb Thiago Macieira <thiago.macie...@intel.com>:
>> 
>> On Saturday 03 October 2015 16:42:42 Till Oliver Knoll wrote:
>> And as a bonus: the 1000s of bogus (?) warnings which I saw with Qt
>> 5.5.0 initially (on OS X 10.10 for sure - not sure anymore about OS X
>> 10.9) are now gone, too (I heard those Warnings will be fixed with the
>> upcoming Qt 5.5.1, but they seem to be gone with Xcode 7 as well). Can't
>> remember anymore what those Warnings were all about, but they originated
>> from some Qt header, IIRC. You know what I'm talking about when you've
>> experienced those Warnings
> 
> The warnings are fixed in 5.5.1. They were correct.

I compiled a few randomly selected Qt examples ("Main Window", "Menus", ...), 
and I definitively did not get that warning again.

(Just in case some custom compiler flags which I set in my actual little 
project were now interpreted differently by Xcode 7).

In all cases I saw the -Wall flag during compilation.

> 
> If Apple disabled the warning in the Xcode 7.0.1 update, it was wrong of them.

The warning I was talking about was indeed
 
http://qihome.org/qiliang/2015/07/04/qt-5-5-0-on-os-x-fix-for-winconsistent-missing-override-warning/

But quickly browsing through the corresponding description and bug report that 
warning was more about a "proper compiler detection" issue and a "wrong warning 
group" which was the follow-up error (warning):

 unknown warning group '-Winconsistent-missing-override', ignored 
[-Wunknown-pragmas]
Q_OBJECT

And now it starts to make sense for me: the Qt headers enabled some warning 
feature which wasn't present on Xcode 6.4 and below - due to a wrong version 
checking (which is/will be fixed in Qt 5.5.1). That feature is now supported 
since Xcode 7, hence that "unknown warning group" warning disappears (also 
supported by the fact that Xcode complained in 3 places in my own code about a 
missing "override" declaration).

Apple simply added the detection for missing "override" declarations in Xcode 7 
- they didn't do anything wrong ;)

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

[Interest] OS X 10.11 'El Capitan' and Qt 5.5.0 - first experience

[Till Oliver Knoll]

Hi all,

a very quick experience feedback for Qt 5.5.0 (stock binary
distribution) on OS X 10.11 'El Capitan':

* I had to uncomment my previous entry QMAKE_MAC_SDK = macosx10.10

IIRC I had to add this entry to my *.pro (qmake project) files for some
previous Qt version (5.4?) which otherwise would default to the SDK
10.9, and hence it would not compile on OS X 10.10 'Yosemite' (with the
above 10.10 SDK entry it would still also compile on 10.9 'Mavericks',
with the then current Xcode version which apparently also shipped an SDK
10.10 - in combination with a QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.8, off
course).

With the current Qt 5.5.0 and the above entry I now get on 10.11:

  Project ERROR: Could not resolve SDK path for 'macosx10.10'

So uncommenting that entry works (or setting it explicitly to
QMAKE_MAC_SDK = macosx10.11).

(I yet have to verify what happens on 10.9 'Mavericks' if above entry is
uncommented, with Qt 5.5.0).

* Most importantly: Qt applications seem to support "split view"

Yay! Both Qt Creator and my own application (widget based) support the
new OS X 10.11 "split view" feature! I read somewhere that one (probably
of several) preconditions for applications to support "split view" was
that they'd need to support Cocoa's "auto-layout". Seems like Qt apps
just do that (at least from a Cocoa point of view: Qt layouts its
widgets with its own logic anyway).

Case in point: MS Office Word 2011 does /not/ support split view! So it
is not something which is to be expected to work for just any application...

* The compiler which comes with Xcode 7 seems to catch a few more Warnings

I have C++11 support enabled, and the compiler spit out a few "method
not marked as override" Warnings, something which it did not do
previously (on OS X 10.10 or 10.9/Xcode 6.x) (and which I also did not
see so far on Windows/Mingw or Kubuntu 14.04 LTS with the respective
compilers). Nice :)

And as a bonus: the 1000s of bogus (?) warnings which I saw with Qt
5.5.0 initially (on OS X 10.10 for sure - not sure anymore about OS X
10.9) are now gone, too (I heard those Warnings will be fixed with the
upcoming Qt 5.5.1, but they seem to be gone with Xcode 7 as well). Can't
remember anymore what those Warnings were all about, but they originated
from some Qt header, IIRC. You know what I'm talking about when you've
experienced those Warnings ;)


That's all for now, folks.

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

Re: [Interest] icons in menus

[Till Oliver Knoll]

> Am 13.09.2015 um 16:50 schrieb René J.V. Bertin :
> 
> Hi,
> 
> Is it to be expected that I have icons in the items of the global menubar of 
> the Assistant, Designer and Linguist apps, using the Qt 5.5.0 Cocoa build?

No.

Applications on OS X don't have icons in the menu - as per Apple HIG.

Also refer to http://doc.qt.io/qt-5/qt.html#ApplicationAttribute-enum

(Not sure whether it is necessary to explicitly set 

Qt::AA_DontShowIconsInMenus

/before/ instantiating QApplication or whether that's set by default on OS X)

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

[Interest] [OT] Re: Qt 5.5.x

[Till Oliver Knoll]

> Am 12.09.2015 um 10:19 schrieb Till Oliver Knoll 
> <till.oliver.kn...@gmail.com>:
> 
> 
>> Am 11.09.2015 um 19:59 schrieb Matthew Woehlke <mwoehlke.fl...@gmail.com>:
>> 
>>> On 2015-09-11 13:41, Till Oliver Knoll wrote:
>>> You can further reduce the "dependency tree" of your sources by 
>>> making use of the private "d-pointer" pattern (there is a name for
>>> it which currently escapes me)
>> 
>> PIMPL? ;-)
>> 
>> https://en.wikipedia.org/wiki/Pimpl
> 
> Exactly :) Even though I had the term "Cheshire Cat" in mind :) (I yet have 
> to google why that pattern is named after a cat).

https://de.m.wikipedia.org/wiki/Cheshire_Cat

The cat in Alice in Wonderland, which disappears when it grins :)

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

Re: [Interest] Qt 5.5.x

[Till Oliver Knoll]

> Am 11.09.2015 um 19:59 schrieb Matthew Woehlke <mwoehlke.fl...@gmail.com>:
> 
>> On 2015-09-11 13:41, Till Oliver Knoll wrote:
>> You can further reduce the "dependency tree" of your sources by 
>> making use of the private "d-pointer" pattern (there is a name for
>> it which currently escapes me)
> 
> PIMPL? ;-)
> 
> https://en.wikipedia.org/wiki/Pimpl

Exactly :) Even though I had the term "Cheshire Cat" in mind :) (I yet have to 
google why that pattern is named after a cat).

But while we're there, quoting from that article:

"One type of opaque pointer commonly used in C++ class declarations is the 
d-pointer. The d-pointer is the only private data member of the class and 
points to an instance of a struct. Named by Arnt Gulbrandsen of Trolltech, this 
method allows class declarations to omit private data members, except for the 
d-pointer itself.[6] The result: (a) more of the class implementation is hidden 
from view; (b) adding new data members to the private struct does not affect 
binary compatibility; (c) the header file containing the class declaration only 
needs to #include those other files needed for the class interface, rather than 
for its implementation. One side benefit is that compilations are faster 
because the header file changes less often. The d-pointer is heavily used in 
the Qt and KDE libraries."


Couldn't have explained it better :) Oh and yes, Trolltech is the initial 
company(*) that brought us Qt! ;)

Cheers,
  Oliver


(*) IIRC they did have (slightly) different names before that___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.5.x

[Till Oliver Knoll]

> Am 12.09.2015 um 10:31 schrieb Samuel Gaist :
> 
> 
> Because the d pointer is the equivalent of the smile of the Cheshire Cat, the 
> only visible part: d => D

Ah, now it makes /completely/ sense to me! D -> smile... clever :) Learnt 
something new about C++ today! ;)

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

Re: [Interest] Qt 5.5.x

[Till Oliver Knoll]

> Am 11.09.2015 um 18:48 schrieb "m...@rpzdesign.com" :
> 
> Mr Weeks -> You were correct.
> 
> A dependency was touched. And that had a domino effect on untouched code.

You can further reduce the "dependency tree" of your sources by making use of 
the private "d-pointer" pattern (there is a name for it which currently escapes 
me - Qt itself makes heavy use). That is, you move the declaration of all your 
(private/protected) members into a "private class", implemented in the 
corresponding *.cpp. It gets a bit tricky for protected members, if you need to 
access them "directly" (without setter/getter) from subclasses. But there's a 
solution for that, too, with the "d-pointer pattern" - see Qt sources ;)

By moving all member declaration and instantiation away from the class *.h 
header into the *.cpp file you potentially avoid indirect dependencies. Even 
more, now you can add/change/remove class members without changing the class 
header! No invalidation of sources which use your class (read: no recompile).

Another "trick": pass along arguments as references/pointers and use "forward 
declarations in your headers (#include the other headers only in your 
implementation *.cpp files).

In general: only #include what's really necessary, where it is necessary.

Oh, and don't use libraries which make heavy use of templates such as boost ;) 
(the last point not to be taken too seriously. But template expansion might 
generate quite a lot of code, might generate additional dependencies and in 
general creates additional work for the parser, prolonging compile time in 
general).

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

Re: [Interest] Dynamic build of Qt for iOS...

[Till Oliver Knoll]

> Am 10.09.2015 um 09:54 schrieb Igor Mironchik :
> 
> Hi guys,
> 
> Is it possible to build Qt dynamically for iOS? 

I'm not an iOS expert but I think people on this list have mentioned that it is 
against the App Store Rules to link dynamically against "private" Frameworks 
(as opposed to "system"/pre-installed Frameworks provided by iOS itself). No?

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

Re: [Interest] OS X Deployment - question

[Till Oliver Knoll]

> Am 02.09.2015 um 09:48 schrieb Ziggy Uszkurat :
> 
> Hi there,
> 
> When I run macdeployqt, it installs frameworks as expected. However, the ones 
> it installs are of a different size to the ones in QT/lib. For instance, 
> QtCore is 5.9 MB in my app, but 6.3 MB in the QT/lib directory. Oddly, the 
> frameworks in QTCreator are the same size as the ones installed into my app. 
> Is this correct?

Hmm, maybe macdeployqt skips the Qt *.h headers?

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

Re: [Interest] Mac with Retina Display - Look is Pixilated with Qt-5.4.2

[Till Oliver Knoll]

 Am 22.07.2015 um 08:43 schrieb Robert Iakobashvili corobe...@gmail.com:
 
 On Wed, Jul 22, 2015 at 9:16 AM, Hamish Moffatt
 ham...@risingsoftware.com wrote:
 On 22/07/15 15:52, Robert Iakobashvili wrote:
 
 Gentlemen,
 A user pointed to the issue on
 Mac Book Pro 15 inch mid 2015. AMD Radeon R9 graphic card,
 15.4-inch, 2880 x 1800 screen, Mac OS 10.10.4.
 and mentioned that the look is pixelated as the application
 does not support Retina.
 
 Unfortunately, I do not have such expensive HW to
 reproduce the issue.
 
 A patch to support 2x and 3x images
 from Morten Sorvig has been applied
 and images 2x and 3x are inside:
 
 https://codereview.qt-project.org/106717
 https://codereview.qt-project.org/106705
 
 Is there something else to be done with Qt-5.4.2
 like defining some HIGH-DPI, etc?
 
 You need to add two keys to your Info.plist:
 
 a boolean key NSHighResolutionCapable with value TRUE;
 a string key NSPrincipalClass with value NSApplication.
 
 
 Hamish
 
 Dear Hamish,
 I'll try it.

Besides, you don't necessarily need Retina capable hardware: the Quartz Debug 
Extensions ((?) check optional developer downloads, either in Xcode or, more 
likely, on Apple's developer homepage) allow you to run your desktop in Retina 
mode to test your application.

Off course on a non-Retina display everything appears 2 times as big (and you 
effectively loose desktop space by the corresponding factor), but like this 
it is possible to visually debug your @2x resources and easily spot pixmaps 
with low resolutions etc.

And off course you easily detect whether your application has been enabled for 
Retina (see Info.plist related answer before).

Finally this is still a good starting point:

  
http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/

Note that in most cases you really just need to enable Retina capability and 
provide @2x resources (bitmaps). Qt will take care of the rest! Even if you 
draw with a QPainter Qt will do just fine (the coordinates are always measured 
in points, under the hood QPainter converts them to pixels in the 
appropriate resolution - simplified).

Only if you really draw yourself on a pixel level (e.g. also OpenGL code 
which is /always/ pixel-based!) your drawing code needs to be aware of the 
actual resolution - and possibly switch/exchange bitmap resources on the fly, 
if the window is moved from a Retina to non-Retina display and vice versa.

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

Re: [Interest] Is moc obsolete?

[Till Oliver Knoll]

Am 08.07.15 um 20:56 schrieb Konstantin Tokarev:
 
 
 08.07.2015, 21:26, Till Oliver Knoll till.oliver.kn...@gmail.com:
  Am 08.07.2015 um 08:57 schrieb Igor Mironchik igor.mironc...@gmail.com:

  Hi,

  Does anybody know if Qt plans to remove moc in the future releases, let's 
 say in Qt 6?

 What's wrong with moc? :)
 ...
 It does not support many C++ features

Okay, got it. So you're not questioning moc as a separate build tool per
see, but rather its (lack of) capabilities when it comes to certain C++
features.

The subject Is moc obsolete seemed to imply one wanted to get rid of
any additional build tool (and only be using C++ compilers/linkers).


I must say that I consider myself not a hard core C++ coder, I try to
stay on the level that the Qt API offers.

Looking at that list in the given link, and given that I mostly write
applications, as opposed to general libraries (where templates can be
useful, for later re-use), I don't see many unsupported features that
I miss.

For instance I never had the need for nested C++ classes (for sure not
in combination with signals/slots). Am not saying that this would not be
useful, I simply never encountered this situation.

Then there are several points complaining about unsupported #macros,
e.g. defining a base class via a #macro - really? :) #macros are evil!

Multiple inheritance: yes, sometimes I ran into this issue (my second
class however was always a pure abstract class aka interface with no
implementation whatsoever!). So QObject needs to come first - big deal.
Not a problem for me... cosmetic issue.

Virtual inheritance - could be useful, but again: nothing I have
encountered myself, so cannot comment on that.

Function pointers as signal arguments: yes, I could imagine some useful
cases here.

I am not quite sure whether the last point - Enums and Typedefs must be
fully qualified for Signal and Slot parameters - is actually a
restriction or rather a feature.

And in the given example (For example, double and qreal are treated as
different types even though qreal is a typedef for double.) I am
actually not sure whether I'd consider a double equal to a qreal! Yes,
in the end they happen to be the same data structure, but I tend to say
that their types - in the strict sense - are in fact different.


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

[Interest] [OT] Re: Indie Mobil Program terminated?

[Till Oliver Knoll]

 Am 07.07.2015 um 07:43 schrieb Turunen Tuukka 
 tuukka.turu...@theqtcompany.com:
 ...
 
 Yup. It is raining today ;)
 
 Yesterday it was still nice and warm here.
 
 We are reading blog comments, mailing lists, forums, sales contact requests 
 etc. ...

And now... please stop that :)

Enjoy your well-deserved holidays instead! Never mind the weather :)

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

Re: [Interest] Camera not worknig on IOS

[Till Oliver Knoll]

 Am 07.07.2015 um 13:28 schrieb Harri Pasanen ha...@mpaja.com:
 
 On 07/07/2015 12:53, Till Oliver Knoll wrote:
 
 
 Am 07.07.2015 um 10:50 schrieb Daniel França daniel.fra...@gmail.com:
 
 Thanks for the answer.
 It seems that we still need to mix with native Cocoa code :( 
 https://forum.qt.io/topic/41071/solved-how-to-store-a-qimage-to-ios-camera-roll-photo-album/3
 https://forum.qt.io/topic/45295/solved-accessing-ios-photo-folder/5
 
 I haven't read the forum entry linked above, but in general your (iOS) 
 application needs special permission from the OS to access the Photos 
 folder (unlike on desktop, where its sufficient to set the 
 com.apple.security.assets.pictures.read-only Entitlement - once you have 
 that set, your sandboxed Mac application may access files in the Pictures 
 folder with traditional file IO, that is QFile etc.). (*)
 
 That permission needs to be explicitly asked for by the application, by 
 calling the proper APIs (and Qt does not yet provide a wrapper API for 
 those, so I understand).
 
 QStandardPaths just tells you where the location of Pictures is - once 
 your application has the permission from iOS. (On Android similar/the same, 
 I guess).
 
 It does not work like you describe on iOS.

Well, I described how it works on OS X (Entitlements).

I have no clue how it works on iOS (besides that a user explicitly needs to 
grant permission for an iOS app to access the Pictures folder) ;)

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

Re: [Interest] Objective C Category for QCocoaApplicationDelegate undefined symbols

[Till Oliver Knoll]

 Am 01.07.2015 um 10:54 schrieb Croitor Alexandru placi...@gmail.com:
 
 Hi.
 
 I'm trying to add an Objective C category to the QCocoaApplicationDelegate 
 class that is defined by the Mac OS X Cocoa platform plugin, to add / 
 override some methods. 

I am not an Obj-C expert, but I'd say you need to link at Build time with the 
class you're trying to add a Category to. You could try to extend the 
(non-existent) class MickeyMouse with a Category and you should see similar 
linker errors.

But basically your own findings already confirm the above.

That said, I am not sure if Obj-C Categories actually work with code that is 
dynamically linked by the application itself (aka plugin loading, dlopen() 
etc.). I understand that with Categories you can add methods even to class 
instances (such as instances of, say, NSString - and all subclasses thereof) 
that are instanciated by other libraries that don't even know about your 
Category. In other words, all happens at runtime. But maybe the system linker 
triggers some magic stuff, that is, injecting an extended message handler 
which first deals with your Category defined messages (aka methods, for the 
Obj-
C foreigners here on the list ;)) before passing them on to the original 
implementation message handler? And maybe that only works with libraries that 
you linked (dynamically) at Build time, but not at Runtime (with dlopen)? Not 
sure...

But let's assume that adding a Category to plugins works and all the linker 
needs is a class definition  implementation, also in the actual application 
(plugin host).

You already tried to link with QCocoaApplicationDelegate, which didn't work.

But doesn't that delegate class derive from some NSApplicationWhateverDelegate? 
Which is probably a Protocol anyway, so bad luck - or can one add Categories 
to Protocols?

Which led me to

  
http://stackoverflow.com/questions/1521267/defining-categories-for-protocols-in-objective-c

and one answer talks about ExtObjC (an additional library, I guess). While in 
general you cannot extend Protocols with Categories (in vanilla ObjC), that 
library might help you...

Anyway, my general idea, as you have figured out, is to extend 
QCocoaApplicationDelegate's base class (or Protocol), which I guess is an 
NSWhatever class/protocol. Then simply link your application explicitly with 
-lcocoa (or the correct framework/if needed).

Maybe that gets you some ideas...

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

Re: [Interest] Objective C Category for QCocoaApplicationDelegate undefined symbols

[Till Oliver Knoll]

Am 06.07.15 um 19:38 schrieb Till Oliver Knoll:
 
 Am 01.07.2015 um 10:54 schrieb Croitor Alexandru placi...@gmail.com:

 Hi.

 I'm trying to add an Objective C category to the QCocoaApplicationDelegate 
 class that is defined by the Mac OS X Cocoa platform plugin, to add / 
 override some methods. 
 
 I am not an Obj-C expert, but I'd say you need to link at Build time with the 
 class you're trying to add a Category to. 

Oh one more thing ;) *Overriding* existing methods with Categories is
strongly discouraged, also (apparently) by the Apple docs!

Also refer to this question:


http://stackoverflow.com/questions/5272451/overriding-methods-using-categories-in-objective-c

(The link to the Apple Developer docs is broken however)

Cheers, Oliver

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

Re: [Interest] Extremely sluggish browser performance in Qt 5.5

[Till Oliver Knoll]

 Am 23.06.2015 um 03:14 schrieb John C. Turnbull ozem...@ozemail.com.au:
 
 It seems that the problem exists in 5.4.2 as well so it's definitely not a
 regression.

Sorry, just a shot into the blue here. Maybe the problem has to do with how Qt 
interacts with the underlying network stack? IPv6 setup, maybe?

And does the problem also occur on other (Window) machines? A firewall maybe 
which gets overly busy with that unknown browser?

What about other Qt networking (example) apps? Wasn't there once a simple FTP 
example (I guess that's gone though, since QFtp doesn't exist anymore in Qt 5 - 
or does it?)?

Or that QML Flickr Image Viewer that I have in mind? Do those Qt network 
applications exhibit the same extreme slowness (which would hint at a problem 
somewhere in QAbstractSocket and friends maybe)?

Are you in a corporate network? What if you run the application in another 
network (preferably on the /same/ computer)? Are you sure the other browsers 
don't use a (default system) proxy which would bring the network packets on 
the fast lane?


My best bet is a problem with IPv6, the rest above sorted in increasing 
esotheric order...

Cheers,
  Oliver


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

Re: [Interest] Cross-platform font normalization best practice

[Till Oliver Knoll]

 Am 12.05.2015 um 18:00 schrieb Bob Hood bho...@comcast.net:
 
 I see that on Windows, Designer defaults to the MS Shell Dialog 2 8-point 
 font, and on OS X (Yosemite) it is .Helvetical Neue DeskInterface 13-point 
 (in one field, while another oddly reports an Al Bayan typeface).  I have 
 found that changing the OS X interface to use Lucida Grande 11-point 
 instead 
 of .Helvetical Neue DeskInterface 13-point makes it very close to the 
 Windows font appearance.

Now if I understand your need correctly you want the same font be used across 
all platforms, to have the same appearance (even if that brakes with font 
conventions on a specific platform), is that correct?

So another option could be to ship a well-behaving font (*) with your app and 
set it up using http://doc.qt.io/qt-5/qfontdatabase.html (a quick google 
research gave me the impression that Qt also checks in QTDIR/lib/fonts, at 
least the embedded Qt version - that path can probably be set relative to your 
application path, too).

Cheers,
  Oliver

(*) All relevant name fields are in english and the font lookup is known to 
work on all relevant platforms; check with your local lawyer for font 
distribution rights!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] cross-language matching of QStrings: partial success only?

[Till Oliver Knoll]

 Am 12.05.2015 um 00:07 schrieb René J.V. Bertin rjvber...@gmail.com:
 
 On Monday May 11 2015 23:00:36 Till Oliver Knoll wrote:
 
 Hi,
 
 Didn't see your message before sending my previous reply.
 
 Each name record is associated with an Encoding ID and Language ID. It would 
 be no fun if those IDs would be interpreted the same across platforms 
 (that's why we have cross-platform toolkits such as Qt to deal with that 
 mess ;)):
 
 I don't think Qt is dealing directly with TTF or OTF files, but rather uses 
 whatever the OS gives it. Did I miss something?

Most likely no. My point was merely to re-iterate and illustrate what a royal 
pain it can be even at the font level.

And we even haven't yet talked about X11 font formats ;) (altough there it 
might actually be /simpler/).

 
 ...
 
 But IF you have that, you could do a heuristic matching by:
 
 - always compare english values
 - if not, translate into english values first by
 - having a predefined set of supported languages for typical font names 
 and styles: bold, fett, gras etc
 
 That exists (translate(QFontDatabase,Bold)) but only for a limited subset 
 of font styles and weights.

Yes, something line that.

I have never heard about Universally Unique Font Style Enums and in my memory 
font matching was always a fuzzy thing.

But the good news seems to be that you are working under the hood, so you 
have access to more powerful font APIs which might help.

The bad news is probably that you have to deal with those non-Qt APIs ;)

Good luck!
  Oliver___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] cross-language matching of QStrings: partial success only?

[Till Oliver Knoll]

 Am 12.05.2015 um 08:08 schrieb Till Oliver Knoll 
 till.oliver.kn...@gmail.com:
 
 
 
 Am 12.05.2015 um 00:07 schrieb René J.V. Bertin rjvber...@gmail.com:
 
 On Monday May 11 2015 23:00:36 Till Oliver Knoll wrote:
 
 Hi,
 
 Didn't see your message before sending my previous reply.
 
 Each name record is associated with an Encoding ID and Language ID. It 
 would be no fun if those IDs would be interpreted the same across platforms 
 (that's why we have cross-platform toolkits such as Qt to deal with that 
 mess ;)):
 
 I don't think Qt is dealing directly with TTF or OTF files, but rather uses 
 whatever the OS gives it. Did I miss something?
 
 Most likely no. My point was merely to re-iterate and illustrate what a royal 
 pain it can be even at the font level.
 
 And we even haven't yet talked about X11 font formats ;) (altough there it 
 might actually be /simpler/).
 
 
 ...
 
 But IF you have that, you could do a heuristic matching by:
 
 - always compare english values
 - if not, translate into english values first by
 - having a predefined set of supported languages for typical font names 
 and styles: bold, fett, gras etc
 
 That exists (translate(QFontDatabase,Bold)) but only for a limited 
 subset of font styles and weights.
 
 Yes, something line that.
 
 I have never heard about Universally Unique Font Style Enums and in my 
 memory font matching was always a fuzzy thing.

Hey, just while googling for win32 english font name I stumbled over:

  http://trigeminal.fmsinc.com/samples/font_choices.html

It doesn't tell us much what we don't know already, but illustrates again that 
As anyone who understands localization will realize, this is very bad since it 
means that the functionality is changing when the language does. The font 
should be made to either accept only one name worldwide, or all names 
worldwide not to accept a different name depending on the machine's locale.

In effect, the (short) article provides a translation table English - Chinese 
(?) font names ;)

For what it's worth...


But it shows that we are on the right track... :/

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

Re: [Interest] Qt 5.4.x QML Quick2 OSX STANDARD framework deployments

[Till Oliver Knoll]

 Am 10.05.2015 um 21:30 schrieb rpzrpz...@gmail.com rpzrpz...@gmail.com:
 
 Oliver:
 
 I took your advice to heart.
 
 I think there is a happy middle ground using scripts.
 
 During in-house development, I can send everyone a given app with a 
 fully self contained bundle.  Ultimately, this will satisfy store 
 requirements.
 
 But for in-house development, 2 script files can run macdeployqt, 
 extract and compress the binary inside the testapp.app file, and place 
 the smaller file onto the DropBox distribution directory for over the 
 internet distribution.

In-House vs Dropbox vs Internet distribution? Smaller file = your 
application? 

 On the user side, they can run a script to import the compressed binary 
 into the proper testapp.app file on their local machine.

Users = they = Testers? In-house testing? Why internet distribution and the 
need for macdeployqt?

I must confess you left me confused here ;)
 
 This will avoid the repeated download of the massive QT5 libraries and 
 frameworks everytime we ship a new version of the application.
 
 And it will not break the protocol of using self contained bundles for 
 applications.

But one thing's for sure: if you mean it as in running scripts in order to 
fetch some dependencies (Qt framework) then this very well violates the Mac 
App Store rules. There is no way you can have a Mac App Store running a script 
to fetch Qt frameworks from some shared Dropbox folder or from the Internet.

And the same goes for updates: each update must be fully self-contained, means: 
with all necessary (Qt) frameworks (it is well possible that the Mac App Store 
uses a diff update mechanism, not sure).


For everything else you can do what you want, but I still fail why you'd want 
to have scripts for in-house testing: I mean, in-house = fast intranet - 
right? ;)

But if you really mean Joe iAverage Mac user to take part in some test 
campaign: don't expect them to know how to even open the Terminal application, 
let alone executing scripts ;)

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

Re: [Interest] Qt 5.4.2 snapshot ios camera capture issue

[Till Oliver Knoll]

 Am 11.05.2015 um 17:49 schrieb Lopes Yoann yoann.lo...@theqtcompany.com:
 
 
 On 11 May 2015, at 17:12, Jason H jh...@gmx.com wrote:
 
 This breaks our app and back-end processing for mobile. How do we fix this?
 You could read the image orientation from the EXIF header in your app and 
 apply the rotation to the QML Image element.

Talking about which: is there an EXIF API planned/available (at least for 
reading of JPEG EXIF data) in Qt? ;)

I know there is Exiv2 (http://www.exiv2.org) and friends, and apparently there 
was once a QExifImageHeader 
(http://stackoverflow.com/questions/15128656/read-exif-metadata-of-images-in-qt 
/ http://doc.qt.digia.com/qtextended4.4/qexifimageheader.html), but the later 
link/project seems to be abandoned.

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

Re: [Interest] cross-language matching of QStrings: partial success only?

[Till Oliver Knoll]

 Am 11.05.2015 um 20:37 schrieb Allan Sandfeld Jensen k...@carewolf.com:
 
 On Monday 11 May 2015, Thiago Macieira wrote:
 On Monday 11 May 2015 19:07:31 René J.V. Bertin wrote:
 So apparently the string comparison does not do translation (which isn't
 really a surprise except when you look at the context in which I'm
 working here...).
 
 How would the context change anything? String comparisons do a
 character-by- character comparison. If any character is different, the
 string won't match. They have nothing to do with translations.
 
 It seems the best option would be to ensure that cstyle and istyle are
 both in the same language. For that, I think I'd need to know the
 language in which the elements of styles are stored, and then
 translate style (cstyle) into that language.
 
 How does one do that?
 
 I have neither understood your objective nor your solution. I read your
 email three times and I can't get either.
 
 But my suggestion is that you restrict yourself to exact string matches.
 Don't do partials. Either you have the complete translation to be matched
 or you don't.
 
 Better yet, don't compare translations. Compare originals only.
 
 I think the problem is that fonts not always named in English and often uses 
 strings instead of defined enums. This means they can have their style names 
 in the language of the font origin or the language of the operating system. 

It's been a long time since I last fiddled around with parsing TTF file 
headers.

From what I see now in the OTF spec:

  https://www.microsoft.com/typography/otspec/name.htm

you have name records which can contain all sort of information: font family, 
sub-family, copyright, ...

Each name record is associated with an Encoding ID and Language ID. It would be 
no fun if those IDs would be interpreted the same across platforms (that's why 
we have cross-platform toolkits such as Qt to deal with that mess ;)): that's 
where the Platform ID comes into play (1 = Macintosh, 3 = Windows etc.). Off 
course there are also platform-independent Language Tag records for Language ID 
values = 0x8000, where Language tags are like en, fr-CA.

It goes without saying that Language Tags may or may not be supported on a 
given platform. The same goes for platform specific Language IDs: so a 
Windows platform may or may not understand the Macintosh Language IDs and vice 
versa.

I mean, where would the fun be!

The Name ID finally denotes the meaning of the name (in the language and 
encoding that you may have figured out by now): 0 = Copyright, 1 = Font Family, 
2 = Font Subfamily etc.

It is my understanding that it is up to the font manufacturer which Names to 
provide in which language (To keep this table short, the font manufacturer may 
wish to make a limited set of entries in some small set of languages; later, 
the font can be “localized” and the strings translated or added.).

So if you are lucky you always have the english names available (it faintly 
rings a bell that I once saw an englishFontFamily function in the win32 API) 
- if not, well, you might have to deal with French Fonts ;)

But it really seems to be in the spirit of the inventor that you lookup a 
specific font by a combination of Platform/Encoding/Language/Name IDs: Clients 
that need a particular string can look it up by its platform ID, character 
encoding ID, language ID and name ID. Note that some platforms may require 
single byte character strings, while others may require double byte strings.

All said, I don't even know how Qt deals with that: e.g. does QFontInfo::family 
return the english name, if available? Or the localised name depending on the 
system language? Or first found, first returned (aka undefined behaviour)?

I don't think you could solve a font matching problem on the Qt API layer - 
not without knowing the language ID of the returned font family name.

But IF you have that, you could do a heuristic matching by:

- always compare english values
- if not, translate into english values first by
- having a predefined set of supported languages for typical font names and 
styles: bold, fett, gras etc
- Have fun!

;)

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

[Interest] [OT] Re: Qt Desktop on Windows 10 TP

[Till Oliver Knoll]

 Am 10.05.2015 um 11:25 schrieb Thiago Macieira thiago.macie...@intel.com:
 
 On Sunday 10 May 2015 18:15:08 Thiago Macieira wrote:
 https://bugreports.qt.io/browse/QTBUG-43413
 
 The bug was introduced in 4.8.6 and fixed for 4.8.5, similarly for 5.3.0 and
 fixed in 5.4.1.
 
 I meant fixed for 4.8.7

And for a second I thought Qt had invented Time Warping (aka Time 
Travelling)!

So in analogy to QFuture: QPast, with const and non-const member functions.

;)

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

Re: [Interest] Qt 5.4.x QML Quick2 OSX STANDARD framework deployments documentation missing

[Till Oliver Knoll]

 Am 09.05.2015 um 03:01 schrieb mark diener rpzrpz...@gmail.com:
 
 Found a reference to the issue to install into /Library/Qt directory and 
 install-name-tool :

Just be aware that this is /very/ unusual for OS X apps to do: the expected way 
is really that each app bundle is self-contained and links against system 
provided frameworks (Cocoa and friends). Even if that means that each 
application brings along its own Qt libs...

Needless to say that the former approach needs an installer (which is 
discouraged very much by Apple) and you run into issues when users want to get 
rid of one of your applications: Who is the last to remove the shared Qt 
libraries?

And what happens if a user installs an older app, possibly overwriting a newer 
shared Qt library? Your installer needs to do a version check etc. to solve 
this.

And it goes without saying that your applications will never make it into the 
Mac App Store that way - if that's what you want.


On the other hand if we're talking about some in-house tools which are 
deployed in a controlled manner then this is a fine approach :)

Just some thoughts...

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

Re: [Interest] Qt5: QProxyStyle destructor is not virtual

[Till Oliver Knoll]

 Am 09.05.2015 um 06:29 schrieb Thiago Macieira thiago.macie...@intel.com:
 
 On Saturday 09 May 2015 12:26:28 Kevin Connor Arpe wrote:
 Hello,
 
 I am new to this mailing list, but I have used Qt (off and on) for many
 years.  Also, I am an OK C++ programmer, but great.  (I'm getting a bit out
 of date since the C++11 Big Bang.)
 
 Apologies if this is a dumb question, but I noticed that the destructor for
 Qt5/QProxyStyle is not virtual.
 
 It is virtual.
 
 The QStyle destructor is virtual.

What is implied here is that in C++ every d'tor of a derived class becomes 
virtual once the d'tor of a superclass has been declared virtual (*).

The same is true for methods in the general sense.

Personally I prefer to put an explicit virtual in front of every d'tor/method, 
also in derived classes. Simply to re-iterate the fact that they are virtual. 
But syntactically that's not required in C++.

The only drawback of my solution that I can think of: if one decided to make 
the d'tor/methods non-virtual again - and I can't think of a scenario where you 
would want to do that, once you have designed your classes to be 
derivable/overwritable - then one would have to remove all virtual 
declarations, and not just one (in the base class).

Oh and talking about C++11 features: I find the override keyword super-sexy 
:) Makes again your intent explicit, and the compiler can even check for 
(unintended) overwrites:

  http://en.cppreference.com/w/cpp/language/override

Cheers,
  Oliver

(*) I am not sure whether it is actually semantically correct (or whether it 
compiles at all) to only declare the d'tor of some derived class as virtual, 
but not in its parent class. E.g. if one wanted to say only from this 
specialised class onwards shall all derived classes have virtual methods 
(again, I fail to see a specific use case for that, but that doesn't mean such 
a use-case would not exist).

I have always declared the d'tor of the root class virtual if I knew that this 
class was going to be subclassed (or just in case).
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Question to members of the Qt team: why does an empty project consumes so much memory on iOS?

[Till Oliver Knoll]

 Am 21.04.2015 um 19:20 schrieb Till Oliver Knoll 
 till.oliver.kn...@gmail.com:
 
 
 Am 21.04.2015 um 18:06 schrieb Nuno Santos nunosan...@imaginando.pt:
 
 Harri,
 
 ...
 
 With a real device I have also found the REAL problem that was causing the 
 crashes. It was not memory!!
 
 Do you mind sharing what it was then?

Never mind, I saw that you already answered in Unknown crashes with Qt, iOS 
and iPad Air.

:)

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

Re: [Interest] Question to members of the Qt team: why does an empty project consumes so much memory on iOS?

[Till Oliver Knoll]

 Am 21.04.2015 um 18:06 schrieb Nuno Santos nunosan...@imaginando.pt:
 
 Harri,
 
 ...
 
 With a real device I have also found the REAL problem that was causing the 
 crashes. It was not memory!!

Do you mind sharing what it was then?

;)

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

Re: [Interest] Problem with QPixmap.

[Till Oliver Knoll]

 Am 19.04.2015 um 06:54 schrieb Igor Mironchik igor.mironc...@gmail.com:
 
 Hi,
 
 On Sun, 19 Apr 2015 00:04:08 +0300, Thiago Macieira  
 thiago.macie...@intel.com wrote:
 
 On Friday 17 April 2015 19:53:01 Igor Mironchik wrote:
 I have one problem: pixmap usb-disconnected.png doesn't draws  
 correctly.
 Draws absolutely nothing. And if click on this button application  
 crashes.
 What is the problem? Thank you.
 
 Hi Igor
 
 You're not a newbie. You know better than to say it crashes and not  
 provide
 a backtrace of the crash...
 
 Thank you, Thiago... You pointed me to the right direction. I found the  
 problem.

Mind sharing your solution (even if it was something stupid or trivial)? Others 
might stumble over the same (beginner's) mistake and profit from your tip!

But stiring up dust on a mailing list like it crashes! doesn't work, even 
providing example code for others to study (which costs them time!) and then go 
like thanks all, I have found the problem (but I won't tell you)! is a bit 
one-sided.

Glad you solved it though.

Cheers,
  Oliver

P.S. I rarely open attachments, unless curiosity about the problem really 
overtakes me. So IMHO it's better to extract /relevant/ code (snippets) and 
show it in the email.

In general it is also polite to disect (digest) the code yourself first a 
little bit and say Here I do this and There I expect the code to behave like 
that etc., when you expect others to spend time and study your code.

You can then still attach a /minimal/ example which is fully compileable 
(qmake; make), for those who caught interest. Besides, attachments are /not/ 
archived (usually) in mailing list archives! (Another good reason to show code 
snippets directly in the email - helps others in the future, keeps the Internet 
a happy place ;)).
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Unable to build Qt 5.4.1 on Ubuntu 14.04 x64 desktop.

[Till Oliver Knoll]

 Am 15.04.2015 um 10:50 schrieb Kim Min-chul nusev...@gmail.com:
 
 ...
 The following packages have unmet dependencies:
  libopenvg1-mesa-dev : Depends: libopenvg1-mesa (= 10.1.3-0ubuntu0.4)

You need to resolve those dependencies first. In this example by installing 
libopenvg1-mesa (on which the dev package depends).

Use your package manager and/or contact the Ubuntu community, since this is a 
Linux distribution/packaging topic.

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

Re: [Interest] Dynamically change dock icon under OS X

[Till Oliver Knoll]

 Am 15.04.2015 um 21:19 schrieb Samuel Gaist samuel.ga...@edeltech.ch:
 ...
 
 As for the dock icon, no need to go too deep in Qt Creator, you can take a 
 look at http://doc.qt.io/qt-5/qtmac.html#setBadgeLabelText

So my guess was right: in the Qt MacExtras module :) That setBatchLabelText 
(-Number) function must be a recent addition, it wasn't there in Qt 5.2.

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

Re: [Interest] iOS app store rejection - microphone consent?

[Till Oliver Knoll]

 Am 15.04.2015 um 20:54 schrieb Jason H jh...@gmx.com:
 
 
 So, because you write “I do record video”, I’m supposing that the 
 microphone request is made by the class you are using for recording video 
 that at some point ask to access to the microphone.
 
 Yes, I thought I might have left it in there by accident, but it got 
 commented out, then removed before submission.

The plot thickens: so are you saying you removed the entire video recording 
(without sound) recording functionality before submission?

So why are you still linking against the QMultimedia module (which needs to be 
explicitly added for linking with QT += multimedia - or so I understand)? Are 
you /displaying/ videos (I guess)?

And you are sure that the code that you removed was the only possible recording 
source (at least that you are aware of)?

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

Re: [Interest] QAudioDecoder class on Macintosh?

[Till Oliver Knoll]

 Am 08.04.2015 um 19:08 schrieb John Weeks j...@wavemetrics.com:
 
 I have a use for QAudioDecoder to load sound files into our numerical 
 analysis program as data. I found Qt Multimedia and the QAudioDecoder. I 
 wrote some trial code and got this message in my Creator console:
 
 defaultServiceProvider::requestService(): no service found for - 
 org.qt-project.qt.audiodecode

Ha! That reminds me of my own failed attempt to load a 16bit PCM *.wav file:

  http://lists.qt-project.org/pipermail/interest/2013-March/006438.html

That was in 2013, pretty much 2 years ago.

So if things haven't improved on OS X then I wouldn't hold my breath :/

I ended up writing my own RIFF file (*.wav) loader (which is quite simple if 
you control the wave files, e.g. stick to 8/16bit mono/stereo PCM data - you'll 
find plenty of example code out there. IIRC even in the Qt sources of the good 
ol' QAudio (?) class there is a simple, non-public loadWAV function).

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

Re: [Interest] QOpenGLWidget and text

[Till Oliver Knoll]

 Am 06.04.2015 um 17:15 schrieb Matthew Woehlke 
 mw_tr...@users.sourceforge.net:
 
 On 2015-04-04 05:57, Till Oliver Knoll wrote:
 Am 03.04.2015 um 17:26 schrieb Matthew Woehlke:
 On 2015-04-02 13:45, Till Oliver Knoll wrote:
 . But what's next? A drawButton? drawBitmap? In a Widget?!
 
 Yes. And why not?
 
 Because the class name sais *Widget, and not *Painter or *WhateverItem.
 
 A Widget's responsibility - much like the one of a View; we'll come to that 
 in a second... - is to provide a /surface/ to draw onto, and to manage the 
 underlying system resources (we'll deliberately skip over other 
 functionality, such as layout management).
 
 Please don't be overly pedantic. The point isn't whether the ability is
 particularly a member of QOpenGLWidget, but whether it is available *at
 all* (in a non-deprecated class, anyway) without the user having to
 concoct a complicated system for providing it.

Sorry, my bad then. I thought the whole discussion was /exactly/ about bringing 
back renderText() to the new class QOpenGLWidget.

You: I am finding myself less than
convinced that the new class is an improvement... implicit context
sharing is nice, but the loss of convenience methods is really, really
painful.

So I concluded that you must have been talking about QOpenGLWidget (alone).

Off course I never argued against the usefulness of said renderText (and /yes/, 
I missed the overload which takes world coordinates ;)).

I was merely defending the position that QOpenGLWidget is not the place for it, 
and that it was hence a good decision to drop it there.

As for the question where to place it: anywhere but *Widget!

Heck, it'd consider any drawWhatever functionality high-level, read: does 
not belong into Qt core OpenGL functionality, but rather another module: 
something between QtGui and Qt3d (or in the later itself).

The Qt core OpenGL functionality should just provide a surface to draw raw 
OpenGL into, a GL context and some convenience methods to convert Qt data 
structures (e.g. QImage) into GL compatible buffer data. QMatrix and friends 
is nice, too.

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

Re: [Interest] Qt5: How to detect difference between window closing and application quitting.

[Till Oliver Knoll]

 Am 04.04.2015 um 22:12 schrieb Michael Jackson imikejack...@gmail.com:
 
 I have a QMainWindow derived application on OS X (10.8.5 if is matters). This 
 app was ported from Qt4 to Qt5 and now I seem to have an issue with my 
 closeEven(..) being called twice. I have implemented the 
 closeEvent(QCloseEvent* event) to capture when the window is closing so that 
 I can call some clean up routines (Writing of settings files mainly). 

Would the signal

  http://doc.qt.io/qt-5/qguiapplication.html#lastWindowClosed

help instead of overwriting ::closeEvent?

You only get it if the /last/ main (top-level) window is (about to get) closed, 
but usually that is sufficient to write application settings (unless you want 
to also store window geometry, that is, /per window/).

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

Re: [Interest] Qt5: How to detect difference between window closing and application quitting.

[Till Oliver Knoll]

 Am 04.04.2015 um 22:12 schrieb Michael Jackson imikejack...@gmail.com:
 
 I have a QMainWindow derived application on OS X (10.8.5 if is matters). This 
 app was ported from Qt4 to Qt5 and now I seem to have an issue with my 
 closeEven(..) being called twice. I have implemented the 
 closeEvent(QCloseEvent* event) to capture when the window is closing so that 
 I can call some clean up routines (Writing of settings files mainly). 

Would the signal

 http://doc.qt.io/qt-5/qguiapplication.html#lastWindowClosed

help instead of overwriting ::closeEvent?

You only get it if the /last/ main (top-level) window is (about to get) closed, 
but usually that is sufficient to write application settings (unless you want 
to also store window geometry, that is, /per window/).

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