Re: [Interest] Qt 6 is much more faster to compile from source

[Konstantin Tokarev]

07.09.2021, 20:53, "Thiago Macieira" :
> On Tuesday, 7 September 2021 02:52:49 PDT Tor Arne Vestbø wrote:
>>  Good to hear!
>>
>>  Part of it comes from CMake generating ninja files instead of Makefiles.
>
> Our qmake-generated Makefiles weren't that slow. Nothing compared to Automake,
> at least.
>
> Qt 5 qtbase/src build:
> Build succeeded, took 3:01.027s (total run time 3:01.027s), 2388.2% CPU usage
>
> Qt 6 equivalent with Ninja:
> Build succeeded, took 222.01s (2385% CPU usage)
>
> 3:01.027 = 181.027s (sorry, different wrapper, so they print time differently)
>
> Same compiler, same otherwise-idle machine, icecc disabled. The configuration
> on both builds is meant to be the same, full build.

If generated makefiles were non-recursive, it would be even faster.

Ninja rocks for incremental build times and has some convenience features for
generators, but it's not a magic pill.


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

Re: [Interest] Installation Sizes for Applications using Qt

[Konstantin Tokarev]

28.08.2021, 04:06, "Ben Cottrell" :
> Yes, I've tried configure with these command line arguments:
>    ./configure -opensource -confirm-license -platform linux-g++ -prefix
>    /opt/6.1.2-linux-g++-static -static
>
> I got lots of errors after running configure, about missing XCB
> libraries, so following the Ubuntu CI script, I installed them with:
>    apt install "^libxcb.*"
>
> I installed this on Debian 11.
>
> I managed to build a test project with cmake containing this code:
>    cmake_minimum_required(VERSION 3.20)
>    project(untitled)
>
>    set(CMAKE_CXX_STANDARD 17)
>    set(CMAKE_AUTOMOC ON)
>    set(CMAKE_AUTORCC ON)
>    set(CMAKE_AUTOUIC ON)
>    set(CMAKE_LINKER ld.gold)
>
>    set(CMAKE_PREFIX_PATH "/opt/6.1.2-linux-g++-static/lib/cmake")
>
>    find_package(Qt6 COMPONENTS
>    Core
>    Gui
>    Widgets
>    REQUIRED)
>
>    add_executable(untitled main.cpp)
>    target_link_libraries(untitled
>    Qt::Core
>    Qt::Gui
>    Qt::Widgets
>    )
>
> Here's the source to main.cpp:
>    #include 
>    #include 
>
>    int main(int argc, char *argv[]) {
>    QApplication a(argc, argv);
>    QPushButton button("Hello world!", nullptr);
>    button.resize(200, 100);
>    button.show();
>    return QApplication::exec();
>    }
>
> Afterwards, I used strip on untitled, reducing the size to 16MB. If I
> give it to people, I'll provide the object file if they want to relink
> it.

If you do this for commercial or closed-source product, make sure you follow 
exact wording of the license.
IIRC you are required to make written offer to provide linking materials on 
request, but  as I said, check it
with the license text carefully.

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

Re: [Interest] Qt 6 Ubuntu package

[Konstantin Tokarev]

05.02.2021, 12:32, "Lorn Potter" :
> On 31/1/21 12:09 AM, Roland Hughes wrote:
>>  If history repeats itself, and in the software industry it most
>>  definitely does, requiring a login to obtain the OpenSource code
>>  effectively ended OpenSource Qt.
>
> really?
> I guess maybe 'git clone http://code.qt.io/qt/qt5.git'
> is a bit too much to ask for open source developers to type.

Or https://download.qt.io/archive/qt/.


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

Re: [Interest] QtPdf from Qt open source online installer

[Konstantin Tokarev]

20.10.2020, 18:12, "Benjamin TERRIER" :
> On Mon, 19 Oct 2020 at 20:54, Jason H  wrote:
>> There's some license shenanegans going on.
>> https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf
>> However there was a later update:
>> https://lists.qt-project.org/pipermail/development/2020-January/038457.html
>>
>> So I don't know why it was not included.
>> It seems that some people (myself included) objected to commericalizing a 
>> module that was based on a open source engine to start with.
>
> Yes, I've seen the discussions about the license, but I thought it was solved.
>
> Given that The Qt Company is selling the QtPdf module under a commercial 
> license on the marketplace I was thinking that
> they remove the QtPdf artefacts from the QtWebEngine packages. That would 
> make sense for commercial users.
>
> However, for open source users it looks like a bug in the installer.

Isn't this done intentionally to promote commercial licenses among open source 
users?


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

Re: [Interest] rebooted QtWebKit for Qt4??

[Konstantin Tokarev]

11.07.2020, 13:26, "Roland Hughes" :
> On 7/10/20 11:24 AM, Konstantin Tokarev wrote:
>>  10.07.2020, 15:00, "Roland Hughes" :
>>>  They have a "slightly" newer version of WebKit.
>>>
>>>  "CsWebKit is a web content rendering engine based on the open source
>>>  WebKit project, featuring broad support for standard web technologies.
>>>  CsWebKit is developed as a part of the WebKit community, which enables
>>>  every new release of CsWebKit to include the latest developments from
>>>  the WebKit project."
>>  Blatant lies. They use the same WebKit snapshot as Qt 4.8, and never took
>>  part in WebKit community.
>
> Perhaps. Perhaps not. Since it is an OpenSource project it could well
> have been someone who actually did take part in the WebKit community who
> just did it for them because they were tired of the Willy-Nilly changes
> to the Qt API and its relentless pursuit of worthless QML.

In this case they had to be really stealthy to avoid any mentioning of the 
project
in patches and discussions, and, of course, avoid contributing any code related
to that project which could reveal their affiliation.

-- 
Regards,
Konstantin

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

Re: [Interest] rebooted QtWebKit for Qt4??

[Konstantin Tokarev]

10.07.2020, 15:00, "Roland Hughes" :
> They have a "slightly" newer version of WebKit.
>
> "CsWebKit is a web content rendering engine based on the open source
> WebKit project, featuring broad support for standard web technologies.
> CsWebKit is developed as a part of the WebKit community, which enables
> every new release of CsWebKit to include the latest developments from
> the WebKit project."

Blatant lies. They use the same WebKit snapshot as Qt 4.8, and never took
part in WebKit community.

-- 
Regards,
Konstantin

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

Re: [Interest] rebooted QtWebKit for Qt4??

[Konstantin Tokarev]

09.07.2020, 20:29, "René J.V. Bertin" :
> On Thursday July 09 2020 15:49:52 Konstantin Tokarev wrote:
>
>>>  I don't see the problem here, as long as we're talking about actual 
>>> individual processes?
>>
>> Individual process which are in fact just different entry points of the same 
>> shared library. Building same files twice for Qt4 and Qt5 in the same build 
>> system will likely turn into maintenance nightmare, not to mention 
>> maintaining ifdefed code paths so that code could actually compile and work 
>> in both cases.
>
> Oh, that. Yeah, maintaining such a glue library as part of Qt[5]WebKit would 
> be problematic, esp. if you want to be able to build it as part of an 
> all-inclusive build. I wasn't thinking along those lines but rather of a 
> separate project, something that would build against an installed QtWebKit or 
> that reimplements just enough of the necessary APIs.

If such glue library is not a part of QtWebKit, it would have to deal with 
having Qt4 and Qt5 in the same process. That would be no easier than wrapping 
any other unmodified Qt5 module for use in Qt4 application.

> I got the impression that the QWebView interface wasn't too extensive, 
> literally a window on a very complex system behind the scenes with only a 
> relatively small set of controls (many of which might not be necessary if you 
> aren't writing a full-fledged browser). I haven't yet figured out how this 
> would be different for the multi-process version (in fact, I haven't yet 
> figured out at all how you obtain it, not from looking through the Otter 
> Browser code in any case).

Otter Browser doesn't use multiprocess mode, as it operates via QWebView API. 
Changing it to use multiprocess API requires writing a lot of new code (and 
also improvements on QtWebKit side to provide feature parity)

>
> R

-- 
Regards,
Konstantin

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

Re: [Interest] rebooted QtWebKit for Qt4??

[Konstantin Tokarev]

09.07.2020, 15:11, "René J.V. Bertin" :
> On Thursday July 09 2020 14:21:53 Konstantin Tokarev wrote:
>
>> I don't know how complex is said application, but almost certainly it would 
>> be easier to port it to Qt5 instead (and more useful to community, as Qt4 
>> had reached EOL many years ago)
>
> I know, but you know what they say about things that ain't broke ;)
> One of the applications (rather, suite of...) is KDE PIM. I don't even want 
> to try the current version of it, partly because it only supports QtWebEngine 
> (if I wanted to read my mail using Chromium I could just as well use the real 
> full-fledged browser I already have running ;) ).
>
> I can also do that just with the email that doesn't render correctly ... or 
> view that on my phone.
>
>> 2) using Qt4 in UI process and Qt5 in render process is not feasible as they 
>> share a lot of code
>
> I don't see the problem here, as long as we're talking about actual 
> individual processes?

Individual process which are in fact just different entry points of the same 
shared library. Building same files twice for Qt4 and Qt5 in the same build 
system will likely turn into maintenance nightmare, not to mention maintaining 
ifdefed code paths so that code could actually compile and work in both cases.

>
> FWIW, any Qt4/KDE4 application that uses KWallet functionality will talk with 
> the Qt5-based KWallet daemon nowadays, through the KDE4 wallet client API.

Those are independent applications communicating over well-defined protocol, 
not a tightly-coupled system built from a single code base


-- 
Regards,
Konstantin

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

Re: [Interest] rebooted QtWebKit for Qt4??

[Konstantin Tokarev]

09.07.2020, 12:18, "René J.V. Bertin" :
> Hi,
>
> Call me stupid or whatever you like

That would probably be against CoC ;)

> but I am hanging on to a few Qt4 applications that never got a satisfactory 
> (to me) Qt5 successor, and which use QtWebKit to render HTML documents.
>
> It's happening more and more often that I come across such documents that 
> don't render properly in QtWebKit 4.8.7 so naturally I've begun to wonder how 
> (un)feasible it would be to port a more recent QtWebKit version back to Qt4 
> (minus the QML shebang, probably) and if any efforts in this direction have 
> been made in the community.

I don't know how complex is said application, but almost certainly it would be 
easier to port it to Qt5 instead (and more useful to community, as Qt4 had 
reached EOL many years ago)

>
> I have no idea how big the public QtWebKit API really is, but a more 
> interesting/exciting/cool solution might be to replace Qt4WebKit with 
> smallish glue library that somehow uses a Qt5-based render process. I notice 
> that the rebooted QtWebKit can work with an external render process, so I 
> presume that it should be possible technically to interface with that from 
> Qt4.

This solution is not viable because
1) multiprocess mode uses very different API which just cannot provide a 
drop-in replacement for QWebView and friends (it's not possible to reach 
QWebElement objects from UI process, many operations have to become 
asynchronous, and so on)
2) using Qt4 in UI process and Qt5 in render process is not feasible as they 
share a lot of code

>
> Dreaming on... :)
>
> R.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Customizing ui/rcc compiler in qmake

[Konstantin Tokarev]

21.04.2020, 21:52, "Patrick Stinson" :
> Sorry, I meant uic not rcc.
>
>>  On Apr 21, 2020, at 10:14 AM, Patrick Stinson  wrote:
>>
>>  Is there a way to customize the ui compiler to use a command other than rcc?
>>
>>  For example, I am trying to set up my pyqt5 project using only qmake and 
>> want it to use the command pyrcc5 instead of rcc, and with a few custom 
>> command line arguments.

You may want to try setting QMAKE_UIC and QMAKE_UIC_FLAGS qmake variables

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

31.03.2020, 22:57, "Bernhard Lindner" :
> Hi Tuukka!
>
>>  I have also tried to explain these, but your tone feels rather aggressive. 
>> I do not
>>  understand what makes you say: “Even a solo developer needs to hire a 
>> lawyer before
>>  touching anything Qt-related.”
>
> Because this is what users hear in MLs and forums, when they ask about Qt 
> licensing
> issues. The recurring answer is: "don't know, don't understand, hire a lawer".
>
> And because this is written in your FAQ: "It is always recommended to contact 
> a lawyer
> familiar with open source licenses for a full review of your project to 
> determine whether
> you can fulfill all of the obligations of applicable open source licenses".

Actually, situation with commercial license turns out to be even more 
complicated than
with open source. Open source licensing is at least well-understood by lawyers 
and
doesn't affect what each department or employee in the company is doing, only 
what
end products are shipped.

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

31.03.2020, 20:34, "Tuukka Turunen" :
> Hi Jérôme et al,
>
> This thread has long ago left the original question and become a discussion 
> about Qt licensing in general and especially about the point of not mixing 
> commercial Qt with open-source version of Qt.
>
> The key point is: The Qt Company, just like Trolltech initially and other 
> companies in between, does not want mixing open-source Qt and commercial Qt.
>
> Reason is simple: if mixing was allowed, many companies would use it to pay 
> less for their use of Qt.
>
> It is unfortunate that also real open-source projects may be affected in some 
> cases. Majority of users are not affected in any way.
>
> It is also unfortunate if licensing is felt to be so complex that it is 
> better to use some other technology. Commercial licensing of Qt is quite 
> flexible and it is also possible to negotiate and ask for advice in case it 
> is unclear what is allowed and what not.
>
> Here are some examples that hopefully clarify the point about mixing 
> open-source and commercial:
>
> Example 1: Company A has 10 developers creating a product. 5 of them use Qt 
> under commercial license and 5 do not use Qt at all. This is ok.
>
> Example 2: Company B has 10 developers creating a product. 5 of them use Qt 
> under open-source license and 5 do not use Qt at all. This is ok.
>
> Example 3: Company C has 10 developers creating a product. 5 of them use Qt 
> under commercial license and 5 use Qt under open-source license. This is not 
> allowed.
>
> Example 4: Large company D is creating a product with Qt under commercial 
> license. Part of the work is subcontracted to Company E that uses Qt under 
> commercial license. This is ok.
>
> Example 5: Large company F is creating a product with Qt under commercial 
> license. Part of the work is subcontracted to Company G that uses Qt under 
> commercial license. Company G subcontracts some of the work further to 
> low-cost Company H, who uses Qt under open-source license. This is not 
> allowed.
>
> Example 6: Company I is building two independent products with separate 
> development teams. One development team uses Qt under commercial license to 
> create product 1 and the other development team uses Qt under open-source 
> license to create product 2. This is ok.
>
> Hopefully I was able to clarify the topic with these examples. The Qt Company 
> wants to provide Qt under open-source license. There is no mega corporation 
> with deep pockets behind. Development of Qt is funded with the revenues 
> gained from commercial licensing.

Hi,

I think this is a kind of explanation which deserves to be in official FAQ.

You should also consider adding flowchart or interactive questionary which 
would show people if their use cases are ok or not after they answer a series 
of questions about their conditions. Otherwise some people might still end up 
with impression that licensing terms are unclear (or even intentionally vague).

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

31.03.2020, 11:54, "Ramakanth Kesireddy" :
> Since the old compiler doesn't supports c++11, we got to use Qt WebKit 5.6.3 
> only. However, we shall move to the latest 5.12 LTS once the compiler is 
> upgraded.
>
> So ICS 59.2 would be compatible with Qt WebKit 5.6.3?

No, necessary patch wasn't backported there. Try 58.x

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

31.03.2020, 05:32, "Ramakanth Kesireddy" :
> Thanks for your mail.
> Can you let me know any specific version of ICU that shall be compatible with 
> Qt WebKit 5.6.3?

If you use 5.9 branch (which you really have no reason not to use, AFAICS), 
it's 59.2


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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

30.03.2020, 19:28, "Thiago Macieira" :
> On Monday, 30 March 2020 12:35:19 -03 Ramakanth Kesireddy wrote:
>>  Any recommendation on the compatible icu sources to cross-compile or the
>>  latest one would do for Qt WebKit 5.6.3?
>
> ICU should always be used in the latest version since it contains data that
> changes every year, some of them multiple times a year, like the timezone
> database.
>
> That also means you need to design your system so it'll get updates.

QtWebKit 5.6.3 won't build with latest ICU. Only the latest release is 
compatible:
https://github.com/qtwebkit/qtwebkit/releases/tag/qtwebkit-5.212.0-alpha4

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

25.03.2020, 22:09, "Vyacheslav Lanovets" :
> Hi,
>
> Situation.
>
> A company has a few developers with Qt Commercial subscription who
> write applications in Qt for iOS.
> There are many other developers, who work on other projects and don't
> use Qt libraries.
> They talk to each other and sometimes even work on the same code.
>
> Is it still possible for the developers who don't use Qt libraries in
> any way, use Qt Creator IDE for editing and debugging?

IANAL, but if you don't redistribute Qt Creator or derivative or combined works
based on Qt Creator, you can use it under terms of GPL without any obligations
from your side. From official GPL FAQ:

https://www.gnu.org/licenses/gpl-faq.en.html#CanIUseGPLToolsForNF

Moreover, GPL even allows using modified versions of Qt Creator inside
your company without sharing these modifications, as long as you don't 
distribute
it outside in any form. From official GPL FAQ:

https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic

-- 
Regards,
Konstantin

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

Re: [Interest] Callgrind under Linux

[Konstantin Tokarev]

06.03.2020, 17:30, "Jérôme Godbout" :
> Hi,
>
> one of my colleague is trying to start valgrind callgrind to profile a part 
> of the application using Qt 5.12.7, latest Qt Creator with Ubuntu. the start 
> command look like this:
>
> valgrind --tool=callgrind --instr-atstart=no ./OpM-3_DU_SW
>
> it did the macro for the start/stop and dump. Added the valgrind lib. But 
> Valgrind seem to crash with the following error:

> vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF2 0xB9 0x1 0x0 0x0 0x0
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==13393== valgrind: Unrecognised instruction at address 0x84d5c40.
> ==13393==    at 0x84D5C40: qt_random_cpu(void*, long long) (immintrin.h:103)
> ==13393==    by 0x84D: 
> QRandomGenerator::SystemGenerator::generate(unsigned int*, unsigned int*) 
> (qrandom.cpp:369)

>but how does one know what exactly is wrong!? The proint call stack seem 
>legitimate to me.

Valgrind says that it cannot handle some instruction. Call stack points 
directly to place RDRAND intrinsics are used.

>We did find a closed issue about it: 
>https://bugreports.qt.io/browse/QTBUG-62118
> But no solution or hint about the cause of this.

You can configure Qt with explicitly disable RDRAND, or use same hack as used 
in tst_qrandomgenerator.cpp, passing SkipHWRNG flag to qt_randomdevice_control.


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

Re: [Interest] Converting CVImageBufferRef into QImage

[Konstantin Tokarev]

28.02.2020, 19:34, "Jason H" :
> Just how invalid are we talking?
> It's well-known that the blue/red channels may be swapped, and I've seen 
> padding on the row.
> Doing your math though you're only reporting 2 bytes per pixel, which is very 
> wrong. What is the image format you expect?

FWIW, QImage::Format_Grayscale16 uses exactly 2 bytes per pixel.

-- 
Regards,
Konstantin

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

21.02.2020, 15:02, "Ramakanth Kesireddy" :
> Where can I download the compatible Qt 5.6.3 Qt WebKit sources? Looks like 
> latest Qt WebKit needs gcc 4.9 and above.

http://download.qt.io/community_releases/5.6/5.6.3/

Though you should probably better use 5.9 branch, if you cannot use gcc 4.8 for 
some reason


-- 
Regards,
Konstantin

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

20.02.2020, 20:00, "Ramakanth Kesireddy" :
> Unable to get away the error though I added QtWebkit(5.5.1) sources along 
> with Qt 5.6.3 sources and use below configure line:
>
> ./configure -prefix /home/ubuntu/qt5 -opensource -confirm-license -qt-libjpeg 
> -qt-zlib -qt-libpng -sql-sqlite -no-cups -no-opengl -no-qml-debug -skip qt3d 
> -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtconnectivity 
> -skip qtdeclarative -skip qtenginio -skip qtgraphicaleffects -skip qtlocation 
> -skip qtmacextras -skip qtmultimedia -skip qtquickcontrols -skip 
> qtquickcontrols2 -skip qtscript -skip qtsensors -skip qtserialbus -skip 
> qtserialport -skip qtwayland -skip qtwebsockets -skip qtwinextras -skip 
> qtx11extras -skip qtxmlpatterns -nomake tools -nomake tests -nomake examples 
> -no-use-gold-linker -no-iconv -no-pulseaudio -no-alsa -no-mtdev -dbus 
> -fontconfig -no-libudev -no-openssl -qt-pcre -v
>
> I installed needed dependencies of Qt Webengine,QtWebkit and libxcb as 
> mentioned in https://wiki.qt.io/Building_Qt_5_from_Git
>
> The older versions of Qt had been installed in /home/ubuntu/ different 
> folders.
> Though I remove the older versions of installed Qt, it still throws the 
> qt_version_tag error.
>
> Do I need to modify any QtWebkit sources/configuration to link against the Qt 
> 5.6+?

You need to use release which is not older than Qt 5.6, 5.5 won't work.

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

20.02.2020, 19:36, "Ramakanth Kesireddy" :
> If I need to build the Qtwebkit source, Do I need to build as a separate 
> module using qmake or use configure line to configure QtWebkit and then 
> make?Looks like it needs gcc 4.9 to build QtWebkit.

Please use this instruction
https://github.com/qtwebkit/qtwebkit/wiki/Building-QtWebKit-on-Linux

It's also possible to build with gcc 4.8 if you disable some features, but not 
with older gcc.


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

Re: [Interest] [Development] How to get winid from qprocess id for QProcess

[Konstantin Tokarev]

20.02.2020, 18:38, "Sujan Dasmahapatra" :
> hi friend
>
> I am running an external app, which I want to fit onto my QScrollArea, for 
> this I am writing code like this.
>
> // launch weasis
> QProcess *process = new QProcess();
> process->start("./viewer-win32.exe");
> if (process->waitForFinished())
> {
> return;
> }
>
> QWindow *window = QWindow::fromWinId(211812356);
> window->setFlags(Qt::FramelessWindowHint);
> _patient_gui->scrollArea_1->setWidget(QWidget::createWindowContainer(window));
>
> But how can I get the wind id? it is hard coded here, is there any way to get 
> the id from process id.
>
> any help is highly appreciated.

Hello,

It seems like your question has nothing to do with development of Qt itself, so 
it would be more
appropriate to use "interest" mailing list.

As for your question, you can get id by using methods like QWindow::winId() or 
QWidget::effectiveWinId()
If subject window is not managed by Qt, you have to use native API.


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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

20.02.2020, 08:03, "Ramakanth Kesireddy" :
> Ok let me try with 5.212..Whether it is compatible with Qt sources starting 
> from 5.6 till the latest 5.12.7 and 5.14?

Yes it is.
You can also take ready to use binaries compatible with official Qt 5.13 from
http://download.qt.io/snapshots/ci/qtwebkit/5.212/1571922148/qtwebkit/

>
> On Wed, 19 Feb, 2020, 22:36 Konstantin Tokarev,  wrote:
>> 19.02.2020, 10:53, "Thiago Macieira" :
>>> On Tuesday, 18 February 2020 16:29:13 PST Sze Howe Koh wrote:
>>>>  On Wed, 19 Feb 2020 at 08:05, Thiago Macieira 
>>>
>>> wrote:
>>>>  > There's no good solution for using qtwebkit. You have to stop using it.
>>>>
>>>>  I was under the impression that Konstantin Tokarev was keeping the Qt
>>>>  WebKit sources up-to-date with upstream WebKit, even though it's not
>>>>  part of the official Qt releases?
>>>
>>> Such impression existed and Konstantin did update the release. There are
>>> certainly some commits in the repository. But looking at the activity for 
>>> the
>>> past year, almost everything seems to be related to keeping the buildsystem
>>> working. I can't find any commit referring to a fixing a security issue.
>>
>> That's correct, most of the work in last year is targeted to a new branch 
>> with updated
>> WebKit. However, 5.212 serves its job well, it's compatible with current Qt 
>> and is at
>> least is strictly better than 5.9 in terms of bugs, features and security. 
>> Of course, it
>> should be used with caution on untrusted content, because of possible 
>> security issues.
>>
>>>
>>> In the end, the 5.212 branch base itself is too old. qtwebkit would need a 
>>> new
>>> base branch off webkit to be a reasonable target and that has not happened.
>>>
>>> Please, let it die.
>>>
>>> --
>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>   Software Architect - Intel System Software Products
>>>
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> https://lists.qt-project.org/listinfo/interest
>>
>> --
>> Regards,
>> Konstantin
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

20.02.2020, 01:54, "Thiago Macieira" :
> On Wednesday, 19 February 2020 09:04:32 PST Konstantin Tokarev wrote:
>>  That's correct, most of the work in last year is targeted to a new branch
>>  with updated WebKit. However, 5.212 serves its job well, it's compatible
>>  with current Qt and is at least is strictly better than 5.9 in terms of
>>  bugs, features and security. Of course, it should be used with caution on
>>  untrusted content, because of possible security issues.
>
> Strictly better than 5.5, you mean.

No, than https://code.qt.io/cgit/qt/qtwebkit.git/log/?h=5.9
There is no valid use case for 5.5 tags now, as I pointed out in my other reply.

>
> Yes, it is. But that's like saying that an open backyard door in your house is
> better than an open front door. It is, but it's also unacceptably insecure.
>
> I guess that if you control the HTML & JS content, never downloading from the
> network, maybe that's acceptable, though.

If you consider Qt implementation of network stack secure enough [1], 
downloading 
content from server controlled by the same party via HTTPS with proper 
certificate
validation can be considered secure as well.

Another possible case is use in sufficiently isolated environment or device 
without
access to sensitive data.

[1] Including dependencies like OpenSSL

-- 
Regards,
Konstantin

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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

18.02.2020, 19:33, "Ramakanth Kesireddy" :
> Hi,
>
> While trying to build Qt Webkit sources from Qt 5.5.1 as a separate module 
> being part of Qt 5.12.7 sources, it throws below error:

Please do NOT use QtWebKit 5.5.1. It has unpatched Spectre/Meltdown
vulnerabilities, as well as a number of rendering bugs.

If 5.212 branch doesn't fit for some reason, you may want to use (as a last 
resort!)
the head of 5.9 branch, which includes aforementioned fixes.

>
> WebKit is now configured for building. Just run 'make'.
>
> g++ -Wl,-O1 -Wl,--enable-new-dtags 
> -Wl,-rpath,/home/ubuntu/qt-everywhere-opensource-src-5.12.7/qtwebkit/lib -o 
> LLIntOffsetsExtractor .obj/llint/LLIntOffsetsExtractor.o
> .obj/llint/LLIntOffsetsExtractor.o:(.qtversion[qt_version_tag]+0x0): 
> undefined reference to `qt_version_tag'
> collect2: ld returned 1 exit status
> make[3]: *** [LLIntOffsetsExtractor] Error 1
> make[3]: Leaving directory 
> /home/ubuntu/qt-everywhere-opensource-src-5.12.7/qtwebkit/Source/JavaScriptCore'
> make[2]: *** [sub-LLIntOffsetsExtractor-pro-make_first-ordered] Error 2
> make[2]: Leaving directory ` 
> /home/ubuntu/qt-everywhere-opensource-src-5.12.7/qtwebkit/Source/JavaScriptCore'
> make[1]: *** 
> [sub-Source-JavaScriptCore-JavaScriptCore-pro-make_first-ordered] Error 2
> make[1]: Leaving directory 
> /home/ubuntu/qt-everywhere-opensource-src-5.12.7/qtwebkit'
> make: *** [module-qtwebkit-make_first] Error 2
>
> I tried to add DEFINES += QT_NO_VERSION_TAGGING in WebKit.pro but it doesn't 
> solves the error.
>
> Any suggestions on how to resolve the same are appreciated.
>
> Thanks and Regards,
> Ramakanth
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] QtWebkit error while building Qt5.12.7 sources

[Konstantin Tokarev]

19.02.2020, 10:53, "Thiago Macieira" :
> On Tuesday, 18 February 2020 16:29:13 PST Sze Howe Koh wrote:
>>  On Wed, 19 Feb 2020 at 08:05, Thiago Macieira 
>
> wrote:
>>  > There's no good solution for using qtwebkit. You have to stop using it.
>>
>>  I was under the impression that Konstantin Tokarev was keeping the Qt
>>  WebKit sources up-to-date with upstream WebKit, even though it's not
>>  part of the official Qt releases?
>
> Such impression existed and Konstantin did update the release. There are
> certainly some commits in the repository. But looking at the activity for the
> past year, almost everything seems to be related to keeping the buildsystem
> working. I can't find any commit referring to a fixing a security issue.

That's correct, most of the work in last year is targeted to a new branch with 
updated
WebKit. However, 5.212 serves its job well, it's compatible with current Qt and 
is at
least is strictly better than 5.9 in terms of bugs, features and security. Of 
course, it
should be used with caution on untrusted content, because of possible security 
issues.

>
> In the end, the 5.212 branch base itself is too old. qtwebkit would need a new
> base branch off webkit to be a reasonable target and that has not happened.
>
> Please, let it die.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] QWebSocket text methods should be utf8?

[Konstantin Tokarev]

14.02.2020, 23:56, "Thiago Macieira" :
> On Friday, 14 February 2020 11:13:24 PST Jason H wrote:
>>  After reviewing the QWebSocket spec ( https://tools.ietf.org/html/rfc6455 )
>>  text frames are supposed to be UTF-8 encoded, which would mean that
>>  QByteArray would be the proper class.
>
> No, QString is the proper class because it's *text*. QWebSocket will convert
> from UTF-8 to UTF-16 and back for you.

FWIW, having to do useless transcoding just to use an API doesn't fit into my
definition of "proper".

>
>>  Now I'm having to toUtf8() all the things I receive, and QString() the ones
>>  I send. I am sure this leads to some degree of madness. I'm wondering if it
>>  would be possible to provide proper overloads:
>>  - sendTextMessage(const QByteArray &message)
>>  - textMessageReceived(const QByteArray &message)
>>  - textFrameReceived(const QByteArray &frame, bool isLastFrame)
>
> https://codereview.qt-project.org/c/qt/qtwebsockets/+/268194
>
> Feel free to pick up where I left off. I have absolutely no interest in web
> sockets so will not work on this.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Klocwork errors in Qt

[Konstantin Tokarev]

09.12.2019, 11:00, "Massimiliano Maini" :
> On Fri, 6 Dec 2019 at 19:41, Max Paperno  wrote:
>> On 12/4/2019 9:31 AM, Roland Hughes wrote:
>>> If you think auto won't be removed as a failed experiment, how about "new"? 
>>> Deprecated in C++20 and slated for removal in C++23.
>>>
>>> https://www.modernescpp.com/index.php/no-new-new
>>> Some more reading on the removal of pointers
>>>
>>> https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/
>>
>> TL;DR: This was a 2018 April Fool's joke.
>
> Ouch. That must hurt.

Well deserved.

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

Re: [Interest] QtWebView: how to ignore ssl errors?

[Konstantin Tokarev]

25.10.2019, 17:37, "Thiago Macieira" :
> On Thursday, 24 October 2019 16:42:05 PDT Alexander Ivash wrote:
>>  I understand all the theory behind, but still need to ignore errors
>>  for test purposes. If it is possible, where can I read how to achieve
>>  it? My understanding QtWebView uses native things for Android & IOS
>>  and WebEngine for desktop platforms and unfortunately there is no any
>>  public API allowing to ignore SSL errors, what I'm missing?
>
> Instead, import your test CA to your test device. That way, the SSL errors
> you're getting won't b errors and there won't be any debug code that you may
> forget to remove.

Or use tool like mitmproxy, which can be run on another machine.

-- 
Regards,
Konstantin

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

Re: [Interest] heads up - ksplashqml crash

[Konstantin Tokarev]

07.10.2019, 18:00, "Roland Hughes" :
> My hardware was new enough I could install 390. Others will most likely
> not be as lucky. 

It may be a good reason to replace their 9 years old GPU to something 
up-to-date.

-- 
Regards,
Konstantin

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

Re: [Interest] Expected event execution order in this multi-thread application

[Konstantin Tokarev]

30.09.2019, 11:38, "Rainer Wiesenfarth" :
> On Mon, Sep 30, 2019 at 9:26 AM Thiago Macieira  
> wrote:
>> [...] Anyway, this is when you should use processEvents(): never.
>
> ...which would be a perfect reason to at least mark it as obsolete in Qt 6?

I would strongly oppose such deprecation, as it would break a few places in 
QtWebKit where it's used to integrate non-Qt code with Qt event loop

>
> I strongly second Thiago's recommendation: processEvents() usually introduces 
> more problems than it solves.
>
> --
> Software Engineer | Trimble Imaging Division
> Rotebühlstraße 81 | 70178 Stuttgart | Germany
> Office +49 711 22881 0 | Fax +49 711 22881 11
> http://www.trimble.com/imaging/ | http://www.inpho.de/
>
> Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
> Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
> Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] QByteArray vs QString, arg, why is there no arg()?

[Konstantin Tokarev]

18.09.2019, 16:59, "Jason H" :
>>  Sent: Wednesday, September 18, 2019 at 2:50 PM
>>  From: "Giuseppe D'Angelo via Interest" 
>>  To: interest@qt-project.org
>>  Subject: Re: [Interest] QByteArray vs QString, arg, why is there no arg()?
>>
>>  Il 18/09/19 13:16, Jason H ha scritto:
>>  > What's the best way to zero-pad a QByteArray?
>>  > What I want is QByteArray("%1").arg(6, 10, 10, '0')
>>
>>  Mostly it has to do with the fact that QByteArray is sitting between two
>>  worlds; on one side it's just a container of bytes, on the other side it
>>  has _some_ manipulation functions for ASCII-like strings. "Some"
>>  because, as you've noticed, stuff like the arg() convenience is missing.
>>
>>  If you really need a QByteArray you can work around this by e.g. using a
>>  printf-like function, what you're looking for is the "%010d" formatting.
>>
>>  Pseudocode:
>>
>>  int n = 123;
>>  const char *format = "The number is %010d";
>>  auto size = qsnprintf(nullptr, 0, format, n);
>>
>>  QByteArray result(size, Qt::uninitialized);
>>  qsnprintf(result.data(), result.size(), format, n);
>
> That helps, but wasn't the answer I wanted to hear. I have to call 
> qsnprintf() twice. Granted, for valid reasons.and it might be faster than my 
> gluing things together with +.

Gluing things together with + in a single expression is probably faster than 
using arg() if you build your sources with -DQT_USE_QSTRINGBUILDER (or use 
operator % instead of + if you don't)

>
> I do prefer python's approach where the character size change does not come 
> with an API change. Maybe discussion for Qt6?. I would think they C++ way 
> would be to have 1 API and a template class? (Though I think some people 
> cringe at that idea)
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Konstantin Tokarev]

13.09.2019, 10:14, "René J. V. Bertin" :
> I finally got around to upgrading OpenSSL and getting to work Qt 5.9 with it. 
> It
> required an additional change that I hadn't found in the 5.10 branch: 
> accepting
> the newer version during the configure phase :)
>
> https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/qt597/patch-openssl11-support-qt597.diff
>
> Test-driving it I did notice that the securesocketclient example would crash 
> on
> me, due to which seems to be an oversight (still present in newer code):
>
> https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/qt598/patch-httpsockeng-fix.diff
>
> Thiago Macieira wrote:
>
>>  On Friday, 22 March 2019 13:02:57 PDT maitai wrote:
>
>>>  Ideally qt should be compatible for both. I understand this is not
>>>  doable ?
>>
>>  It's not doable.
>
> Technically it seems that it should be possible when loading the SSL libraries
> at runtime, no?
>
>>>  At least deliver binaries for both, please.
>>
>>  That's one option we're studying, but that means you'll have to ask your 
>> user
>>  when they download.
>
> What about LibreSSL, do they have the same inter-version compatibility issues 
> as
> OpenSSL has, and could you distribute a binary version in your binary 
> packages?
> If so, it could be worth the initial investment to start supporting it?

FWIW, you can find patches for LibreSSL support at 
https://bugs.gentoo.org/562050

-- 
Regards,
Konstantin

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

Re: [Interest] QML and sensitive data

[Konstantin Tokarev]

05.09.2019, 19:02, "Jason H" :
>>  On Wednesday, 4 September 2019 16:20:44 PDT Alexander Ivash wrote:
>>  > Thank you for fast response, but my question is purely about QML. On
>>  > C++ side I have a lot of ways for nullifying / erasing sensitive
>>  > information *after* it is not needed (let say after particular QML
>>  > screen gets' closed). But on QML / JS side I have no any control at
>>  > all. Would be great if one of QML guys could step in and comment too.
>>
>>  As I said, the moment you want to display a string, it's no longer 
>> considered
>>  secure. This has nothing to do with QML.
>>
>>  The string will be used for text shaping, the pixels will be drawn in a
>>  pixmap, said pixmap will be shared with the compositor, which then by some
>>  means uploads it to the GPU.
>
> If you have an array of non-contiguous 1-char strings, which are converted to 
> images, then displayed sequentially (increasing x position) then you never 
> have the string in memory.
>

If you can sacrifice proper shaping, this might actually work.

-- 
Regards,
Konstantin

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

Re: [Interest] Code coverage with QtCreator

[Konstantin Tokarev]

03.09.2019, 18:45, "Andy" :
> Not sure if it's quite what you're looking for, but I wrote up a tutorial on 
> using gcov & lcov with Qt5 & Qt Creator:
>
> "Code Coverage Of Unit Tests Using Qt 5 On macOS"
> https://asmaloney.com/2017/01/code/code-coverage-of-unit-tests-using-qt-5-on-macos/
>
> Might give you some ideas.

Line-based coverage is inherently sub-par approach as compared to 
condition/decision coverage provided by testcocoon. However it may be possible 
to achieve that by using different instrumentartion options of compiler.


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

Re: [Interest] Code coverage with QtCreator

[Konstantin Tokarev]

03.09.2019, 18:35, "Jérôme Godbout" :
> Is this integrate the CppUnit with is own listener? My test are in QTest, I 
> could translate them, just wondering if it does support this.

It's agnostic of test framework, it instruments code via its own preprocessor

-- 
Regards,
Konstantin

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

Re: [Interest] Code coverage with QtCreator

[Konstantin Tokarev]

03.09.2019, 17:47, "Jérôme Godbout" :
> Hi,
>
> Is there a good way to make code coverage with QMake and Qt Creator? I will 
> probably switch my codes to CMake with Qt 6, but for the time being I will 
> leave my projects as QMake and we do not use Visual Studio on Windows either. 
> Any free tools that can run on Windows, Linux, MacOS ?
>
> I have seen a few tools that are expensive or only work for GCC, but found 
> nothing that is open source and can run multiple platform so far.

You can try TestCocoon - it has easy to use integration with qmake:
https://github.com/testcocoon/testcocoon

It's an old version of what is called Squish Coco now. You'll have to build it 
from source. Build process produces nice pdf documentation.


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

Re: [Interest] Static build of Qt - debug mode and plugins

[Konstantin Tokarev]

30.08.2019, 21:29, "Jakub Narolewski" :
> Thank you Thiago for your suggestion :]
>
> I'm currently not able to use zstandard because I need it to work on my 
> client side - WebGL targeted Unity Engine builds.
>
> We had some problems getting it to work using different approaches.
>
> As for compression performance, zstd is still not as fast as lz4's 
> LZ4_compress_fast - at least not in my use case.

And not only yours - even benchmark results in zstd repository [1] demonstrate 
clearly that lz4 is substantially faster than zstd in both compression and 
decompression.

[1] https://github.com/facebook/zstd



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

Re: [Interest] Building Qt from Git: Information on version of external libraries

[Konstantin Tokarev]

22.08.2019, 17:23, "Rainer Wiesenfarth" :
> On Thu, Aug 22, 2019 at 4:07 PM Konstantin Tokarev  wrote:
>> 22.08.2019, 17:01, "Rainer Wiesenfarth" :
>>> I am trying to build Qt (in my case: 5.12.4) from Git and came along the 
>>>external ICU and OpenSSL libraries. Is there any page telling which version 
>>>of the external libraries was used when building Qt?
>>
>> When building Qt from sources you should better use newest available 
>> version, e.g. 64.1 for ICU. It doesn't really matter what version is used in 
>> official binaries.
>
> Hmm, yes and no. I fully agree that I should go as latest as possible, but if 
> - like with ICU by the introduction of a namespace - the API has changed, the 
> build will fail. I'd like to minimize those failing builds upfront... :-)
>
> So, I'd like to have a page telling me "was build using versions ..." to have 
> a safe fallback, and a base to judge if the latest version of an external 
> library might work or not.

See https://wiki.qt.io/Qt_5.12_Tools_and_Versions

Also, you can review provisioning scripts in [1] which are actually responsible 
for installing
software into Coin vm images.

[1] https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/

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

Re: [Interest] Building Qt from Git: Information on version of external libraries

[Konstantin Tokarev]

22.08.2019, 17:01, "Rainer Wiesenfarth" :
> Hi all,
>
> I am trying to build Qt (in my case: 5.12.4) from Git and came along the 
> external ICU and OpenSSL libraries. Is there any page telling which version 
> of the external libraries was used when building Qt?

When building Qt from sources you should better use newest available version, 
e.g. 64.1 for ICU. It doesn't really matter what version is used in official 
binaries.

>
> In detail: With Qt 5.6.2, I used ICU version 57.x. Since then, ICU seemed to 
> change quite a bit (at least with version 60, introducing namespaces). Thus I 
> was wondering if I should use ICU version 62-1, which was the latest version 
> when 5.12.0-alpha1 came out or if I should go back to ICU version 59.
>
> The same happens for OpenSSL, and maybe also for other libraries. I would 
> like to see a page telling me which versions the Qt team used when they built 
> their binary packages...
>
> Cheers, Rainer
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] Qt free software policy

[Konstantin Tokarev]

14.08.2019, 21:04, "David M. Cotter" :
>i’m ALLOWED to use the free version, right? or did i misunderstand how LGPL 
>works?

You are allowed to use it if you comply with LGPL terms.

In case new modules are licensed as GPL-only and you don't want/can't comply 
with GPL,
you won't be allowed to use that new modules (note that there are certain cases 
when
complying with GPL does not require you to releasing your code, for example if 
your
application runs on the server controlled by you and users interact with it 
only by means
of network connection).

Even in the case (very unlikely) that existing Qt modules are relicensed to 
GPL-only, you
can continue using previous version under LGPL terms, or make a fork.


>
>> On Aug 14, 2019, at 10:11 AM, Vadim Peretokin  wrote:
>>
>> Sorry but I'll ask the obvious question: you bet your entire business 
>> without paying for a license?
>>
>> Have I misunderstood you?
>>
>> On Wed, 14 Aug. 2019, 7:01 pm David M. Cotter,  wrote:
>>> +1 on this
>>>
>>> i am in the process of porting my legacy project to Qt and am afraid that 
>>> i’ve made the wrong choice.  i’m just one guy and i bet my whole business 
>>> on the availability of what  i need from Qt under LGPL
>>>
>>> i’m already using a third party HTTP server so i’m not affected by this but 
>>> it’s a worrying sign. I too agree that the HTTP server really should be 
>>> LGPL.
>>>
>>> What’s going to happen? It’s taken me over a year’s worth of work to get 
>>> this far with Qt and i’m only half done. did i make the wrong choice?
>>>
>>> -dave
>>>
 On Aug 14, 2019, at 9:18 AM, Benjamin TERRIER  wrote:

 Hi everyone,

 Since we are talking about the future of Qt these days, I would like
 to know The Qt Company free software policy with Qt.

 Today, most of Qt modules are released under 3 free software licenses: 
 LGPLv3,
 GPLv2 and GPLv3. Some modules are released only under GPLv3.
 If my memory is good, these GPLv3-only modules are the ones which used to
 be commercial-only modules (like Qt Charts).

 However, it seems to me that most, if not all (except Qt 3D), new Qt 
 modules
 are now being released only under GPLv3:
  - Network Auth
  - WebGL
  - WASM
  - Http Server
  - Lottie
  - Quick 3D
  - MQTT

 I understand that The Qt Company is only obligated to release new modules
 under GPLv3 (because of the KDE agreement).
 I understand also that The Qt Company business model is selling Qt licenses
 and has no direct financial interests in releasing Qt under any other 
 license.

 So I can understand that some modules, in particular those valuable for 
 wealthy industrial companies,
 are only released under GPLv3.
 However, for some modules like HttpServer, it seems to be an odd choice. 
 There are plenty
 alternatives available under LGPL or more permissive licenses, so I do not 
 see what
 would be the loss of releasing it under LGPLv3.

 Also the fact that those modules are GPLv3 only is a problem when 
 developing with other
 components that are GPLv2 only (and not GPLv2+).

 So I would like that someone could officially confirm if all new modules 
 will be
 released under GPLv3 only. Or if it is something that is decided on a per 
 module
 basis.

 I believe that Qt users and contributors deserve to know what it The Qt 
 Company
 view on this.
 Using an LGPLv3 framework is not the same thing as using a GPLv3 framework
 where some historical parts are available under LGPLv3 and all new 
 features will be GPLv3 only.

 BR,

 Benjamin


 ___
 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


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

Re: [Interest] qt creator 4.9.1 + qt 5.11.3 = android debugger not working

[Konstantin Tokarev]

02.07.2019, 22:31, "Alexander Dyagilev" :
> Hello,
>
> I've just noticed that debugger is not stopping on the breakpoints. It
> seems like it's not working at all.
>
> Is this a known problem? Do I have to upgrade to Qt 5.12 and clang for
> Android?

Are you sure that you are using debug build?

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

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

To be fair, it's not about protection of your system, but about protection of 
AppStore users and reputation of Apple as a company. For protection of your 
system you are free in choice of tools.


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

Re: [Interest] X11->XQuartz compatability?

[Konstantin Tokarev]

14.06.2019, 17:45, "Jason H" :
> I have a application running on an Ubuntu 16.04 Box. I want to get the window 
> on my Mac. I installed XQuartz and Inkscape and xeyes work. But when I launch 
> my Qt app, I get:
> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: swrast
> Unrecognized OpenGL version
> Unrecognized OpenGL version
> QGLXContext: Failed to create dummy context
> failed to acquire GL context to resolve capabilities, using defaults..
>
> And an all-white window.
>
> How can I get this to work? It's a QML app.

You can try using llvmpipe + LIBGL_ALWAYS_SOFTWARE=1 on Linux side.
It worked for me in the past.

-- 
Regards,
Konstantin

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

Re: [Interest] Online doc URL improvement

[Konstantin Tokarev]

06.06.2019, 05:09, "Christian Gagneraud" :
> Hi there,
>
> I quite often read the documentation online, b/c the urls are quite
> short and simple i usually type them in directly in the URL bar.

FWIW, you can get even better experience with local documentation

> One
> little thing is annoying me, the '.html extension.
> Wouldn't it be great if instead the url would be 'doc.qt.io/qt-5/qwidget'.
> That is shorter to type and easier to navigate to a class you know the
> name of. Currently you have to move the cursor around in the url field
> so that you replace the class name b/w '/' and '.html'. not having to
> deal with '.html' would make the process way faster/easier.
> Of course to avoid breaking search engine, bookmarks, ... the url with
> '.html' would have to redirect to the one w/o.
>
> Any thoughts?
>
> Chris
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] passing something into subdirs qmake

[Konstantin Tokarev]

05.06.2019, 14:29, "Kai Köhne" :
>> I want to invent some convenient way to switch between two variations
>  > of the same app.
>
> How do you plan to set these?
>
> If it's via command line (e.g. qmake CONFIG+= ...): This will be passed 
> automatically to SUBDIRS projects.
>
> If you somehow detect it otherwise: The common pattern here is to have the 
> switch logic in a .pri file, and include it from all .pro files needing it.

Less common pattern is using .qmake.conf in the root project directory


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

Re: [Interest] QFontComboBox without preview?

[Konstantin Tokarev]

30.05.2019, 13:44, "René J.V. Bertin" :
> Hi,
>
> Is there a way to prevent font previews in the QFOntComboBox widget, or do 
> application which offer to deactivate the feature have their own 
> implementation of a comparable widget?

Have you considered using regular QComboBox with list of font family names, 
obtained from QFontDatabase?

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

-- 
Regards,
Konstantin

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

Re: [Interest] Operator QMap[] is casting to int?

[Konstantin Tokarev]

07.05.2019, 17:45, "Giuseppe D'Angelo via Interest" :
> On 07/05/2019 16:11, Bernhard Lindner wrote:
>>>  1) the the change to qsizetype as an index type has not
>>>  happened yet, anyhow. It's still a huge question if it's doable in the
>>>  first place.
>>  It is still discussed? I thought it is pretty high at the priority list 
>> anyway.
>
> No such patch has landed, and the discussion on the mailing list
> stopped. I'm just guessing it's going to be one of the major points of
> debate during the container changes expected for Qt 6. It needs some
> serious experiment on some big code base.
>
> Disclaimer: I'm against this change, presented like that, on source
> compatibility reasons. If we can somehow get 100% SC, then I am totally
> in favour of it.
>
>>  I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't 
>> do it in a
>>  minor release, can you?
>>
>>  x64 is standard in many applications and memory sizes are growing. I have 
>> seen to many
>>  platforms/frameworks die an early death because developers where afraid to 
>> enforce
>>  fundamental architectural fixes/improvements (including evolving 
>> language)... until it was
>>  too late.
>
> The hard answer would be: never.
>
> If you need a 64-bit ready byte
> array/vector/map/hash/list/deque/stack/..., the Standard Library has
> been providing them for a very long time now. Qt should make the
> transition towards them easier. The reason why I'm still in favour of
> the change above is getting a 64-bit QString, whose equivalent simply
> does not exist in the Standard Library yet.
>
> (Honorable mention: QStringView is 64-bit ready.)

You were asking when static_casts between int and size_t are needed.
Interfacing Qt-based code with Standard Library types is one of such cases.

-- 
Regards,
Konstantin

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

Re: [Interest] QML preprocessing

[Konstantin Tokarev]

28.04.2019, 21:27, "Roland Hughes" :
> On 4/28/2019 11:31 AM, Konstantin Tokarev wrote:
>>  28.04.2019, 19:15, "Roland Hughes" :
>>>  If you are worried about a sensitive value being memory dumped because
>>>  of a completely insecure scripted language, then don't do it there.
>>  If some data is copied to memory it can be dumped from there, no matter
>>  what language are you using. There are no "secure" and "insecure" languages
>>  in this regard.
>
> Sure there are.
>
> https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html
>
> https://www.oreilly.com/library/view/secure-programming-cookbook/0596003943/ch01s09.html
>
> Most importantly, by placing all of the sensitive data used only for
> debug in C++ class methods bounded by #ifdef DEBUG statements, in a
> production release the copy will never happen.
>
> The scarier architectural problem with the original post is the
> console.log() call is calling something to convert a password to "free
> text" rather than dumping a hashed/encrypted version. Most production
> applications never bother with this. They compare a hashed/encrypted
> version of the entered password with the hashed/encrypted version stored
> on disk.
>
> Scripted languages are inherently insecure.  With QML and JavaScript you
> end up with stuff like this in your elf binary.
>
> DefaultButton {
>  id: helpButton
>  text: qsTr("Help")
>  iconSource: helpButton.pressed ? "/Images/help_pressed.png" :
> "/Images/NewButtonIcons/help_notpressed.png"
>  iconSizeX: 17
>  iconSizeY: 24
>  onClicked: {
>  popupHelpInfo.open()
>  popupHelpInfo.forceActiveFocus()
>  }
>
> I found that in a few seconds with Eclipse. Any number of "text" editors
> will let you open and view binaries. The amount of code and logic
> actually exposed to anyone willing to edit a copy of the file is
> immense. Not so with compiled C/C++ or even COBOL for that matter. If
> you are really worried about things like "Password" being found you have
> multiple options.
>
> 1) Under Qt use tr("1234") and always have a translation file, even for
> your native language.
>
> 2) Under any compiled language build the string programatically from Hex
> strings. FWIW, the Hex values for "Password" are 50 61 73 73 77 6F 72 64
>
> With a scripted language there is little you can do to avoid exposing
> your code. Yes, there is an option to "precompile" QML but it comes with
> significant limitations.
>
> https://doc.qt.io/qt-5/qtquick-deployment.html
>
> The most significant of which is being tightly bound to the version of
> QML compiled against. For an embedded system where you control the
> universe this could be acceptable. For an app which anyone can download
> and run it is not. If you developed under 5.2 and didn't use anything
> which disappeared in 5.12 you still want the user to be able to run your
> app. The inverse is true as well. Just because you used 5.12 doesn't
> mean you used something which only existed in 5.12.
>
> Under various operating systems (OpenVMS in particular) one can tell the
> compiler for the language of choice to place all string constants within
> a single PSECT or a series of them. In your linker options the named
> PSECT(s) can be flagged with an attribute which excludes them from dump
> utilities. These principals have been around since the 1980s when I
> started programming commercially on big-boy systems. Didn't matter if we
> were working in COBOL, FORTRAN or BASIC, we always had linker option
> files to flag string constant PSECTs as nodump. Even if the midrange or
> mainframe was air-gapped from the world we still did this. Back then we
> were only worried about dial-up access, the Internet did not exist in
> any meaningful way.
>
> With a scripted language you cannot do this. You are at the mercy of the
> engine.
>
> It would be interesting to see just how much text survives in
> pre-compiled QML. I would imagine it is a lot. If the QML engine is
> OpenSource then it isn't a difficult task for someone intent on gaining
> passwords via a dump or cache file on disk to find the text "Password"
> and decompile everything around it. They can't get back to the original
> source, but they can get close enough.
>
> Basically, if your application must be secure you cannot use a scripted
> language.

You are trying to defend security through obscurity here. If attacker can 
directly
dump memory of the process, game is over, and it's not principal how much work
is needed to decompile code (which may not be needed at all, depending on data
or source leaks or other possible scenarios)

-- 
Regards,
Konstantin

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

Re: [Interest] QML preprocessing

[Konstantin Tokarev]

28.04.2019, 19:15, "Roland Hughes" :
> If you are worried about a sensitive value being memory dumped because
> of a completely insecure scripted language, then don't do it there.

If some data is copied to memory it can be dumped from there, no matter
what language are you using. There are no "secure" and "insecure" languages
in this regard.

-- 
Regards,
Konstantin

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

Re: [Interest] QML preprocessing

[Konstantin Tokarev]

24.04.2019, 22:01, "Alexander Ivash" :
> What I really need is some 'plugin' to qmake which would allow to
> modify qml files on the fly before placing it into resources (but not
> touching them on filesystem!). In ideal world, yeah.

That's possible to do with qmake already, but you'll have to build
resource files manually via custom targets

>
> ср, 24 апр. 2019 г. в 21:51, Alexander Ivash :
>>  2Jerome:
>>
>>  The issue is that even if that function will be doing nothing, logging
>>  data (which might be sensitive) can be captured via hooks / dump
>>  analysis etc. I really need to pre-processes to eliminate not only
>>  function call but also function parameters completely. Think about
>>  this scenario:
>>
>>  console.debug('password: ',
>>  someFunctionWhichReturnsPasswordFromProtectedStorage());

You can wrap this whole expression into function and replace that
function with empty one:

function printPasswordToDebug() {
  console.debug('password: ', 
someFunctionWhichReturnsPasswordFromProtectedStorage());
}

and replace printPasswordToDebug

>>
>>  In this case even if console.debug will be replaced with empty
>>  function, 'someFunctionWhichReturnsPasswordFromProtectedStorage()'
>>  will be executed anyway and as the result password will appear
>>  somewhere in JS heap so after capturing dump it will be simpler to
>>  find it.
>>
>>  2Tomasz:
>>
>>  In fact I would love to use logging category, but only for debug
>>  builds. But I have some requirements to minimize risk of sensitive
>>  data leak via logging. And to make a life of reverse engineers a bit
>>  more complicated if you like. So ideally no logging-related functions
>>  (and their parameters too!) should be visible in release build.
>>
>>  ср, 24 апр. 2019 г. в 21:27, Jérôme Godbout :
>>  >
>>  > Maybe you can overload the functor directly into the code and import the 
>> file only if in debug mode (optional module):
>>  > http://udidu.blogspot.com/2012/12/override-console-functions.html
>>  >
>>  > That could also be helpful to split the log into multiple receiver.
>>  >
>>  > Not sure if this would work, but maybe you can override the console.log 
>> command into the QQmlScriptEngine and define a new javascript function that 
>> does nothing. Maybe into the your main.cpp where you create the QQmlEngine 
>> you can call the rootContext() QQmlContext object, maybe you can extract the 
>> console object with QVariant contextProperty() and set the debug() property 
>> of it with a QQmlExpression, I cannot glue all this together, but maybe 
>> something into that direction could be done before you start loading the 
>> main qml file. This is far fetched by might work but it seem overcomplicated 
>> to me.
>>  >
>>  > -Original Message-
>>  > From: Interest  On Behalf Of Alexander 
>> Ivash
>>  > Sent: April 24, 2019 12:56 PM
>>  > To: interestqt-project.org 
>>  > Subject: [Interest] QML preprocessing
>>  >
>>  > I understand that this topic was raised a lot of times and that this is 
>> not QML-way. But, what options do I have in case of requirements to 
>> eliminate all the logging for release builds?
>>  >
>>  > Is there any hidden magic in qmake, like 'QMAKE_SUBSTITUTES' but more 
>> flexible to substitute all the 'console.debug' with '// console.debug' 
>> right before adding qml into resources?
>>  >
>>  > p.s. Yea, I'm aware of selectors, but would like to avoid having both 
>> component-with-logging.qml and component-with-no-logging.qml
>>  >
>>  > Regards, Alexander
>>  > ___
>>  > 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

-- 
Regards,
Konstantin

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

Re: [Interest] Qt + Android + OpenSSL

[Konstantin Tokarev]

15.04.2019, 21:16, "Nuno Santos" :
> Hi,
>
> I’m trying to use SSL websocket on a Qt 5.12 Android app.
>
> When I run the app it is complaining about the missing functions.
>
> W qt.network.ssl: QSslSocket: cannot resolve DTLSv1_2_server_method
> W qt.network.ssl: QSslSocket: cannot resolve DTLSv1_2_client_method
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_CTX_new
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_CTX_free
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_CTX_set_ssl_ctx
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_CTX_set_flags
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_CTX_finish
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CONF_cmd
> W qt.network.ssl: QSslSocket: cannot resolve SSL_set_alpn_protos
> W qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_alpn_select_cb
> W qt.network.ssl: QSslSocket: cannot resolve SSL_get0_alpn_selected
> W qt.network.ssl: QSslSocket: cannot resolve DTLS_server_method
> W qt.network.ssl: QSslSocket: cannot resolve DTLS_client_method
> W qt.network.ssl: QSslSocket: cannot call unresolved function 
> DTLS_client_method

Note that these warning messages don't necessary mean a problem for you.
For examples, if your application doesn't use DTLS or HTTP/2 protocol 
negotiation
you can ignore DTLS and ALPN warnings.

> I’m providing OpenSSL 1.0.1s as an ANDROID_EXTRA_LIBS param.
>
> Does anybody know if the problem here is the fact that OpenSSL is too old?
>
> Thanks in advance!
>
> Regards,
>
> Nuno
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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

Re: [Interest] Random question Friday: Why no area() for Rects and Sizes?, path.join()?

[Konstantin Tokarev]

12.04.2019, 18:11, "Jason H" :
> 1. Area of concern
> I find myself wanting to know the area of rectangular things a lot. For Sizes 
> and Rects: it's abs(width()*height()), but Rects might also have a offset 
> from the origin.
> Either way, I was wondering why this was not added to Qt already? When 
> working with images, it gives things like pixel counts and

I guess reason is the same as why Qt doesn't have classes like QTriangle or 
QEllipse. QRect's primary concern is GUI-related programming, not properties of 
particular geometric shape.

-- 
Regards,
Konstantin

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

Re: [Interest] How to properly show progress for a signal processing pipeline

[Konstantin Tokarev]

  08.04.2019, 16:16, "Murphy, Sean" :> We have a data processing pipeline that looks like so:> Raw Data objects -> Type "A" data objects -> Type "B" data objects -> Final Data objects>> Each step can be considered a filtering process where the following mathematical relationship holds for the quantities of each type of object:> Raw count >= A count >= B count >= Final count> Technically all of those quantity relationships can be >=, but in practice they almost never equal, the left hand side is almost always greater than right hand side, but it's technically possible that some could be equal with the right input data.>>  So the issue I'm having here is that I want to show the user some sort of progress indicator (this whole pipeline takes a bit of time), but at the start I only know the raw count, not any of the intermediate or final counts. And because the A->B->Final portion of the pipeline takes a noticeable amount of time, I can't just run the progress bar from 0 to Raw count, because then from the user's standpoint the progress bar would reach 100% once the number of raw samples is exhausted, not when processing is fully complete.>> Is my only strategy to use the "undetermined state" of QProgress bar to just show "something" is happening, but not how far along we are in the process? To make the issue even a little more complicated, each processing node is running in a separate thread, so these conversions are happening in parallel as much as possible, making tracking a little more difficult. For example, at any given point in time, the node that converts type A objects to B objects, might be empty. It may have processed all of the A objects it has received into all the B objects it can make and passed them on to the next node, while the node ahead of it might not have finished its work on the next chunk of raw data to emit the next A object. So at that instant in time, the A->B node thinks it's "done" until it receives the next A object at some time later. Assuming that the main chunk of work is done on A->B step, you can increment progress bar when each thread is started and finished, plus fixed amounts of progress for the first and the last step. Approximate thread number as 2*Raw when it starts, and when amount is known, adjust progress bar settings accordingly.  -- Regards,Konstantin ___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Detemine Run into VM

[Konstantin Tokarev]

28.03.2019, 17:49, "Thiago Macieira" :
> On Thursday, 28 March 2019 05:59:57 PDT Konstantin Tokarev wrote:
>>  28.03.2019, 03:58, "Thiago Macieira" :
>>  > On Wednesday, 27 March 2019 12:56:15 PDT Konstantin Tokarev wrote:
>>  >> Note that it will only work if user has systemd installed
>>  >
>>  > Is there any modern Linux without it?
>>
>>  Hopefully, there a few, e.g. Gentoo, Void Linux, Devuan
>
> In Gentoo it's optional, not the default. The other ones are not mainstream.

Another one is Alpine Linux, which is often used as a base for container images
because of its low footprint.

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

-- 
Regards,
Konstantin

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

Re: [Interest] Detemine Run into VM

[Konstantin Tokarev]

28.03.2019, 03:58, "Thiago Macieira" :
> On Wednesday, 27 March 2019 12:56:15 PDT Konstantin Tokarev wrote:
>>  Note that it will only work if user has systemd installed
>
> Is there any modern Linux without it?

Hopefully, there a few, e.g. Gentoo, Void Linux, Devuan

-- 
Regards,
Konstantin

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

Re: [Interest] Detemine Run into VM

[Konstantin Tokarev]

27.03.2019, 22:50, "Jérôme Godbout" :
> Thanks, I have an issue that software reset my cdc_acm device inside a VM 
> make the xhci goes nuts (on native install it work just fine). So I will 
> print a message box when inside a VM and ask the user to unplug and replug 
> the device instead or software reset it. On native or Windows vm I will 
> simply do it by software and continue without user intervention. If I ever 
> found a cause or a real fix I will remove that popup, but until then I have 
> something that will work at least.

Note that it will only work if user has systemd installed

>
> -Original Message-
> From: Interest  On Behalf Of Thiago Macieira
> Sent: March 27, 2019 3:41 PM
> To: interest@qt-project.org
> Subject: Re: [Interest] Detemine Run into VM
>
> systemd-detect-virt -v if you don't want to be told about being run inside 
> containers.
>
> Note that you can also use ConditionVirtualization in your systemd units if 
> you need to start (or not start) a service.
>
> On Wednesday, 27 March 2019 11:37:42 PDT Jérôme Godbout wrote:
>>  Nice, thanks Thiago!
>>
>>  -Original Message-
>>  From: Interest  On Behalf Of Thiago
>>  Macieira
>>  Sent: March 27, 2019 2:05 PM
>>  To: interest@qt-project.org
>>  Subject: Re: [Interest] Detemine Run into VM
>>
>>  On Wednesday, 27 March 2019 09:11:11 PDT Jérôme Godbout wrote:
>>
>>  > Is there a way to detect the application run inside a VM from Qt?
>>
>>  Run systemd-detect-virt.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Konstantin Tokarev]

20.03.2019, 21:17, "René J. V. Bertin" :
>>  Which distribution already stopped shipping OpenSSL 1.0?
>
> See my other email: for now this is for MacPorts, but I'm guessing Qt may not
> want to depend only on an OpenSSL variant that's EOL.
>
> Moving to 5.10 may be relatively trivial on Linux but not on Mac, if you want 
> to
> keep supporting OS versions that don't run 5.10 .
>
> Judging from the commit, OSSL 1.1 support was added to the dev branch almost
> exactly TWO years ago. I can't remember when 5.9 came out but it must not have
> been older than the "current" version back then. Why on earth was this change
> never cherry-picked to the 5.9 branch?!

Because it is a major rewrite of QtNetwork code interfacing with OpenSSL. Such 
change
cannot go to LTS branch [1]

[1] http://quips-qt-io.herokuapp.com/quip-0005.html

> It's not like it introduces all kinds of
> hot new features, and if I understand correctly this kind of change to the 
> OSSL
> backend should be completely transparent for dependent software?
>
> R.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Konstantin Tokarev]

20.03.2019, 21:03, "René J.V. Bertin" :
>> You should either use Qt >= 5.10 or build against OpenSSL 1.0.2
>
> Wrong answer :P
>
> If Qt 5.9 is still in LTS it should get commit 
> cfbe03a6e035ab3cce5f04962cddd06bd414dcea cherry picked from the dev branch 
> before 1.0 reaches EOL later this year.
>
> Is that commit sufficient? Getting it to apply to the 5.9 branch was a bit of 
> monks' work but perfectly doable;
> see https://trac.macports.org/ticket/58218
>
> The MacPorts project is in the process of migrating the default OpenSSL 
> version to 1.1 . I haven't yet upgraded but am preparing; my patched Qt 5.9.7 
> seems to work fine with OSSL 1.0.2r .

It would be better to upgrade Qt in MacPorts

>
> David: IIRC Qt doesn't work with LibreSSL.
>
> R.

-- 
Regards,
Konstantin

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

Re: [Interest] Qt 5.9 and OpenSSL 1.1?

[Konstantin Tokarev]

20.03.2019, 13:18, "René J.V. Bertin" :
> Hi,
>
> I just learned that Qt 5.9 apparently doesn't build against OpenSSL 1.1 . 
> Does anyone already have a fix for this?

You should either use Qt >= 5.10 or build against OpenSSL 1.0.2

>
> If not I'll try to adapt Debian's OSSL 1.1 support patch for Qt4; that might 
> even be upstreamable supposing there will be further Qt 5.9 releases ?
>
> Thanks,
> R.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Fwd: vs. Flutter

[Konstantin Tokarev]

27.02.2019, 18:23, "Jason H" :
>Who knows Objective C and Java? Not many.

I guess that amongst mobile developers this number is higher than for C++

-- 
Regards,
Konstantin

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

Re: [Interest] vs. Flutter

[Konstantin Tokarev]

19.02.2019, 15:27, "Vlad Stelmahovsky" :
> QtMultimedia cant be less power than GStreamer, because QtMultimedia on linux 
> uses gstreamer as backend :)

It's less powerful because its API provides lowest common denominator of all 
media backends

> However I'd like to see there something like custom pipeline provider to 
> Gstreamer it would be really useful for different usecases
>
> br,
> Vlad
>
> On Mon, Feb 18, 2019 at 9:39 PM Christian Gagneraud  wrote:
>> On Tue, 19 Feb 2019 at 02:57, Jason H  wrote:
>>>
>>> Are there any good Qt vs Google Flutter comparisons?
>>> I took a brief look, it looked like a declarative JS framework. Usually the 
>>> difference with between Qt and the competition is Qt abstracts there 
>>> platform libraries (i.e. Gstreamer vs avfoundation vs directshow)
>>
>> OT: This is not always a good thing. QtMultimedia is less powerful
>> than Gstreamer for example. So if you target embedded Linux, you might
>> prefer to use gstreamer directly instead of using QtMultimedia.
>>
>> Chris
>>
>>> ___
>>> 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
>
> --
> Best regards,
> Vlad
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest


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

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

[Konstantin Tokarev]

I personally find this troll rather amusing, and will be kinda missing those wall of text rants in case he gets banned :) 11.02.2019, 19:09, "Michael Jackson" :We all get frustrated at times and sometimes that frustration comes out in posts (hopefully with a short  tag..) but Roland’s posts _always_ have put downs for almost every other kind of developer except those in the medical/space community. I consider myself having pretty thick skin and I can ignore those posts (Gmail server side rules make sure of this) but at some point Roland needs to be told in no uncertain terms that the list is for questions/answers not long tirades. I don’t mind discussing the merits of the different systems, use-cases of those systems, developer learning and all that. Those can be enlightening discussions in and of themselves. But at some point, we as a community, just need to let Roland know that his demeanor is not conducive to getting responses on the list and soon will no longer be tolerated. -- Michael A. Jackson                 400 S. Pioneer BlvdOwner, President                   Springboro, Ohio 45066BlueQuartz Software, LLC           EMail: mike.jack...@bluequartz.net  From: Interest  on behalf of René Hansen Date: Monday, February 11, 2019 at 10:16 AMTo: Jason H Cc: Qt Interest Subject: Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins] I'm with Jason here.I use Qt for mobile development as well, and I don't think a ban is the right course of action. Choice of words is a pre-eminent selector in deciding which posts to take seriously. Using terms in the the manner Roland does about phone development, in all likelihood, self-disqualifies any serious consideration his posts might have received otherwise. Although a shame, that is repercussion enough in my opinion./René On Mon, 11 Feb 2019 at 15:07 Jason H  wrote:The truth is I often enjoy the hyperbole. In my book it's better to have a thick skin rather than to go around being offended by everyone and asking for them to comply with a fragile nature. However this most recent post put down the Qt mobile community of which I am a significant member having been using Qt in mobile for about the past 5 years. I have argued repeatedly for more attention in the Mobile platforms (except WinRT) and the message was directly contrary to that aim. I pointed out (off list) ironically what should happen is port the application to mobile and just let Samsung make and revise the hardware faster than he ever could. Didn't draw any ire but it didn't go anywhere either. I'm starting to wonder if the hyperbole isn't for comedic effect.My plan of action is that I'm just going to ignore this person's snarky posts which comes with the price that I might have the answer to their issue and I won't contribute it.I on occasion post something snarky because I am frustrated with the problem I'm having. I wouldn't want to be banned over it. There is a social capital here, add I try to have a positive balance. And I think it's reasonable that when you fall below zero, you stop getting replies. I would not bring in the CoC just yet.> Sent: Friday, February 08, 2019 at 8:18 PM> From: "Konstantin Shegunov" > To: m...@herrdiel.de> Cc: "Interests Qt" > Subject: Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]>> >> > [...]> > I do appreciate the open discussion style on this list. I even do> > appreciate a somewhat harsh style, if it has a factual base and is> > getting straight to the point instead of b*s*ing around. But those> > lengthy wallpapers our President of Logikal solutions commonly utters,> > have long since crossed the border from amusing to annoying.> >>> I, myself, still perceive them more as amusingly misguided, than really> angering (annoying at times, yes). This is just me, though, I have> experience with that kind of thing. However, I can very well imagine how> you, and most certainly others, are finding them taxing; not surprising at> all.> Plus, as I rule, I tend to discard anything that references fortran or> cobol as examples of anything ... ;)> ___> Interest mailing list> Interest@qt-project.org> https://lists.qt-project.org/listinfo/interest>___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest,___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest  -- Regards,Konstantin ___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Modern

[Konstantin Tokarev]

21.12.2018, 21:34, "Jason H" :
> I would attribute Flutter to React. It's far more likely that Google is aware 
> of Facebook. What I've seen of Flutter looks like React to me.
>
> Now the question is "Was React inspired by QML?" QML is about 10 years old 
> now and pre-dates everything of the style.

No, it doesn't. For example, EFL's Edje exists since 2003

https://www.enlightenment.org/_legacy_embed/edje_main.html#edje_main_intro_example
 (look at code after "The above example requires the following annotated source 
Edje file" words)



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

Re: [Interest] Modern

[Konstantin Tokarev]

21.12.2018, 19:42, "Vlad Stelmahovsky" :
> Nope, its only my guess based on short Dart code checking and some articles, 
> how it works
>
> Google definitely aware about Qt, but its huge, so..

Note that declarative UI description languages were known long before QML, even 
Motif had a couple of them


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

Re: [Interest] QFile subclass that does HFS compression?

[Konstantin Tokarev]

17.12.2018, 22:28, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  How does that work? Is that just an ioctl, fcntl or a similar system call on
>>  the open file descriptor? If so, you can do it right now.
>
> Unfortunately, no. Decompression is transparent like you'd expect from a
> filesystem level for of compression, but you have to do the compression
> yourself. And it's a chunked form of compression, but that probably makes it
> easier to integrate it into an existing "write pipe" where you do not already
> have all data ready to be written to storage.
> You also have to maintain a chunk offset table, and a bit of metadata like the
> uncompressed file size. Depending on the size of the compressed data, it's
> stored either as an extended attribute, or else it goes into the file's 
> resource
> fork.
>
> Libarchive has an option to extract the files with HFS compression, if you 
> want
> to have a look at a well-tested implementation.
>
>>  Do you want an API for it?
>
> No, I was thinking of an option to set while opening a file for writing and 
> that
> makes the compression as transparent as possible (seek would probably have to 
> be
> disabled for instance).
>
>>  could benefit from this, the proposal would be stronger. NTFS and btrfs have
>>  compression, for example, and on Linux you can set attributes like secure
>>  deletion too.
>
> I don't know about secure deletion but the compression in NTFS and btrfs (or
> ZFS) is not a property you request when you open a file AFAIK.

I'm not sure about ZFS, but other mentioned file systems support per-file 
compression
setting. In Linux this is done by setting FS_COMPR_FL flag in FS_IOC_GETFLAGS 
ioctl 

> It's a filesystem
> property that is set at the level of the directory or dataset. HFS compression
> in QFile would really be Mac-specific, most 3rd-party HFS drivers for other 
> OSes
> do not even support the feature.
>
> R
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] QFile subclass that does HFS compression?

[Konstantin Tokarev]

17.12.2018, 20:13, "Thiago Macieira" :
> On Monday, 17 December 2018 01:36:50 PST René J.V. Bertin wrote:
>>  Using HFS compression can be very beneficial for files that you write once
>>  and read often (or very infrequently) as well as for tiny files (which are
>>  reduced to only a directory entry). Being able to create such files
>>  directly in compressed form is typically an order of magnitude faster than
>>  using a post-hoc compression utility like afsctool.
>
> How does that work? Is that just an ioctl, fcntl or a similar system call on
> the open file descriptor? If so, you can do it right now.
>
> Do you want an API for it? Then if you had a few more attributes and OSes that
> could benefit from this, the proposal would be stronger. NTFS and btrfs have
> compression, for example, and on Linux you can set attributes like secure
> deletion too.

UBIFS (which is often found in embedded devices with raw NAND flash) also 
supports
compression flag, however it's usually used to disable compression of certain 
files
while everything else is compressed by default.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

05.11.2018, 23:31, "Thiago Macieira" :
> On Monday, 5 November 2018 11:33:58 PST René J.V. Bertin wrote:
>>  On Monday November 05 2018 12:03:31 René J.V. Bertin wrote:
>>  >In my experience clang generates significantly more compact binaries
>>
>>  Quite: bzipped tarballs of everything except the examples, translations,
>>  QWE, QtWebView and Qt3D:
>
> Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
> decompress and produces worse results than xz.

bzip2 still has one valid use case: it requires less memory for compression

>
>>  -rw-r--r-- 1 root root 363M Sep 8 13:22
>>  qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
>>  -rw-r--r-- 1 root root 199M Nov 5 19:22
>>  qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)
>>
>>  The first built with GCC 8, the 2nd with clang 6.0; identical compiler
>>  options (release build, -O3, force_debug_info for qtbase).
>
> Please compare debug-stripped binaries.
>
>    text data bss dec hex filename
> 7205857 200632 1714 7408203 710a4b lib/libQt5Widgets.so
> 6727027 197920 1576 6926523 69b0bb clang/libQt5Widgets.so
>
> Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, but
> not significantly so. And since -O3 means "aggressively optimise, even if it
> takes longer to compile or increases the size considerably", you don't really
> care about size. Bigger code could indicate more optimisations applied (loop
> unrolling, vectorisation).
>
> Anyway, compare the debug sections of the two:
>
> GCC:
> Section Headers:
> [Nr] Name Type Off Size ES Flags Lk Inf Al
> [29] .debug_line PROGBITS 00710a80 002c360b 0 0 0 1
> [30] .debug_info PROGBITS 009d408b 00567018 0 0 0 1
> [31] .debug_abbrev PROGBITS 00f3b0a3 0002813a 0 0 0 1
> [32] .debug_aranges PROGBITS 00f631e0 fd70 0 0 0 16
> [33] .debug_str PROGBITS 00f72f50 001f84b5 1 MS 0 0 1
> [34] .debug_ranges PROGBITS 0116b410 002f3a20 0 0 0 16
>
> Clang:
> [28] .debug_aranges PROGBITS 0069c0a0 0080 0 0 0 16
> [29] .debug_info PROGBITS 0069c120 004b52fc 0 0 0 1
> [30] .debug_abbrev PROGBITS 00b5141c 6dea 0 0 0 1
> [31] .debug_line PROGBITS 00b58206 0032d586 0 0 0 1
> [32] .debug_str PROGBITS 00e8578c 000377fb 1 MS 0 0 1
> [33] .debug_macinfo PROGBITS 00ebcf87 00b6 0 0 0 1
> [34] .debug_ranges PROGBITS 00ebd040 00135ff0 0 0 0 16
>
> Clang carries 9793421 bytes of debug information, while GCC produces 13951906.
> That's a much bigger difference.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

07.11.2018, 01:09, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
>>  decompress and produces worse results than xz.
>
> Xz is even slower, and on the machine these numbers came from that difference 
> is
> more important in this case.

Use pxz to utilize all cores when compressing

>
>>  Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, 
>> but
>>  not significantly so.
>
> You know that significant is not a synonym for considerable, right? ;)
>
>>  takes longer to compile or increases the size considerably", you don't 
>> really
>>  care about size.
>
> Off-topic, but if I can get the same performance with a smaller size, why opt
> for the larger size?
>
>>  Clang carries 9793421 bytes of debug information, while GCC produces 
>> 13951906.
>>  That's a much bigger difference.
>
> I know; most of my builds do have debug info so this is important to me.
> I should look into using separate debug info sometime, but not if it gives
> something comparable to the .dSYM folders that tend to litter my directories. 
> I
> hate that for some reason.
>
> R
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Qt Commits - Where to Find the Patches by Commit-Id

[Konstantin Tokarev]

20.10.2018, 20:19, "coroberti ." :
> Hi,
> The bug report https://bugreports.qt.io/browse/QTBUG-69281
> refers to commit:
>
> 5be48d4238465b4efd36ed4bbb96ec407be9f217
>
> Where I can find the patch by the commit-id.
>
> Qt Codereview seems to be the place but without search by commit-id.
> https://codereview.qt-project.org/#/q/status:open,n,z

You can just enter 5be48d4238465b4efd36ed4bbb96ec407be9f217
into search field

>
> Another question is whether Qt-5.11.3 branch exists?
>
> Thanks in advance.
>
> Kind regards,
> Robert Iakobashvili
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] proper (silent) exit in response to SIGHUP?

[Konstantin Tokarev]

15.10.2018, 19:22, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  I wasn't joking. The Unix systems often copy neat features from one another
>>  when one innovates ahead of the others. I have a pending patch for Linux
>>  copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it.
>
> So you meant "ask to incorporate this here implementation". That might work 
> for
> Linux, possibly (Free)BSD which are open source ... but I wouldn't keep my 
> hopes
> up with the likes of Apple.

XNU kernel is also open source.

-- 
Regards,
Konstantin

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

Re: [Interest] cmake and auto-generated sources

[Konstantin Tokarev]

21.09.2018, 20:17, "Thiago Macieira" :
> On Friday, 21 September 2018 07:58:51 PDT René J.V. Bertin wrote:
>>  I think qmake-based projects generate those things as the first step during
>>  a make, while cmake-based projects generate them on an as-needed basis.
>
> Both do the same at the same time, during make.
>
> You should build your project once for all the generated files to be present.

There is a sligh difference though: cmake's automoc re-scans source tree on each
make to determine if new files need to be moc'ed, while with qmake it's done 
only
when qmake is executed

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Priority of bugs

[Konstantin Tokarev]

20.09.2018, 15:59, "Krzysztof Kawa" :
> Hi,
> I really hate to be "that guy" again, but I'd just like to know what's going 
> on.
>
> Some time ago I complained about bugs not being resolved for many
> major releases. I was then told my reports were P2 or lower and I
> can't expect them to be taken care of. That sucks for me but I can
> understand to some degree.
> But now a new release is out and I still have three P1:Critical
> issues, reported 3 or 4 releases ago, all being regressions btw, and
> nothing is fixed. There's a next major release around the corner and
> it doesn't seem to fix these either.
>
> Are only P0 reports looked at?

Only P0 bugs block releases, others don't have predicatable schedule.

You may get fixes faster if
* you contact maintainers of respective code and provide additional
information such as debugging details
* you convince people that priority should be promoted to P0
* you contribute fixes yourself

> Why do we even have other categories if
> they are all treated the same way?

To sort issues by priority in JIRA queries, of course :)

>
> It feels like more and more features I don't need are being added and
> more and more features I've been using for years are randomly broken
> in new releases and never fixed back while hanging in jira limbo.
>
> Wouldn't it be a good idea to have a clear policy like certain P level
> is fixed or at least a workaround proposed in the span of X releases
> at which point they become a block or are dropped entirely? And
> shouldn't regressions be treated more seriously? If a new feature has
> a bug I just don't start to use it, no problem, but if something
> breaks after update I'd like to at least know I can skip a release and
> wait for a fix. Now I don't know if it ever gets fixed again.
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

30.07.2018, 16:17, "Roland Hughes" :
> On 01/14/2018 03:53 AM, Nikos Chantziaras wrote:
>> On 12/01/18 17:30, Thiago Macieira wrote:
>>> On Friday, 12 January 2018 01:01:20 PST Igor Mironchik wrote:
 Hi, What was used to write first version of QtCreator, what IDE? Just 
 interesting... :)
>>>
>>> Emacs, Vim and Visual Studio.
>>
>> Also known as The Good, the Bad and the Ugly.
>
> Sorry for the necro-post, but I'm finally getting near the end of writing 
> "The Phallus of AGILE and Other Ruminations" and digging through the old 
> Interest Digest issues in my inbox from the time when we were all discussing 
> AGILE.
>
> I would hate to think anyone utilized Eclipse to create QtCreator. I would 
> hope, given KDE's ties to Qt that KATE/KDevelop were used to create it.
>
> Just my personal opinion though.

Please keep us informed, it is so much on-topic for this list

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

Re: [Interest] promoting a QGuiApplication to a QApplication?

[Konstantin Tokarev]

11.07.2018, 12:29, "René J.V. Bertin" :
> Hi,
>
> I'm tinkering with using a Qt plugin that expects a QApplication in a 
> QGuiApplication (specifically, a QML application using QGuiApplication).
> I'm not doing anything that causes a straight crash (or haven't run into that 
> one fatal instruction yet), but I do wonder:
>
> is it in any way possible to promote a QGuiApplication instance to a 
> QApplication? Somewhat unexpectedly, `dynamic_cast(qApp)` 
> behaves as `static_cast` or `const_cast` in this case (= it returns qApp). Or 
> it returns a nullptr in
>
> QGuiApplication app(argc, argv);
> QApplication *gapp = dynamic_cast(&app);
>
> which is probably what you'd expect.
>
> Still, with QApplication inheriting QGuiApplication one could think that the 
> former does some initialisation the latter lacks and that it should be 
> possible to perform those steps at a later stade. Is it?

If application object is created as QGuiApplication, you obviously cannot cast 
it to QApplication.

If you want to do something only when application object is created as 
QApplication (or its subclass), use qApp pointer


-- 
Regards,
Konstantin

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

Re: [Interest] 32-bit mingw ld out of memory

[Konstantin Tokarev]

05.06.2018, 21:54, "Vyacheslav Lanovets" :
> Hello,
>
> I experience out of memory error in ld from mingw 5.3 included into Qt.
>
> Is it possible to use 64-bit version of mingw-w64?

Yes, but you need to build Qt from sources in this case

>
> And how can I use multi-threaded C:\Qt\Tools\mingw530_32\bin\ld.gold.exe to 
> build Qt apps?

Note that ld.gold is ELF-only, it cannot produce PE executables

>
> Please help!
>
> Regards,
>
> Vyacheslav
>
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] Faster QXmlStreamWriter?

[Konstantin Tokarev]

25.04.2018, 19:08, "Thiago Macieira" :
> On Wednesday, 25 April 2018 08:45:41 PDT Thiago Macieira wrote:
>>  On Wednesday, 25 April 2018 07:13:18 PDT Konstantin Tokarev wrote:
>>  > 25.04.2018, 09:43, "Thiago Macieira" :
>>  > > So Qt 6 QJsonDocument & family will have the 128 MB limit
>>  > > removed, at the expense of the binary JSON format requiring parsing.
>>  >
>>  > That's sad, as we lose the single solution inside Qt for serialization
>>  > without parsing
>>
>>  That was going to happen anyway, because of the 128 MB size limit. If we did
>>  nothing else, we'd create a new format with a much expanded size limit,
>>  which means the current format would need to be parsed and converted.
>
> By the way, QJsonDocument::fromBinaryData does still perform a correctness
> check, to make sure it won't crash later reading corrupt data. You can skip
> this step and then loading your data is extremely fast.

For example, QtWebChannel implementations in QtWebKit and QtWebEngine
use QJsonDocument as a wire format for exchanging data between processes,
of course validation is skept because producer and consumer are reliable.

>
> Here are my numbers comparing loading that 60+ MB file in both binary JSON
> format (with validation) and CBOR:
>
> Binary JSON:
>  69,844846 task-clock:u (msec)
>    196.906.259 cycles:u
>    422.255.714 instructions:u
> [There's no readAll(); 70.2% of the time is spent inside
> QJsonPrivate::Object::isValid]
>
> JSON:
> 255,809132 task-clock:u (msec)
>    771.771.000 cycles:u
>  2.690.966.058 instructions:u
> [80.2% inside QJsonPrivate::Parser::parseValue, 58.7% inside
> QJsonPrivate::Parser::parseString and 16.3% inside QUtf8Functions::fromUtf8]
>
> CBOR:
> 239,059121 task-clock:u (msec)
>    562.474.857 cycles:u
>  1.431.590.428 instructions:u
> [71.6% inside QCborValue::fromCbor, 65.0% inside
> QCborContainerPrivate::decodeStringFromCbor, 25.5% inside
> QCborStreamReader::readStringChunk plus 12.6% inside QUtf8::isValidUtf8]
>
> So it's just under 4x slower, but we're still talking about consuming over
> 250 MB/s of data.
>
> PS: YMMV, especially if you don't use CPU-optimised UTF-8 methods like I do.
> You need to compile your own Qt to get those.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Faster QXmlStreamWriter?

[Konstantin Tokarev]

25.04.2018, 09:43, "Thiago Macieira" :
> So Qt 6 QJsonDocument & family will have the 128 MB limit
> removed, at the expense of the binary JSON format requiring parsing.

That's sad, as we lose the single solution inside Qt for serialization without
parsing

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] Faster QXmlStreamWriter?

[Konstantin Tokarev]

24.04.2018, 11:40, "Vadim Peretokin" :
> On Tue, Apr 24, 2018 at 8:14 AM Thiago Macieira  
> wrote:
>> On Monday, 23 April 2018 22:02:20 PDT Vadim Peretokin wrote:
>>> > Correct, QBuffer is not optimised for speed. I ran into that while
>>> > developing
>>> > QCborStreamWriter. The solution was to bypass it for speed.
>>>
>>> OK, that's a pity. I'll look into using pugixml instead, and if anyone else
>>> knows a faster XML serializer, I'd he happy to hear about it.
>>
>> Any chance you can choose a different serialisation format?
>
> We're thinking on the consequences of that - if pugixml isn't fast enough 
> still, will look at a different format. Recommendations welcome! :)

If your serialized data is intended to be read by Qt applications only, 
QDataStream may be a good choice

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


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

Re: [Interest] QtCreator oddity

[Konstantin Tokarev]

20.04.2018, 16:01, "Roland Hughes" :
> On 04/20/2018 07:55 AM, Konstantin Tokarev wrote:
>>  20.04.2018, 15:19, "Roland Hughes" :
>>>  On 04/20/2018 06:40 AM, Thiago Macieira wrote:
>>>>  On Wednesday, 18 April 2018 10:18:05 PDT Konstantin Tokarev wrote:
>>>>>  #include 
>>>>  DO NOT write that. The correct line for libusb is: #include  If 
>>>> that file is not in your default search path, then add it to INCLUDEPATH 
>>>> or via pkg-config. PKGCONFIG += libusb-1.0
>>>  The problem isn't the default search path. The problem is QtCreator cannot 
>>> handle directories with a "." in their name underneath /usr/include. One 
>>> has to force it in with
>>>
>>>  INCLUDEPATH +=/usr/include/libusb-1.0
>>  There is no force here. You cannot #include  unless compiler is 
>> provided with -I/usr/include/libusb-1.0 option instructing it to look in 
>> this directory.
>>
>>>  By default, everything under /usr/include should be found and, if the 
>>> directory doesn't have a . in the name it is.
>>>
>>>  -- Roland Hughes, President Logikal Solutions (630)-205-1593 
>>> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
>>> http://www.johnsmith-book.com http://www.logikalblog.com 
>>> http://www.interestingauthors.com/blog http://lesedi.us/ 
>>> http://onedollarcontentstore.com
>>>  ,
>
> Yes, there is a force here. Having to inform the environment about a
> directory underneath /usr/include is a force. By design all directories
> in that tree are searched.

Your understanding is wrong. Please read documentation of your compiler more 
carefully.

>
> This is a bug.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us/
> http://onedollarcontentstore.com

-- 
Regards,
Konstantin

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

Re: [Interest] QtCreator oddity

[Konstantin Tokarev]

20.04.2018, 15:19, "Roland Hughes" :
> On 04/20/2018 06:40 AM, Thiago Macieira wrote:
>> On Wednesday, 18 April 2018 10:18:05 PDT Konstantin Tokarev wrote:
>>> #include 
>>
>> DO NOT write that. The correct line for libusb is: #include  If 
>> that file is not in your default search path, then add it to INCLUDEPATH or 
>> via pkg-config. PKGCONFIG += libusb-1.0
> The problem isn't the default search path. The problem is QtCreator cannot 
> handle directories with a "." in their name underneath /usr/include. One has 
> to force it in with
>
> INCLUDEPATH +=/usr/include/libusb-1.0

There is no force here. You cannot #include  unless compiler is 
provided with -I/usr/include/libusb-1.0 option instructing it to look in this 
directory.

>
> By default, everything under /usr/include should be found and, if the 
> directory doesn't have a . in the name it is.
>
> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
> http://www.johnsmith-book.com http://www.logikalblog.com 
> http://www.interestingauthors.com/blog http://lesedi.us/ 
> http://onedollarcontentstore.com
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Regards,
Konstantin

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

Re: [Interest] QtCreator oddity

[Konstantin Tokarev]

18.04.2018, 20:03, "Roland Hughes" :
> On 04/18/2018 11:52 AM, Konstantin Tokarev wrote:
>> 18.04.2018, 19:43, "Roland Hughes" :
>>> All, KDE Neon all updates applied. QtCreator 4.4.1  Qt 5.9.3 from repos. 
>>> Also installed libusb packages from repos. 
>>> roland@roland-I5-HP-Compaq-8300-Elite-SFF-PC:~$ ls /usr/include/libusb-1.0/ 
>>> libusb.h When typing in the editor and compiling, libusb.h is not found. 
>>> Other headers from other directories in /usr/include are found, but not 
>>> libusb.h. If I force QtCreator to look at it via INCLUDEPATH 
>>> +=/usr/include/libusb-1.0 in the .pro file, all is well. I assume there is 
>>> a bug when it comes to directories with "." in the name. Just passing this 
>>> along.
>>
>> This is expected behavior. Unlike /usr/include, /usr/include/libusb-1.0 is 
>> not in default search path of compiler, so you have to add it explicitly
> I would buy that argument if postgresql and all of the other directories 
> under /usr/include didn't work just fine. Either their packages add an entry 
> where the compiler suddenly knows about them _or_ the directory tree under 
> /usr/include is "walked."

Indeed, it seems like "libusb-1.0" entry is missing from autocomplete list when 
one starts typing

#include 

Feel free to create a bug report on this

>
> To test this theory I did the following:
> removed INCLUDEPATH from .pro file and saved
> cd /usr/include
> dir aa
> sudo mkdir aa
> sudo cp libusb-1.0/*.h aa
>
> Now typing
>
> #include 
> brings up the aa/ completion entry and libusb.h is found under it.
>
> This is a manually entered directory. To further test I did the following
>
> sudo mkdir a.a
> sudo cp libusb-1.0/*.h a.a
> dir
> roland@roland-I5-HP-Compaq-8300-Elite-SFF-PC:/usr/include$ dir a.a
> libusb.h
>
> typing #include  not found.
>
> There appears to be a problem walking the directory tree when a directory 
> name includes the "."
>
> Roland
>
> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
> http://www.johnsmith-book.com http://www.logikalblog.com 
> http://www.interestingauthors.com/blog http://lesedi.us/ 
> http://onedollarcontentstore.com


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

Re: [Interest] QtCreator oddity

[Konstantin Tokarev]

18.04.2018, 19:43, "Roland Hughes" :
> All,
>
> KDE Neon all updates applied. QtCreator 4.4.1  Qt 5.9.3 from repos. Also 
> installed libusb packages from repos.
>
> roland@roland-I5-HP-Compaq-8300-Elite-SFF-PC:~$ ls /usr/include/libusb-1.0/
>
> libusb.h
>
> When typing in the editor and compiling, libusb.h is not found. Other headers 
> from other directories in /usr/include are found, but not libusb.h. If I 
> force QtCreator to look at it via
>
> INCLUDEPATH +=/usr/include/libusb-1.0
>
> in the .pro file, all is well. I assume there is a bug when it comes to 
> directories with "." in the name. Just passing this along.

This is expected behavior. Unlike /usr/include, /usr/include/libusb-1.0 is not 
in default search path of compiler, so you have to add it explicitly

>
> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
> http://www.johnsmith-book.com http://www.logikalblog.com 
> http://www.interestingauthors.com/blog http://lesedi.us/ 
> http://onedollarcontentstore.com
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] How do I get the most robust version of 5.10

[Konstantin Tokarev]

12.04.2018, 20:34, "william.croc...@analog.com" :
>>>  So, are you saying that the 5.10 branch has been abandoned.
>>
>>  No, it's been *closed*. There's a difference.
>
> If it is closed then I assume issues will not be fixed.
> I call that abandoned.
>
>>>  If so, I do not think the web site should offer it as a download candidate.
>>
>>  Huh, why? What's the rationale for this?
>
> For me I saw it in a distinguished position (tip of the next-to-last branch)
> and yet it had known issues which were not fixed nor would, apparently, ever 
> be
> fixed.
>
>>>  I saw that 5.11 was on the tip and, therefore, assumed that
>>>  the latest 5.10 was good and stable.
>>
>>  It is.
>
> If I may raise my voice for a moment...
>
> No. It (5.10.1) is NOT good.
>
> It immediately failed one of my regression tests.
> You should have known there was an issue because I here it has been fixed in 
> 5.11

In a software project of size and scope of Qt, it would be simply impossible to 
produce
a release without any known issue in a finite amount of time.

And discovery of bugs in release is not a reason to revoke it, unless it is 
important
security issue or fatal regression that affect every user.

>
> Fortunately I did not spend too much time blaming my code.
> I submitted a bug report and was offered 3 patches which fixed the problem.
>
> I think leaving that prominent, dangling version with known
> issues is irresponsible.
>
> Fix 5.10.1 (and make a 5.10.2) or take it away.
>
> Back to calm voice...
>
> Thanks.
>
> Bill
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] How do I get the most robust version of 5.10

[Konstantin Tokarev]

12.04.2018, 20:47, "Thiago Macieira" :
> On Thursday, 12 April 2018 10:34:18 PDT william.croc...@analog.com wrote:
>>  >> So, are you saying that the 5.10 branch has been abandoned.
>>  >
>>  > No, it's been *closed*. There's a difference.
>>
>>  If it is closed then I assume issues will not be fixed.
>>  I call that abandoned.
>
> A closed branch is one we're not applying fixes to. We're applying fixes to
> next releases, though.
>
>>  >> If so, I do not think the web site should offer it as a download
>>  >> candidate.
>>  >
>>  > Huh, why? What's the rationale for this?
>>
>>  For me I saw it in a distinguished position (tip of the next-to-last branch)
>>  and yet it had known issues which were not fixed nor would, apparently,
>>  ever be fixed.
>
> Those issues will be fixed in the next release. That just happens to be
> 5.11.0.
>
>>  >> I saw that 5.11 was on the tip and, therefore, assumed that
>>  >> the latest 5.10 was good and stable.
>>  >
>>  > It is.
>>
>>  If I may raise my voice for a moment...
>>
>>  No. It (5.10.1) is NOT good.
>>
>>  It immediately failed one of my regression tests.
>>  You should have known there was an issue because I here it has been fixed in
>>  5.11
>
> Of course there are problems. Do you want us to delete every old release
> because we've fixed bugs? We already have fixes for bugs post 5.9.5, which was
> released today. Should we delete it too?
>
> Bugs will be fixed in the next release.
>
>>  Fortunately I did not spend too much time blaming my code.
>>  I submitted a bug report and was offered 3 patches which fixed the problem.
>>
>>  I think leaving that prominent, dangling version with known
>>  issues is irresponsible.
>
> Ok, we'll delete all releases. Please build only from Git, from the dev
> branch. It's the only one that has all fixes.

* only in moments shortly after all merges are done

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] How to make the QString "10" behind "9" in QMap's key order

[Konstantin Tokarev]

09.04.2018, 20:53, "Roland Hughes" :
> Which isn't really a Qt answer.
>
> Long ago, before Nokia, there was the mantra/design principal that Qt would 
> always be compatible with the standard stuff. A subset of means "compatible" 
> is written with barely readable faint gray ink.

Times has changed, and since Qt 5 standard library is a requirement for Qt, and 
parts that duplicate standard library (or core language) are on their way to 
deprecation. See e.g. QtAlgorithms or Q_FOREACH.

>
> Just my 0.2. I can only remember twice on projects where the inability to 
> set the sort for a QMap hurt me. It hurt bad both times so I remember the 
> hurt, but not what caused it.
>
> On 04/09/2018 12:46 PM, Konstantin Tokarev wrote:
>> 09.04.2018, 20:44, "Roland Hughes" :
>>> On 01/08/2018 06:26 AM, Mark Gaiser wrote:
>>>> You might want to look into std::map[1] as well. It allows setting a 
>>>> compare function, QMap doesn't. Going that route is most likely more 
>>>> efficient as your inserts will be sorted, no need to do std::sort 
>>>> afterwards.
>>>
>>> Jumping into this one late, but, is there any particular reason QMap 
>>> doesn't allow overriding or supplying a comparison method? Has a feature 
>>> request already been filed.
>>
>> Because there is std::map
>>> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
>>> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
>>> http://www.johnsmith-book.com http://www.logikalblog.com 
>>> http://www.interestingauthors.com/blog http://lesedi.us/ 
>>> http://onedollarcontentstore.com , 
>>> ___ Interest mailing list 
>>> Interest@qt-project.org 
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>> --  Regards, Konstantin
>
> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
> http://www.johnsmith-book.com http://www.logikalblog.com 
> http://www.interestingauthors.com/blog http://lesedi.us/ 
> http://onedollarcontentstore.com


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

Re: [Interest] How to make the QString "10" behind "9" in QMap's key order

[Konstantin Tokarev]

09.04.2018, 20:44, "Roland Hughes" :
> On 01/08/2018 06:26 AM, Mark Gaiser wrote:
>> You might want to look into std::map[1] as well. It allows setting a compare 
>> function, QMap doesn't. Going that route is most likely more efficient as 
>> your inserts will be sorted, no need to do std::sort afterwards.
>
> Jumping into this one late, but, is there any particular reason QMap doesn't 
> allow overriding or supplying a comparison method? Has a feature request 
> already been filed.

Because there is std::map

>
> -- Roland Hughes, President Logikal Solutions (630)-205-1593 
> http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net 
> http://www.johnsmith-book.com http://www.logikalblog.com 
> http://www.interestingauthors.com/blog http://lesedi.us/ 
> http://onedollarcontentstore.com
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] Deploying open-source Qt-based applications to the AppStore

[Konstantin Tokarev]

29.03.2018, 15:55, "Jaime Robles" :
> How dowe appstore violate lgpl?
>
> You can publish binaries and your sources in wherever you want... that would 
> fulfil licenses...
> I am wrong?

AppStore terms add restrictions on what user can do with software, which gets 
in conflict with
rights mandated by (L)GPL, and ability to get source code is not the only such 
right.

See https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

>
>> AFAIK, Apple was never banned (L)GPL code from AppStore without request from
>> copyright holders of that code. Copyright holders of Qt might want do this, 
>> as
>> AppStore rules violate LGPL.


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

Re: [Interest] Deploying open-source Qt-based applications to the AppStore

[Konstantin Tokarev]

29.03.2018, 14:41, "Nikos Chantziaras" :
> On 29/03/18 14:22, Corentin Jabot wrote:
>>  I'm currently working on a Qt-based application that is fully
>>  open-source (LGPL, though we are considering re-licensing to MIT/BSD)
>>  and using the open-source Qt version.
>>
>>  We are contemplating working on an iOS version with the goal to deploy
>>  it on the AppStore.
>>
>>  In this scenario, can we use the GPL version of Qt, or do we absolutely
>>  need a commercial license ?
>>
>>  Thanks !
>
> Since your app is open-source and LGPL compatible, you can use the LGPL
> version of Qt. However, note that there might be other issues with the
> AppStore and GNU licenses. From the FSF:
>
> https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement
>
> There have been cases where (L)GPL-licensed software was banned from the
> AppStore by Apple. On the other hand, other GPL apps are still there. I
> do not know if this is because they're keeping a low profile to avoid
> Apple noticing them, or they're allowed to stay.

AFAIK, Apple was never banned (L)GPL code from AppStore without request from
copyright holders of that code. Copyright holders of Qt might want do this, as
AppStore rules violate LGPL.

>
> In any event, there seems to be some sort of issue, and you probably
> would need to seek advice on this. Even if you license your app under
> MIT or BSD, the Qt you ship would still be LGPL and thus the AppStore
> issue could still be there.
>
> (For what it's worth, if it was me, I would just publish the app and
> assume Apple is not going to do anything, but note that THIS IS NOT
> LEGAL ADVICE.)
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] About Qt and WebEngine/Chromium

[Konstantin Tokarev]

16.03.2018, 15:52, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  Whom would we share it with?
>
> In that vision I had the question was more "whom would Chromium share itself
> with" :)

* WebEngine needs patched Chromium source
* Chromium can be updated at any time and break Qt

>
> In theory you could be sharing "it" with any other application built on 
> Chromium
> but not Qt. A concrete example would be on mobile devices with their limited
> resources.

WebView module allows using platform browser engine

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

-- 
Regards,
Konstantin

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

Re: [Interest] Retrieving the object info due to exception std::bad_alloc

[Konstantin Tokarev]

01.03.2018, 20:35, "Ramakanth Kesireddy" :
> When system runs on low memory, the object allocations through new in the Qt 
> application does throw bad_alloc exception,right?

It may or may not throw exception, depending on OS kind, overcommit settings,
memory limits set for your application, and your luck.

>
> On Thursday, March 1, 2018, Thiago Macieira  wrote:
>> On Wednesday, 28 February 2018 15:23:22 PST Konstantin Tokarev wrote:
>>> bad_alloc is mostly thrown due to too view memory for the request in
>>> question.
>>> > so when you continue your program, chances are good to see more
>>> > bad_allocs.
>>>
>>> Or don't get any bad_alloc at all, being killed by OOM Killer promptly
>>
>> You get bad_alloc when you make silly requests, like negative sizes or
>> petabytes.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

Re: [Interest] Retrieving the object info due to exception std::bad_alloc

[Konstantin Tokarev]

28.02.2018, 09:51, "alexander golks" :
> Am Tue, 27 Feb 2018 23:12:51 +0530
> schrieb Ramakanth Kesireddy :
>
>>  Hi,
>>
>>  As mentioned in http://doc.qt.io/archives/qt-4.8/exceptionsafety.html, the
>>  below code is being used to catch the exceptions in application:-
>>
>>  QApplication app(argc, argv);
>>  ...
>>  try {
>>  app.exec();
>>  } catch (const std::bad_alloc &) {
>>  //clean up code and log the exception info
>>  // retrieve class name and method name of object
>>  return 0; // exit the application
>>  }
>>
>>  Please let me know if there any means to get the runtime object info like
>>  class name, method name(if possible line number) throwing the exception
>>  std::bad_alloc in catch block?
>
> beside your origin question:
> bad_alloc is mostly thrown due to too view memory for the request in question.
> so when you continue your program, chances are good to see more bad_allocs.

Or don't get any bad_alloc at all, being killed by OOM Killer promptly

>
> to your question:
> you may try stacktracers, like mentioned here: 
> https://stackoverflow.com/a/691742
>
> alex
>
> --
> /*
>  *No violence, gentlemen -- no violence, I beg of you! Consider the furniture!
>  * -- Sherlock Holmes
>  */
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] How to debug QNetworkReply? It never finishes!

[Konstantin Tokarev]

27.02.2018, 18:39, "coroberti ." :
> Hi Tomek,
> It was a similar case in my setup.
>
> It appeared, though, that I was 2 connections and deleting the first
> conn before getting reply.
>
> If you are using the same connection, check that your server supports
> pipe-lining.
> You need somehow to manage QNetworkReply/s - perhaps 2 different objects.

Pipelining may be used only when QNetworkRequest::HttpPipeliningAllowedAttribute
is set to true

>
> Kind regards,
> Robert
>
> On Tue, Feb 27, 2018 at 10:44 AM, Tomasz Olszak  
> wrote:
>>  Hello,
>>
>>  I faced strange issue.Probably important information"
>>  1. I send 2 GET request in short delay between them (a few ms). Request have
>>  the same URL (including GET variables). They are connecting to remote HTTPS
>>  nginx server
>>  2. I save both replies from QNAM in internal cache and when the latter reply
>>  is finished I print information about first one. First one is running, not
>>  finished, no error. There is no signal emitted from first reply (like
>>  encrypted, metadataChanged etc), those signal are emitted from second reply
>>  though.
>>
>>  Anyone has an idea what could happen and how to debug it?
>>
>>  Thanks in Advance,
>>  Tomek
>>
>>  ___
>>  Interest mailing list
>>  Interest@qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] How to solve ICU conflict? Qt ICU conflicts with Matlab ICU

[Konstantin Tokarev]

20.02.2018, 14:14, "Vincent Hui" :
> Hi,
>
> I am trying to use MATLAB Engine API for C++ and Qt together on Ubuntu 16.04. 
> Both of Matlab and Qt ship ICU library.
>
> I got an run-time error just after I execute my program.
>
> "/opt/MATLAB/R2017b/bin/glnxa64/libicuio.so.56: undefined symbol: 
> _ZN6icu_5613UnicodeString8doAppendEPKDsii"
>
> How to solve it?

Build Qt with ICU 56



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

Re: [Interest] What is the minimum version of Mac OS X Qt 5.10 application will run on?

[Konstantin Tokarev]

19.02.2018, 20:10, "Nuno Santos" :
> Curiously, 10.10 is not listed under support platforms.
>
>>  On 19 Feb 2018, at 17:08, Michael Corcoran  wrote:
>>
>>  On Mon, 2018-02-19 at 14:39 +, Nuno Santos wrote:
>>>  Alexandru,
>>>
>>>  Thanks for your feedback and prompt reply.
>>>
>>>  I got my answer!
>>>
>>>  Best regards,
>>>
>>>  Nuno
>>
>>  It's also worth noting the list of "supported platforms": http://doc.qt
>>  .io/qt-5/supported-platforms.html

See https://wiki.qt.io/Qt_5.10_Tools_and_Versions#OSX_10.10

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

-- 
Regards,
Konstantin

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

Re: [Interest] iOS libpng conflicts with another lib

[Konstantin Tokarev]

07.02.2018, 16:25, "maitai" :
> Yes I know, but if I use jpeg2000 i will have another conflict for sure
> since I do use jpeg2000 lib (and jasper) to decode gribs in my app.

Apple's decoder should not conflict with jasper. However, I would not
recommend to use jasper for anything, it's obsolete and very incomplete
implementation (IIRC it support no extensions from part 2)

 I
> agree Webp is another possibility, since it is also supported by gdal, I
> might gice it a try, thanks.
>
> Le 07-02-2018 13:56, Konstantin Tokarev a écrit :
>>  07.02.2018, 15:46, "maitai" :
>>>  Thanks Konstantin for the good advices, I'll keep that in mind if
>>>  finally I decide to give it a try. For the time being I managed to
>>>  cheat
>>>  by using a tif instead of a png, just for iOS.
>>
>>  That's not the best format. Try jpeg2k or webp instead (plugins "webp"
>>  and "macjp2" in qtimageformats module)
>>
>>>  Thanks again
>>>  Philippe.
>>>
>>>  Le 07-02-2018 13:12, Konstantin Tokarev a écrit :
>>>>   07.02.2018, 09:44, "maitai" :
>>>>>   Thanks you for your replies
>>>>>
>>>>>   I will decide to compile qt on iOS when I will be retired and
>>>>>  nothing
>>>>>   else to do, too much a pain with lipo and all ;)
>>>>
>>>>   lipo is not hard to use at all, however there should be no need to
>>>>  use
>>>>   it when building Qt.
>>>>
>>>>   Fo example, configure line [1] initiates build for 4 architectures
>>>>   (-arch armv7 -arch arm64 -arch i386 -arch x86_64)
>>>>
>>>>   See build log [2] for example (this is build configuration used for
>>>>   official
>>>>   iOS packages).
>>>>
>>>>   All you need to change is to add -I and -L options to configure to
>>>>   specify
>>>>   location of libpng headers and library. Make sure that configure
>>>>   summary
>>>>   states "Using system libpng  yes".
>>>>
>>>>   [1] configure -xplatform macx-ios-clang -no-sql-mysql -no-sql-psql
>>>>   -plugin-sql-sqlite -opensource -confirm-license -nomake tests
>>>>  -verbose
>>>>   -prefix /Users/qt/work/install -debug-and-release -static -no-icu
>>>>   -nomake examples
>>>>
>>>>   [2]
>>>>   
>>>> https://testresults.qt.io/coin/api/results/qt/qtbase/1860a91eeb370b10677cb1813752739361011015/MacOSMacOS_10_12x86_64IOSIOS_ANYmultiClangqtci-macos-10.12-x86_64-8-9dffb3DebugAndRelease_DisableTests_Static/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/build_1517672826/log.txt.gz
>>>
>>>  ___
>>>  Interest mailing list
>>>  Interest@qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] iOS libpng conflicts with another lib

[Konstantin Tokarev]

07.02.2018, 15:46, "maitai" :
> Thanks Konstantin for the good advices, I'll keep that in mind if
> finally I decide to give it a try. For the time being I managed to cheat
> by using a tif instead of a png, just for iOS.

That's not the best format. Try jpeg2k or webp instead (plugins "webp"
and "macjp2" in qtimageformats module)

>
> Thanks again
> Philippe.
>
> Le 07-02-2018 13:12, Konstantin Tokarev a écrit :
>>  07.02.2018, 09:44, "maitai" :
>>>  Thanks you for your replies
>>>
>>>  I will decide to compile qt on iOS when I will be retired and nothing
>>>  else to do, too much a pain with lipo and all ;)
>>
>>  lipo is not hard to use at all, however there should be no need to use
>>  it when building Qt.
>>
>>  Fo example, configure line [1] initiates build for 4 architectures
>>  (-arch armv7 -arch arm64 -arch i386 -arch x86_64)
>>
>>  See build log [2] for example (this is build configuration used for
>>  official
>>  iOS packages).
>>
>>  All you need to change is to add -I and -L options to configure to
>>  specify
>>  location of libpng headers and library. Make sure that configure
>>  summary
>>  states "Using system libpng  yes".
>>
>>  [1] configure -xplatform macx-ios-clang -no-sql-mysql -no-sql-psql
>>  -plugin-sql-sqlite -opensource -confirm-license -nomake tests -verbose
>>  -prefix /Users/qt/work/install -debug-and-release -static -no-icu
>>  -nomake examples
>>
>>  [2]
>>  
>> https://testresults.qt.io/coin/api/results/qt/qtbase/1860a91eeb370b10677cb1813752739361011015/MacOSMacOS_10_12x86_64IOSIOS_ANYmultiClangqtci-macos-10.12-x86_64-8-9dffb3DebugAndRelease_DisableTests_Static/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/build_1517672826/log.txt.gz
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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

Re: [Interest] iOS libpng conflicts with another lib

[Konstantin Tokarev]

07.02.2018, 09:44, "maitai" :
> Thanks you for your replies
>
> I will decide to compile qt on iOS when I will be retired and nothing
> else to do, too much a pain with lipo and all ;)

lipo is not hard to use at all, however there should be no need to use
it when building Qt.

Fo example, configure line [1] initiates build for 4 architectures
(-arch armv7  -arch arm64  -arch i386  -arch x86_64)

See build log [2] for example (this is build configuration used for official
iOS packages).

All you need to change is to add -I and -L options to configure to specify
location of libpng headers and library. Make sure that configure summary
states "Using system libpng  yes".
 

[1] configure -xplatform macx-ios-clang -no-sql-mysql -no-sql-psql 
-plugin-sql-sqlite -opensource -confirm-license -nomake tests -verbose -prefix 
/Users/qt/work/install -debug-and-release -static -no-icu -nomake examples

[2] 
https://testresults.qt.io/coin/api/results/qt/qtbase/1860a91eeb370b10677cb1813752739361011015/MacOSMacOS_10_12x86_64IOSIOS_ANYmultiClangqtci-macos-10.12-x86_64-8-9dffb3DebugAndRelease_DisableTests_Static/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/build_1517672826/log.txt.gz


-- 
Regards,
Konstantin

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

Re: [Interest] iOS libpng conflicts with another lib

[Konstantin Tokarev]

06.02.2018, 13:28, "maitai" :
> Hello,
>
> I have an external lib build statically into my qt app (5.9.4,
> widget-based). That lib can optionally support internally png images. If
> I activate this, there is no problems in other platforms (I tested
> Android, Windows, Linux, Raspberry, MacOS), but on iOS as soon as I try
> to open a png image with a QPixmap or a QImage it crashes. If I compile
> my external lib without png support no more crash.
>
> So it appears that libpng from Qt and the one from my lib are
> conflicting, but only on iOS.
>
> Any idea why this occurs on iOS and what I could do to avoid the crash?
> I badly need png support in both qt and the external lib.

Also, make sure that when you build your lib it uses headers from the same
copy of libpng that it links to. (At least with cmake it's quite easy to get 
into
such situation)

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

-- 
Regards,
Konstantin

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

Re: [Interest] iOS libpng conflicts with another lib

[Konstantin Tokarev]

06.02.2018, 22:26, "Thiago Macieira" :
> On Tuesday, 6 February 2018 02:41:39 PST Konstantin Tokarev wrote:
>>  > Any idea why this occurs on iOS and what I could do to avoid the crash?
>>
>>  Build both Qt and that library against same libpng
>
> Preferably a system-wide one, if such a thing exists on iOS.

At least on macOS it doesn't (so official Qt binaries use bundled version)

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin

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