Re: [Interest] Battery status and info

[Jason H]

No. I had to write my own JNI api. Curiously, for iOS, the ideviceinfo binary can give you more than the device itself.
 

Sent: Wednesday, July 10, 2019 at 9:45 AM
From: "Jérôme Godbout" 
To: "Interest@qt-project.org" 
Subject: [Interest] Battery status and info




Hi,

Is there any Qt API (I did found some into the old QtMobile) that can be used to probe the main battery on the system (I want to target iOS, Android, OS X, Window and Linux). I was wondering if any Qt API exist to monitor the charge level, the current, voltage, capacity, health, etc. I think I won’t get everything on all platform (yes I’m looking at you iOS lol). If anybody have a lead on this it would be welcome.

 

Thanks,

Jerome

 

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




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

Re: [Interest] X11->XQuartz compatability?

[Jason H]

Tries, that, output changed slightly:
function is no-op
Unrecognized OpenGL version
Unrecognized OpenGL version
function is no-op
QGLXContext: Failed to create dummy context
function is no-op
Unrecognized OpenGL version
Unrecognized OpenGL version
function is no-op
failed to acquire GL context to resolve capabilities, using defaults..

Also for glxgears:
$ glxgears
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  21
  Current serial number in output stream:  23


> Sent: Friday, June 28, 2019 at 10:42 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] X11->XQuartz compatability?
>
> On Friday, 28 June 2019 08:25:12 PDT Jason H wrote:
> > I looked into this, but cannot find out how to "use llmvpipe"? I've been
> > staring at https://www.mesa3d.org/llvmpipe.html and poking around, I don't
> > see instructions on where to get it, or how to build it? it just kind of
> > assumes the reader already has it?
>
> You already have it.
>
> Try setting LIBGL_ALWAYS_SOFTWARE=1 and GALLIUM_DRIVER=llvmpipe.
>
> See https://www.mesa3d.org/envvars.html
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] X11->XQuartz compatability?

[Jason H]

I looked into this, but cannot find out how to "use llmvpipe"? I've been 
staring at https://www.mesa3d.org/llvmpipe.html and poking around, I don't see 
instructions on where to get it, or how to build it?
it just kind of assumes the reader already has it?

Many thanks

> Sent: Friday, June 14, 2019 at 10:50 AM
> From: "Konstantin Tokarev" 
> To: "Jason H" , "interestqt-project.org" 
> 
> Subject: Re: [Interest] X11->XQuartz compatability?
>
>
>
> 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] QEventLoop ::hasPendingEvents() replacement?

[Jason H]

Can't you use a QRunnable / QThreadPool with maxThreadCount=1?


> Sent: Wednesday, June 26, 2019 at 1:58 AM
> From: "Fabrice Mousset | GEOCEPT GmbH" 
> To: "Thiago Macieira" , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] QEventLoop ::hasPendingEvents() replacement?
>
> Hi Thiago,
> 
> thank's a lot for you answer and for your explanation.
> Sadly for me, replacing with true/false is not an alternative for my use case.
> I will have to rework the whole process.
> I have a worker class (with his own thread), and before allowing a new task 
> to be started I have to be sure previous task has been finished.
> Depending on the type of task there are more or less slots which are 
> triggered and depending on the parameter each slots could also trigger 
> another slots.
> hasPendingEvents() was a very attractive solution for my use case, too bad 
> for me!
> 
> Fabrice Mousset
> 
> > -Ursprüngliche Nachricht-
> > Von: Interest  Im Auftrag von Thiago
> > Macieira
> > Gesendet: Dienstag, 25. Juni 2019 18:09
> > An: interest@qt-project.org
> > Betreff: Re: [Interest] QEventLoop ::hasPendingEvents() replacement?
> > 
> > On Tuesday, 25 June 2019 08:00:02 PDT Fabrice Mousset | GEOCEPT GmbH
> > wrote:
> > > Hi all,
> > >
> > > Since Qt 5.3 QAbstractEventDispatcher::hasPendingEvents() has been set
> > > "obsolete". Is there an alternate way to know if a QEventLoop has
> > > pending events?
> > 
> > The reason it's obsolete is that it's a race condition. Since the race 
> > can't be
> > fixed, there will be no replacement.
> > 
> > I suggest you replace the call with "true" or "false", depending on how your
> > code around it would react to an event being posted by another thread at
> > just the wrong moment.
> > 
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel System Software Products
> > 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Problem with cv::Mat grayscale to QImage

[Jason H]

It seems that there is some word/dword/byte-alignment magic going on and the skew is proportional to that. 
 

Sent: Friday, June 21, 2019 at 9:40 AM
From: "Jason H" 
To: "René Hansen" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage




That indeed seems to be the case. But this is very interesting for Grayscale. RGB888 is fine. Maybe this is more a OpenCV question, why would the BPL not equal pixels per line?

 

Many thanks to all who replied.

 

Sent: Thursday, June 20, 2019 at 5:33 PM
From: "René Hansen" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage


You might need to set the bytesPerLine of the QImage to match the step of cv::Mat. I seem to recall having a similar issue once, converting between a four and three bytes per pixel formats, e.g. if the cv::Mat is in CV_8UC4.
 

 

/René

 


On Thu, 20 Jun 2019 at 23:05, Jason H <jh...@gmx.com> wrote:

Simple code:

cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
cv::imwrite("dummy_gray_cv.png", left_image); // ok
QImage test((unsigned char*) left_image.data, left_image.cols, left_image.rows, QImage::Format_Grayscale8);
test.save("dummy_gray_qt.png"); // skewed


However the dummy_gray_qt.png image is not aligned correctly, it's skewed as if bytes are missing/being skipped.

I have to convert it back to color to work:
cv::Mat dst;
cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows, QImage::Format_RGB32);
result.save("dummy_color_qt.png")

Is there a way I can avoid needing cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA)?

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

 

 
--

Never fear, Linux is here.





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



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

Re: [Interest] Problem with cv::Mat grayscale to QImage

[Jason H]

That indeed seems to be the case. But this is very interesting for Grayscale. RGB888 is fine. Maybe this is more a OpenCV question, why would the BPL not equal pixels per line?

 

Many thanks to all who replied.

 

Sent: Thursday, June 20, 2019 at 5:33 PM
From: "René Hansen" 
To: "Jason H" 
Cc: "interestqt-project.org" 
Subject: Re: [Interest] Problem with cv::Mat grayscale to QImage


You might need to set the bytesPerLine of the QImage to match the step of cv::Mat. I seem to recall having a similar issue once, converting between a four and three bytes per pixel formats, e.g. if the cv::Mat is in CV_8UC4.
 

 

/René

 


On Thu, 20 Jun 2019 at 23:05, Jason H <jh...@gmx.com> wrote:

Simple code:

cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
cv::imwrite("dummy_gray_cv.png", left_image); // ok
QImage test((unsigned char*) left_image.data, left_image.cols, left_image.rows, QImage::Format_Grayscale8);
test.save("dummy_gray_qt.png"); // skewed


However the dummy_gray_qt.png image is not aligned correctly, it's skewed as if bytes are missing/being skipped.

I have to convert it back to color to work:
cv::Mat dst;
cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows, QImage::Format_RGB32);
result.save("dummy_color_qt.png")

Is there a way I can avoid needing cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA)?

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

 

 
--

Never fear, Linux is here.




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

[Interest] Problem with cv::Mat grayscale to QImage

[Jason H]

Simple code:

cv::Mat left_image = cv::imread(filename, cv::IMREAD_COLOR );
cv::cvtColor(mat, mat, cv::COLOR_BGR2GRAY);
cv::imwrite("dummy_gray_cv.png", left_image); // ok
QImage test((unsigned char*) left_image.data, left_image.cols, left_image.rows, 
QImage::Format_Grayscale8);
test.save("dummy_gray_qt.png"); // skewed


However the dummy_gray_qt.png image is not aligned correctly, it's skewed as if 
bytes are missing/being skipped.

I have to convert it back to color to work:
cv::Mat dst;
cv::cvtColor(left_image, dst, cv::COLOR_GRAY2BGRA);
QImage result = QImage((unsigned char*) dst.data, dst.cols, dst.rows, 
QImage::Format_RGB32);
result.save("dummy_color_qt.png")

Is there a way I can avoid needing cv::cvtColor(left_image, dst, 
cv::COLOR_GRAY2BGRA)?

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

[Interest] X11->XQuartz compatability?

[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.

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

[Interest] Simple Starting PySide2 Questions

[Jason H]

In preparing to use PySide2, I have several questions. Please feel free to 
direct me to proper resources, if I missed them.
1. According to https://wiki.qt.io/Qt_for_Python#Frequently_Asked_Questions ,
 - Embedded is not supported, with Raspberry Pi specifically called out. Why 
are these platforms (especially the Pi) "not supported"?
 - What does this"not supported" scenario look like (i.e. it doesn't work at 
all on arm7, or is not guaranteed to work, etc?)

2. What is the best way to convert/use an image between QImage and what I get 
from Python's PIL imread()/numpy? (to avoid copy of 12M pix image) I am not 
sure  how relevant 
https://stackoverflow.com/questions/13302908/better-way-of-going-from-pil-to-pyside-qimage
 is.


3. What integration is there (if any) between Qt's even loop and Python's 
existing asyncio event loops and await support?
I found this: https://github.com/gmarull/asyncqt but all the indicators are 
fail.
https://github.com/harvimt/quamash looks better, and allegedly works with 
Python 3.7
I also found https://bugreports.qt.io/browse/PYSIDE-769, which seems to 
indicate that there is interest but no support yet.
The bigger question here is: I will undoubtedly have to integrate with existing 
code that uses asyncio, so what's my best way to do that.

I'm sure I'll have more as I dig in, but that's what I have for now. Many 
thanks in advance.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QFile/QDir: force move mode only?

[Jason H]

> Sent: Tuesday, May 14, 2019 at 10:15 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QFile/QDir: force move mode only?
>
> Hi,
>
> On 14/05/2019 15:47, Jason H wrote:
> > I'd rather static bool QFile::isAtomicRename(const QString , cont 
> > QString );
> > So that the software can plan accordingly. Blindly executing won't allow 
> > the software to accomodate non-atomic renames (i.e. Display an alternate 
> > UI). It would also be nice if there was an atomic-esque non-atomic rename, 
> > that would be a copy to the target FS and then atomic rename.
>
> Such a function would be inherently racy (the moment you have that
> information, the information is already outdated, as the filesystem may
> have changed). Suppose the function returns true, you then call
> QFile::rename() and may end up copying anyway.

Yes, all accesses to a shared resources beyond your control are inherently 
racy. Even if you logically can prove that the change will by all detectable 
means be possible, it doesn't mean it will actually happen. You really need to 
know if you can do it atomically, before attempting to do so, otherwise you 
have to fall back to a copy and atomic move. But to determine that you need to 
know what filesystems are mounted where, copy to the same fs as the destination 
then do the atomic rename. Can you still consider that atomic? I think you can 
hide a lot, but if the copy fails, the rename will necessarily fail, similarly 
if it all succeeds, it succeeds. At least there is an implication that atomic 
is fast,  but it isn't necessarily so.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QFile/QDir: force move mode only?

[Jason H]

I'd rather static bool QFile::isAtomicRename(const QString , cont 
QString );
So that the software can plan accordingly. Blindly executing won't allow the 
software to accomodate non-atomic renames (i.e. Display an alternate UI). It 
would also be nice if there was an atomic-esque non-atomic rename, that would 
be a copy to the target FS and then atomic rename.


> Sent: Monday, May 13, 2019 at 10:11 PM
> From: "d3fault" 
> To: interest@qt-project.org
> Subject: Re: [Interest] QFile/QDir: force move mode only?
>
> On 5/13/19, Bernhard Lindner  wrote:
> >> QFile::rename should rename always or fail! It should never do
> >> completely different operation - copy!
> >
> > I agree.
> >
>
> Adding a non-copying rename method to QFile/etc seems justified. Maybe
> call it: fastRename, tryRename, or atomicRename?
>
> d3fault
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Jason H]

Hi all,
I'm really sorry I brought this up. I have been working with smaller things 
thanks size_t.  I was wrong in the general case.

You can do a data structure of 16gB using the range of signed indexes for 
doubles. That should plenty.

I do still miss the python negative syntax though. [-1] and [-2] in particular. 
Though I done expect slices to be a thing? Maybe? Eventually?



> Sent: Friday, May 10, 2019 at 6:36 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On Friday, 10 May 2019 04:17:03 PDT Roland Hughes wrote:
> > > Data is different. std::byte is unsigned and "unsigned char" is the actual
> > > definition of byte. QByteArray should actually get an API to treat its
> > > contents as bytes, not just chars.
> > >
> > > But we weren't talking about data, we were talking about metadata: sizes,
> > > indices, offsets.
> >
> > I was talking about the devices needing the sizes sent in unsigned
> > octates. Sorry if there was any confusion. The static casts most often
> > occur here.
>
> Only if we're talking about sizes between 0 to 255. That's what a single
> unsigned octet can represent. Doesn't strike me as very useful.
>
> If you meant transmitting sizes as unsigned values over the network or medium,
> that's fine, since negative counts are physically meaningless. The bit pattern
> of any size in signed and unsigned is the same, so the choice between them is
> irrelevant. You may as well treat the protocol field as signed.
>
> > > Then you use a 64-bit signed integer for that. That's why Qt uses qint64
> > > for file sizes, regardless of architecture.
> [cut]
> > Or the size incoming and outgoing is required to be unsigned and it is
> > to/from a device where one does not control the firmware.
>
> Which, just like the above, you can treat as *signed* 64-bit, since your item
> count will not likely be more than 9223372036854775807. If it is, then you
> should use signed 128-bit, not unsigned 64-bit.
>
> I understand your argument that the other side may have specified that the
> field is unsigned. That's fine. But my argument is that all values between 0
> and 9223372036854775807 have the exact same bit pattern in both signed and
> unsigned 64-bit.
>
> However, I can now think of one particular case where unsigned math may be
> useful: dealing with untrusted data (and network definitely is untrusted).
> Until you confirm that all values are in the expected range, you should keep
> it unsigned.
>
> > We really really really need those things which cannot be negative to be
> > unsigned. I understand there is great resistance to this for reasons
> > which make no sense when viewed from the place of one who actually has
> > to interface with this stuff.
>
> No, we do not "really really" need that.
>
> Just because one field can't be negative does not mean that others can't. Take
> the example of a string / vector / bytearray size. As I said above, sizes
> cannot meaningfully be negative. But functions like indexOf() take an offset
> position that can be negative and the function can return a negative value
> indicating that the search failed. Using unsigned for size() is much more
> likely to cause you to need casts, for no appreciable gain since you cannot
> have more items in that vector or string than the maximum signed value.
>
> > As a compromise, every container should have a usize() method which
> > returns the value as an unsigned datatype. To make things even more
> > bullet proof it could be something like
> >
> > usize( bool * wasNegative = nullptr)
> >
> > ulength(bool * wasNegative = nullptr)
>
> Sorry, not convinced. This is as much an ugly band-aid as std::ssize()
> function.
>
> > Then we only have to jump through hoops for things like DICOM.
> >
> > https://www.dicomstandard.org/faq/
> >
> > 
> >
> > Following the (group number, data element number) pair is a length field
> > that is a 32 bit unsigned even integer that describes the number of
> > bytes from the end of the length field to the beginning of the next data
> > element.
> >
> > 
>
> This is fine, but since you can't operate on this much data on a 32-bit system
> without implementing windowed access through the data in your own code, I
> don't see as in impediment. You will code your application to deal with a
> possible 4 GB distance by seeking in the file -- and remember off_t is signed!
>
> If you only allow your application on 64-bit systems, then qsizetype can
> represent all 32-bit unsigned values without loss of information.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Jason H]

> Sent: Wednesday, May 08, 2019 at 8:09 PM
> From: "Henry Skoglund" 
> To: interest@qt-project.org
> Subject: [Interest] My first 5 years with Qt and 2 suggestions
>
> Hi, 5 years ago I started with Qt, it's been a very nice ride, thank 
> you! Looking forward to the next 5. Got 2 suggestions:
> 
> 
> 1) Make Qt more easily accessable for first timers:

"Skip" appears if there is no data, Qt will repopulate if appropriate data is 
found, this changes the default of "Skip" to "Login"

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

Windows invented the whole SXS scheme to deal with that. *shrug*

---

Anyway, if you want to make Qt more accessible ("accessible" is worth some 
words) Qt should make QML an open JS Framework for general web development, 
since JS is making inroads to local apps faster than anything else. At which 
point moving to Qt is just ditching Chrome or Webkit and bundling the Qt 
Scenegraph-based runtime, with the advantage of not being sandboxed and direct 
access to hardware (Though efforts are there to reduce this penalty on 
browsers.)

Now as for "accessible", we're dealing with developers who will have to 
know/learn C++, and the Qt Meta Object Compiler if they do any project of 
sufficient complexity, so I'm not sure a lack of a "Skip" button in the 
installer is going to turn people away. But I think there is a kernel of 
something there. For me, this would be that the Qt license has been the subject 
of FUD from the earliest days, continuing even up to today. Though I understand 
why this is, (Qt Company wants to make money) I don't like it, and I think it 
preemptively turns people away. I think the issue should have been settled when 
Qt got LGPL'd. However I admit I am not the one to know exactly where the 
balance point is between being profitable and popular. Additionally attempting 
to bundle services like qt.io cloud services rather than be cloud platform 
agnostics (cross-cloud platform) I think also limited Qt. It should be that the 
Amazon, Google, and and Azure clouds are interchangeable for cloud service 
providers.

I've griped about Qt's priorities in the past:
1. Automotive seems to be driving these days, driving 3D (which I will never 
use)
2. Mobile is a 3rd rate citizen whose Qt feature set lags behind much younger 
projects like ReactNative. This could have been a huge and easy win because 
this is a cross-platform scenario that Qt was ideal for and exploded in the 
past 10 years, so many potential new licensees, but Qt continues to lag. Qt is 
conceding ground to what I consider inferior toolkits.




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

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

[Jason H]

> Sent: Tuesday, May 07, 2019 at 9:31 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On 07/05/2019 14:42, Jason H wrote:
> >> Those will likely change to qsizetype in Qt 6. Which is still signed.
> >
> > This is disappointing. I'll only get half of the indexable space... can I 
> > get something in return? Having a negative index mechanism, like in Python, 
> > would be a way to alleviate some of the pain. Otherwise can you explain the 
> > rationale for not using signed?
>
> I guess you meant "not using unsigned" here?
>
>
> Half of the memory space is the theoretical maximum you get anyhow, no
> matter the signedness of the index, right?
>
> (You need to be able to take the pointer difference between any two
> positions in an array (including the one-past-the-end). Given that
> ptrdiff_t is the same size of a pointer, and has to be signed, that
> means that the biggest contiguous block of memory you can index is half
> of the address space. What am I not seeing?)

Ah, that's probably what I'm missing.

Given how often I miss indexing negatives (to index from the end) It seems that 
we could do this in Qt6?
/me ducks

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

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

[Jason H]

> Sent: Tuesday, May 07, 2019 at 8:44 AM
> From: "Christian Gagneraud" 
> To: "Ola Røer Thorsen" 
> Cc: "interestqt-project.org" 
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On Wed, 8 May 2019 at 00:14, Ola Røer Thorsen  wrote:
> >
> >
> > lør. 4. mai 2019 kl. 17:51 skrev Thiago Macieira 
> > :
> >>
> >> No, the size of something definitely fits in int on 32-bit systems. And 
> >> why do
> >> you need to do any static_cast in the first place?
> >
> >
> > We build our code using gcc with the options "-Wall -Wextra -Werror" and 
> > this leads us to have to use static_cast for example when comparing int and 
> > unsigned int (or std::size_t). A mix of using std::array, std::string and 
> > QVector/QByteArray often gives a few extra static casts, not that it 
> > bothers me too much.
> 
> Same here, with the added pain of compiling qt with qreal=float for
> arm-linux and qt=double for x86-linux/windows

IIRC, there was [fairly] recently  a discussion on the Qt development list 
about that... Might want to check the archives.


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

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

[Jason H]

> Sent: Saturday, May 04, 2019 at 11:48 AM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Operator QMap[] is casting to int?
>
> On Saturday, 4 May 2019 05:12:08 PDT Roland Hughes wrote:
> > On 5/4/19 5:00 AM, interest-requ...@qt-project.org wrote:
> > >> Unless Qt supports negative indexes (like python's [-1]) I would have
> > >> thought this would be an int. Thanks for catching that everyone.
> > >
> > > I'm assuming you made a typo there and meant to say "uint"? Regardless
> > > here's the official reason why Qt uses "int" for container indices:
> > > https://lists.qt-project.org/pipermail/interest/2013-September/008592.html
> >
> > There are an awful lot of places where Qt uses int when it should be
> > uint like when returning the size() of something.
>
> Those will likely change to qsizetype in Qt 6. Which is still signed.


This is disappointing. I'll only get half of the indexable space... can I get 
something in return? Having a negative index mechanism, like in Python, would 
be a way to alleviate some of the pain. Otherwise can you explain the rationale 
for not using signed?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] TapHandler tapped coordinates not accessible

[Jason H]

Taps are for taps, that a thing was tapped. Not where. Generally if you want points, you get the press/down/move event and save the coordinate there, then on the tap event, check what was saved. Sometimes . Maybe PointHandler is what you want? I often would like the x,y on an onClicked() handler, but I've never needed it.  Though using those TapHandlers is not anything I've worked with for a while.

 

 

Sent: Monday, May 06, 2019 at 10:30 AM
From: "Tomasz Olszak" 
To: "Qt Interest" 
Subject: [Interest] TapHandler tapped coordinates not accessible


Hi,
 

I use Qt 5.12.3 and I'm trying to use TapHandler. For some reason though in onTapped handler point is already reset.

I see that point is valid when reading it from onPressedChanged. Is it a bug? Seems like docs miss explicit example of reading point coordinate.

 

This is snippet I use to test.

https://pastebin.com/h8PneRDB

 

Any ideas?

 

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



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

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

[Jason H]

*facepalm*

 

Unless Qt supports negative indexes (like python's [-1]) I would have thought this would be an int. Thanks for catching that everyone.

BTW: I meant to do: 
quint32 foregroundColor = reverseHist[foregroundPixels];


So it was good I appened attentiont to the warning. 

 

Sent: Friday, May 03, 2019 at 10:58 AM
From: "Mike Chinander" 
To: "interestqt-project.org" 
Subject: Re: [Interest] Operator QMap[] is casting to int?


On that last line you're indexing a QList which takes an int for its argument.
 

https://doc.qt.io/qt-5/qlist.html#operator-5b-5d  

 


On Fri, May 3, 2019 at 9:44 AM Jason H <jh...@gmx.com> wrote:

Given the code below:
QMap reverseHistogram;
...
QList reverseKeys = reverseHistogram.keys();
int foregroundIndex = reverseHistogram.size()-2;           // arg, QMap::size() returns signed
uint foregroundPixels = reverseKeys[foregroundIndex];
uint foregroundColor = reverseKeys[foregroundPixels];
uint foregroundColor = reverseKeys[foregroundPixels]; //main.cpp:66:37: warning: implicit conversion changes signedness: 'uint' (aka 'unsigned int') to 'int'

Where is the "signed" conversion happening?

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

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



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

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

[Jason H]

Given the code below:
QMap reverseHistogram;
...
QList reverseKeys = reverseHistogram.keys();
int foregroundIndex = reverseHistogram.size()-2;   // arg, QMap::size() 
returns signed
uint foregroundPixels = reverseKeys[foregroundIndex];
uint foregroundColor = reverseKeys[foregroundPixels];
uint foregroundColor = reverseKeys[foregroundPixels]; //main.cpp:66:37: 
warning: implicit conversion changes signedness: 'uint' (aka 'unsigned int') to 
'int'

Where is the "signed" conversion happening?

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

Re: [Interest] Trying to access Microphone via QAudioInput on Mac 10.14

[Jason H]

You have to add the description of microphone use to be presented to the user.

 

I've done somethign similar to this, for video I think, and I did get the popup and it worked as it should have.

 

Sent: Thursday, May 02, 2019 at 9:37 AM
From: "Roland Winklmeier" 
To: interest@qt-project.org
Subject: [Interest] Trying to access Microphone via QAudioInput on Mac 10.14



Dear Qt experts,

 

I'm trying to access the microphone using QAudioInput for a VoIP application. Since Mac 10.14, I receive only silence from the QAudioInput. After reading the Mac OS 10.14 documentation, I realize that Apple added more Security/Privacy control to MacOS. All microphone access has to be approved by the user.

Fair enough, however the permission request to ask for authorization is never popping up. Also my application is not listed in the Privacy/Security control. I simply tried to open a default device with QAudioInput and started it. Do I miss something?

I also added NSMicrophoneUsageDescription to the Info.plist which seems necessary now. However, no success still.

 

I also read https://forum.qt.io/topic/97570/macos-mojave-privacy-prompt-not-appearing-when-debugging-audio-app-in-qt-creator/8 which suggests that it should work.

 

Does anyone know whats going on?

 

Thanks,

Roland

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



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

Re: [Interest] QML Audio loops

[Jason H]

I'm guessing, but the audio hardware is shutting down? As a cheap hack, since it is "white noise", (it's not technically white noise) can you overlap two with a time offset so the audio hardware never shuts down?

 

 

Sent: Thursday, April 18, 2019 at 8:45 AM
From: "Marc Van Daele" 
To: interest@qt-project.org
Subject: [Interest] QML Audio loops


Hello,
 

I have the following QML that plays an audio file in an infinite loop.

 



import QtQuick 2.11



import QtQuick.Window 2.11



import QtMultimedia 5.8



 



Window {



visible: true



width: 640



height: 480



title: qsTr("Hello World")



 



Audio {



id: noiseId



loops: Audio.Infinite



source: "qrc:/448213__florianreichelt__white-noise.wav"



onStatusChanged: console.log("status = " + status)



onError: console.log("error = " + error + " " + errorString)



onPlaybackStateChanged: console.log("playbackstate = " + playbackState)



}



 



Component.onCompleted: noiseId.play()



}

 


I used the noise file from here

Unfortunately, after every loop, I hear a clear short hiccup. 

Any advice on how to avoid these hiccups?

 

I'm using Qt5.11.2 on Ubuntu 16.04

 

Thanks in advance,

 

Marc

 



 



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



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

Re: [Interest] QtWebAssembly license question

[Jason H]

Check out: https://blog.qt.io/blog/2018/11/19/getting-started-qt-webassembly/#comment-1206267

 

You can always license it commercially. Commercial licesensees are not boung by GPL in Qt. Since you have a "boss" you're probably using Qt commercially. IANAL.

 

Sent: Tuesday, April 16, 2019 at 7:56 AM
From: "Fabrice Mousset | GEOCEPT GmbH" 
To: "inter...@lists.qt-project.org" 
Subject: [Interest] QtWebAssembly license question




Hello,

 

before starting QtWebAssembly evaluation, I would like to know what are the “limitation” of the GPL Version?

Does it mean that everything I will develop using QtWebAssembly must be GPL?

 

At this time, we have developed our Web frontend using _javascript_ base kits, but I am not a _javascript_ fan, I would prefer do the development with C++/QML.

But, if all have to be GPLed, my boss would not agree.

 

I am a software developer and not a lawyer, so could someone give me more information about this point?

I hope the is the right mailing-list to post this kind of question?

 

Best regards

 

Fabrice Mousset

___ 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] Random question Friday: Why no area() for Rects and Sizes?, path.join()?

[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

2. Path to enlightenment
I often miss Node and Python that has a path appender. This could have been 
tedious in the past but in C++11, QDir::join({parts, of, a, path, and, 
filename})  (declared as static QDir::join(const QStringList& parts);)
I'm aware that Qt makes file path delimiters OS-agnostic, but I find myself 
missing the construct as a logical concept.  Also consider:

source = "file://" + appPath+ "/" + filename

which becomes:

source = QDir::join({"file://", appPath, filename})

which I would argue is slightly more readable. While Url* at it, maybe one for 
QUrl as well? (Not sure how to handle scheme/protocol.)

https://stackoverflow.com/questions/2217258/os-path-join-in-qt
https://stackoverflow.com/questions/740423/qt-class-for-handling-file-paths

*pun accidental, but enjoyed.


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

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

You are indeed correct. I am iterating on a minimal test case and the first versions do work. I'm working back to the minimal case that I experienced the issue. This may take some time though.

 

Thank you for your help

 

 

Sent: Thursday, April 11, 2019 at 10:07 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Konstantin Shegunov" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 4:57 PM Jason H <jh...@gmx.com> wrote:





Update on this:

It didn't work. I called it, nothing (discernable) happened. Got a bunch of serial port not open errors





Something else's amiss. Here's the test-case:
 

#include 

#include 

 

int main(int argc, char *argv[])

{

QCoreApplication app(argc, argv);

 

QObject::connect(&app, &QCoreApplication::aboutToQuit, [] () -> void  {

qDebug() << "Goodbye cruel world!";

});

QMetaObject::invokeMethod(&app, &QCoreApplication::quit, Qt::QueuedConnection);


 

return QCoreApplication::exec();

}



Which produces (as expected):



17:05:37: Debugging starts

Goodbye cruel world!

17:05:38: Debugging has finished







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

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

Update on this:

It didn't work. I called it, nothing (discernable) happened. Got a bunch of serial port not open errors

 

Sent: Thursday, April 11, 2019 at 9:44 AM
From: "Jason H" 
To: "Konstantin Shegunov" 
Cc: "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?




Thanks!  If it's that easy, and more reliable, why doesn't qApp->quit() do it that way?

 

 

Sent: Thursday, April 11, 2019 at 8:54 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Giuseppe D'Angelo" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 3:48 PM Jason H <jh...@gmx.com> wrote:


What is the best way to do that? I think in the past, I used a 0ms timer, but that always feels janky.


QMetaObject::invokeMethod(qApp, ::quit, Qt::QueuedConnection);

is my preference.







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



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

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

Thanks!  If it's that easy, and more reliable, why doesn't qApp->quit() do it that way?

 

 

Sent: Thursday, April 11, 2019 at 8:54 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Giuseppe D'Angelo" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 3:48 PM Jason H <jh...@gmx.com> wrote:


What is the best way to do that? I think in the past, I used a 0ms timer, but that always feels janky.


QMetaObject::invokeMethod(qApp, ::quit, Qt::QueuedConnection);

is my preference.






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

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

> Sent: Thursday, April 11, 2019 at 7:35 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Signals, slots before the event loop starts?
>
> Il 11/04/19 00:18, Jason H ha scritto:
> > In a QObject who is exported to QML, and is instantiated just below the 
> > top-level Window:
> > //  in the object's open() method:
> > if (!_serialPort.open(QIODevice::ReadWrite))
> > qApp->quit(); // won't actually quit - no use if I can't use the serial 
> > port. (because another instance is using it)
> >
> > Then I have a ready() signal that is emitted when the serial device is 
> > ready, however the QML, when I hook onReady, it never gets called. I have 
> > to use a Component.onCompleted at the top level. However, there is async 
> > serial I/O happening, so there is at least one event loop?
> >
> > What can I do to make sure these things work?
>
> Regarding quit(): calling it before exec() has been called yields no
> effects. This is documented:
>
> > https://doc.qt.io/qt-5/qcoreapplication.html#quit
>
> > If a signal connected (non-queued) to this slot is emitted before control 
> > enters the main event loop (such as before "int main" calls exec()), the 
> > slot has no effect and the application never exits
>
> So, instead of calling quit() directly, do a queued invocation.

What is the best way to do that? I think in the past, I used a 0ms timer, but 
that always feels janky.

>
> Regarding ready(): can't say more without looking at the code. You need
> to make a minimal testcase.

It's rather simple, port opens when the portname property is set during 
initialization. The device writes a ready message that i detect and emit 
(somehow... I don't know how I process it in readyRead handler without an event 
loop, but it happens). I emit ready() and the QML handler for ready does not 
get invoked.

> Anyhow, all events queued before running exec() will get dispatched when
> you enter the event loop. The problem with e.g. quit() is that it does
> not involve sending events at all, it involves setting a flag into the
> event loop. Flag that is never read because the event loop is not running...

That seems janky as well. Why not give it it's own message? Even windows has 
WM_QUIT.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

Because I can't. The QML engine is loading, creating the objects. There is 
nothing I can return to.

Its like I want to create the event loop, init, then hand the app.exec() pick 
up the events already queued in the event loop...



> Sent: Thursday, April 11, 2019 at 3:20 AM
> From: "Tony Rietwyk" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Signals, slots before the event loop starts?
>
> Hi Jason,
>
> Why can't your initialisation pass back a status to the main routine?
>
> Otherwise I suggest to use a short timer, so it gets picked up early
> when the main event loop starts.
>
> Hope that helps, Tony
>
>
> On 11/04/2019 8:18 am, Jason H wrote:
> > I've now come across two places in my code where this is an issue (at 
> > various states of initializing)
> >
> > In a QObject who is exported to QML, and is instantiated just below the 
> > top-level Window:
> > //  in the object's open() method:
> > if (!_serialPort.open(QIODevice::ReadWrite))
> > qApp->quit(); // won't actually quit - no use if I can't use the serial 
> > port. (because another instance is using it)
> >
> > Then I have a ready() signal that is emitted when the serial device is 
> > ready, however the QML, when I hook onReady, it never gets called. I have 
> > to use a Component.onCompleted at the top level. However, there is async 
> > serial I/O happening, so there is at least one event loop?
> >
> > What can I do to make sure these things work?
> >
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Signals, slots before the event loop starts?

[Jason H]

I've now come across two places in my code where this is an issue (at various 
states of initializing)

In a QObject who is exported to QML, and is instantiated just below the 
top-level Window:
//  in the object's open() method:
if (!_serialPort.open(QIODevice::ReadWrite))
qApp->quit(); // won't actually quit - no use if I can't use the serial 
port. (because another instance is using it)

Then I have a ready() signal that is emitted when the serial device is ready, 
however the QML, when I hook onReady, it never gets called. I have to use a 
Component.onCompleted at the top level. However, there is async serial I/O 
happening, so there is at least one event loop?

What can I do to make sure these things work?




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

Re: [Interest] Parsing data from serialport

[Jason H]

Yea, I'm going to have to agree with Denis over Roland. In general it's not good to do synchronous operations (expecially I/O) in the main thread, but Qt I/O is mostly* asyc.

 

*caveat: data reading/writng is async, but things like QDir::mkDir() are sync. So if you're on a slow 5400RPM disk with a swap file on it on a system that is actively swapping, in a deep direcyory structure, on old fielsystems, it might take a while (100s of ms).

 

I'm not sure if Qt wants fully async I/O as I've witnessed what it does to a code base - some functions are async others are sync and you don't want that mess in your code. Coroutines will be a C++ thing (C++20), but I migh prefer the clarity of just being syncronous in your own thread. A lot of people don't realize that as soon as you ask for I/O your thread gets suspended by the kernel anyway. There are corner cases where you can get slughtly better performance because you can avoid the context switch, but the penalty on codebase is large as readability suffers. If the async nature could be completely hidden, that would be fine. But cyrrently in JS and Python, it's an imperfect abstraction.

 

 

Sent: Friday, April 05, 2019 at 5:45 AM
From: "Denis Shienkov" 
To: rol...@logikalsolutions.com
Cc: h...@gmx.com, interest@qt-project.org
Subject: Re: [Interest] Parsing data from serialport












> Never ever ever do I/O in the main GUI thread of a Qt application.

 

Why not? It is an asynchronous. You can do I/O in a main thread, but handle data in a separate thread (e.g. to parse it). Of course, it depends on the used communication protocol and etc.

A main limitation is that on Windows all I/O stops when a user hold-on the application window (ot to drag it, or do resizing). It is a Windows 'feature'.

 

So, yes, in a common case it is makes sense to move the QSerialPort object to the different thread (a concept of workers).

 

> Real world serial comm is fraught with peril. I've been doing it since the days of DOS 3.1.

 

It's not true.

 

> Unless something has dramatically changed in QSerialPort, readyRead is only emitted for the first character in the buffer because there is no concept of block or packet. A UART handles one byte at a time.

 

It's not true too. The readyRead() will be triggered when the device's handle/descriptor becomes 'signalled/activated' (when something comes into FIFO of driver), in this case the QSerialPort reads all data which are in this time in the FIFO (there are may be some bytes). So, no any byte-per-byte handling as you say.

 

> When you get a readyRead and fail to completely empty the buffer, that's it. You never get another one.

 

I'm don't understand what do you mean...

 

> When QSerialPort was taken from Playground and had all its method names changed, there was an odd timing bug too. In a production system running multiple ports of embedded target the code loading the next byte into the class buffer (perhaps not completely Qt code as it could have been in the device driver). The adding of the next byte could begin after readLine() determined how many bytes were in the buffer but prior to actually pulling them. The new byte got added. One less than a full buffer got read and readyRead never fired again because the next byte wasn't being written to a pristine empty buffer.

 

I don't know about what you say... It is trash for my opinion.. For you has been provided a good code example how to read the lines:

 

>     QSerialPort * port;
>     QObject::connect(port, ::readyRead, port, [port] () -> void  {
>         while (port->canReadLine())  {
>             QByteArray data = "">
>             // emit with data as argument and do the parsing
>         }
>     });

 

BR,

Denis

 

 

 








 


пт, 5 апр. 2019 г. в 10:38, :


Quoting interest-requ...@qt-project.org:

> I think the point is that there's little reason to poll the serial port if
> you can react to the event. Exactly what you'd do if you had a network
> socket. Qt already does the heavy lifting for you, so you only need to
> react to the signal and read as much as you want/need. Basically:
>
>     QSerialPort * port;
>     QObject::connect(port, ::readyRead, port, [port] () -> void  {
>         while (port->canReadLine())  {
>             QByteArray data = "">
>             // emit with data as argument and do the parsing
>         }
>     });
>
> Whether you have the port in another thread or not is irrelevant in this
> case, either can work fine (unlike your while-sleep loop).

Never ever ever do I/O in the main GUI thread of a Qt application. 
It's a recipe for disaster despite the countless examples you will 
find posted on-line and even in the Qt examples themselves. Those 
database examples are really nice. Try testing them with a million+ 
row table.

Real world serial comm is fraught with peril. I've been doing it since 
the days of DOS 3.1.

Before anyone goes running off and using the above lambda, they need 

Re: [Interest] QWebSocketServer - server randomly stopsacceptingconnections

[Jason H]

Yes. Gone are the days of security from obscurity. Minutes after standing up a 
AWS ec2 instance i was getting scanned. Easy way to get rid of most of that is 
don't be on a common port like 8080, port scans are less frequent but still 
happen. Also maybe deploy a reverse proxy to validate requests. 

But let's get that patch committed. 

> Sent: Thursday, April 04, 2019 at 8:32 PM
> From: "Jakub Narolewski" 
> To: "Jason H" 
> Cc: "interest@qt-project.org" 
> Subject: RE: [Interest] QWebSocketServer - server randomly 
> stopsacceptingconnections
>
> Quick test and it looks like this is it. When I start my server in SSL mode 
> and spam some ws connections at it I quickly loose ability to connect – even 
> under Windows.
> What’s more, trying to connect to SSL server using ws protocol does not emit 
> any errors on the server side.
> 
> Can situation on my remote test server can be attributed to bots and / or 
> scanners? Our client forces only wss connections, so something else has try 
> to connect to it.
> Well, either this is QTBUG-57026 or some other, completely unrelated thing x]
> 
> Hmm, this could be problematic. Either I will hack Qt sources or will try to 
> use QTcpServer to hack around it.
> 
> 
> From: Jason H
> Sent: 04 April 2019 19:07
> To: Jakub Narolewski
> Cc: interest@qt-project.org
> Subject: Re: RE: [Interest] QWebSocketServer - server randomly 
> stopsacceptingconnections
> 
> Wow, a P1 that was abandoned. https://codereview.qt-project.org/#/c/179030/
>  
> **facepalm** 
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections

[Jason H]

Wow, a P1 that was abandoned. https://codereview.qt-project.org/#/c/179030/

 

**facepalm** 

 



Sent: Thursday, April 04, 2019 at 12:59 PM
From: "Jakub Narolewski" 
To: "Jason H" 
Cc: "interest@qt-project.org" 
Subject: RE: [Interest] QWebSocketServer - server randomly stops acceptingconnections




I just found this old report:

 

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

 

which sounds suspiciously similar to what I am observing. Hmm, I wonder if you hit the jackpot writing earlier to use QTcpServer to initialize connections.

If I could still use SSL with QWebSocketServer::handleConnection(QTcpSocket *socket) then this could be the solution :]

 

Will test it and report back!

 


From: Jason H
Sent: 04 April 2019 17:49
To: Narolewski Jakub
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections


 

 


1. Add a slowloris attack to your fuzzer. Really.



2. "rejected" means something specific. The server does not reject your connection. Your client sends the RST packet.




 



The "long periods" could just be those first few [hundred] connections where everything goes right, but the slow connection breaks it. I've actually seen this before in company proprietaty code. I wrote a local storage service - previously the storage server was remote - and the timing of packets broke the header parsing. This seems really similar in nature. It -no joke- expected that all the header data in the first packet and no additional data. However now that the service was lusing the localhost (loopback) interface it was no longer subject to MTU and nagle's algorythm.



 



 





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

Re: [Interest] QWebSocketServer - server randomly stops accepting connections

[Jason H]

 

1. Add a slowloris attack to your fuzzer. Really.

2. "rejected" means something specific. The server does not reject your connection. Your client sends the RST packet.


 

The "long periods" could just be those first few [hundred] connections where everything goes right, but the slow connection breaks it. I've actually seen this before in company proprietaty code. I wrote a local storage service - previously the storage server was remote - and the timing of packets broke the header parsing. This seems really similar in nature. It -no joke- expected that all the header data in the first packet and no additional data. However now that the service was lusing the localhost (loopback) interface it was no longer subject to MTU and nagle's algorythm.

 


Sent: Thursday, April 04, 2019 at 11:39 AM
From: "Narolewski Jakub" 
To: "Jason H" 
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections



First of all, thank you Jason for detailed analysis of the QWS' source and tips about what can be done next.

 

I will of course report this to Qt JIRA as soon as I rule out error on my end. 

 

About the stuff with endsWith(), keep in mind that I have long periods of time when server works just fine. Clinets can connect to it and their connection method is just the same. 

 

When we test connection to the server we either use our client - game written in Unity3D, or its WebGL version deployed to the Facebook's GameRoom.

 

Currently our server has disabled preemptive client authorization, so even using https://www.websocket.org/echo.html is sufficient to connect.

 

In either case, connection is rejected.

 

On Thu, 4 Apr 2019, 17:03 Jason H, <jh...@gmx.com> wrote:

That's NOT what I was going for!! I specifically said I have not tested any of those theories. I ALSO said I have used it successfully. Do not let my speculation hold you up. The more eyes (users) we have on this the better it will be.

At this point Jakub should probably file a bug at https://bugreports.qt.io/secure/Dashboard.jspa , as this is not my bug and I have no ability to reproduce it. Feel free to attach my speculation and/or tag me.

Given that it takes a while for this to show up, I'm increasingly confident that the endsWith() is the issue. A slow client might deliver the bytes in an unpredictable way. If the client doesn't wait to send the request after a successful header, and just sends it blindly, endsWith() won't work.

Also, I am looking at the wireshark pcap and there is no 0d 0a ("\r\n") sequence (much less 0a 0a 0d 0a ("\r\n\r\n"), so maybe it's the client's fault? So I could also still be TOTALLY wrong.

> Sent: Thursday, April 04, 2019 at 10:41 AM
> From: "alexander golks" <a...@golks.de>
> To: No recipient address
> Cc: interest@qt-project.org
> Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections
>
> i was going to switch some codebase to websocket server, too,
> but reading this lets me think again...
>
> thanks ;)
>
> Am Thu, 4 Apr 2019 16:33:19 +0200
> schrieb "Jason H" <jh...@gmx.com>:
>
> > I looked at the private implementation of QWebSocketServer, QWebSocketServerPrivate.
> >  
> > I haven't tested it, but there are a few concerns:
> >  
> > 1. That for errorString(), it first checks if it doesn't have an error then returns the QTcpSocket errorString(). But if you just look at serverError() it only reports it's own error and nothing at the QTcpSocket level. This means that if you only check serverError() you won't catch QTcpServer error. This is probably a bug. QWebSocketProtocol::CloseCode needs to be able to express QAbstractSocket::SocketErrors as well.
> >  
> > 2. QWebSocketServerPrivate::handshakeReceived() has a check of pTcpSocket->bytesAvailable()).endsWith(QByteArrayLiteral("\r\n\r\n") Such position-reliant checks are bad form. There's no reason for it to end with, it should probably be using contains()
> >  
> > 3. There are multiple `if` blocks that don't set an error. This isn't wrong, as the handhake bytes may come in slowly and take multiple re-parsings, (something to add to your fuzzer?) but you can wind up in an uncaught error state.
> >  
> >  
> >  
> > Sent: Thursday, April 04, 2019 at 10:07 AM
> > From: "Jason H" <jh...@gmx.com>
> > To: "Narolewski Jakub" <izow...@gmail.com>
> > Cc: interest@qt-project.org
> > Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections
> > So, yeah, I was thinking of QTcpServer::incommingConnection(). That function is used in multithreadding because you use the descriptor to make a socket on the proper thread. Looks like QWebSocketServer is no

Re: [Interest] Parsing data from serialport

[Jason H]

Maybe you don't need another thread, just maybe an event loop (QEventLoop)?


> Sent: Thursday, April 04, 2019 at 10:43 AM
> From: "Jérôme Godbout" 
> To: "Paolo Angelelli" , "interest@qt-project.org" 
> 
> Subject: Re: [Interest] Parsing data from serialport
>
> It relief the main thread from read data all the time and keep a good 
> reactivity. The dedicated thread try to read and can wait until something 
> come along and once it found something that can be parsed, it emit his own 
> signal that the main thread only have to handle into normal slot (will be 
> queued, since it's not the same thread).
> 
> But yeah, you can have the main thread do it and process the readyRead(), you 
> main thread will perform the read and parsing. if you have any CRC and other 
> things, this might be bad for application reactivity, depending on the amount 
> of data flowing.
> 
> -Original Message-
> From: Interest  On Behalf Of Paolo Angelelli
> Sent: April 4, 2019 10:19 AM
> To: interest@qt-project.org
> Subject: Re: [Interest] Parsing data from serialport
> 
> What is the advantage of having such a continuous reading loop in a separate 
> thread?
> 
> I mean it as opposed to reacting to the readyRead() signal, and having a 
> while(canReadLine()) { ... } in the reacting slot.
> 
> 
> On Tue, 2 Apr 2019 22:01:49 +
> Jérôme Godbout  wrote:
> 
> > Make sure your reading loop and processing data are separated. Call you 
> > read device when needed or into a loop that can take some pause to avoid 
> > 100% CPU usage for nothing.
> > 
> > QByteArray buffer;
> > 
> > void ReadDeviceHaveData()
> > {
> > 
> >while(serial_port->bytesAvailable()) // This can be dangerous is 
> > data keep coming  and might be removed {
> > // You can read bytes per bytes or smaller chunk over here for 
> > better reactivity and less memory consumption
> > buffer.append(serial_port->readAll());
> > processData();
> > serial_port->waitForReadyRead(5);
> >  }
> > }
> > 
> > void ProcessData()
> > {
> >int pos = buffer.indexOf(‘\n’);
> > 
> >while(pos >= 0)
> >{
> >  QByteArray line = buffer.left(pos);
> >  // Strip trailing \r for windows here
> >  // Do whatever you need with your line, check data integrity
> > 
> >  // Remove the processed data but leave the unprocessed data alone
> >  buffer.remove(0, pos + 1); // Remove \n too
> >  pos = buffer.indexOf(‘\n’);
> >}
> > }
> > 
> > From: Interest  On Behalf Of Martin 
> > Marmsoler
> > Sent: April 2, 2019 3:58 PM
> > To: Thiago Macieira 
> > Cc: interest@qt-project.org
> > Subject: Re: [Interest] Parsing data from serialport
> > 
> >  > To be able to roll back, in case your reading from the device 
> > didn't result in what you wanted or you got an error. See QDataStream.
> > Ah ok I understand.
> > 
> > So this minimal example
> > QSerialPort sPort;
> > sPort.open(QIODevice::ReadOnly);
> > 
> > if(sPort.waitForReadyRead(2000)){
> > 
> >   while (!device.atEnd()) {
> > 
> > if (device.canReadLine()) {
> > 
> >newData.push_back(device.readLine());
> > 
> >linesToRead++;
> > 
> > } else {
> > 
> >return;
> > 
> > }
> > 
> >}
> > 
> >...
> > 
> > }
> > 
> > works fine, if I go trough it step by step (maybe, because enouth data come 
> > in). But if I'm to fast it does not work.
> > 
> > If I'm using the signal readyRead I will have the same problem, 
> > because new data come everytime. So I check that in the
> > 
> > readyRead function if a complete line come in, and if no complete line 
> > I return without doing something otherwise I do
> > 
> > something with the data? Is this the right way?
> > 
> > 
> > 
> > Martin
> > 
> > 
> > 
> > 
> > Thiago Macieira 
> > mailto:thiago.macie...@intel.com>> schrieb am 
> > Di., 2. Apr. 2019, 18:02:
> > On Tuesday, 2 April 2019 07:04:03 PDT Martin Marmsoler wrote:
> > > Thank you Thiago for your response. But what is transactionstart for?  
> > 
> > To be able to roll back, in case your reading from the device didn't 
> > result in what you wanted or you got an error. See QDataStream.
> > 
> > --
> > 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
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebSocketServer - server randomly stops accepting connections

[Jason H]

That's NOT what I was going for!! I specifically said I have not tested any of 
those theories. I ALSO said I have used it successfully. Do not let my 
speculation hold you up. The more eyes (users) we have on this the better it 
will be. 

At this point Jakub should probably file a bug at 
https://bugreports.qt.io/secure/Dashboard.jspa , as this is not my bug and I 
have no ability to reproduce it. Feel free to attach my speculation and/or tag 
me. 

Given that it takes a while for this to show up, I'm increasingly confident 
that the endsWith() is the issue. A slow client might deliver the bytes in an 
unpredictable way. If the client doesn't wait to send the request after a 
successful header, and just sends it blindly, endsWith() won't work. 

Also, I am looking at the wireshark pcap and there is no 0d 0a ("\r\n") 
sequence (much less 0a 0a 0d 0a ("\r\n\r\n"), so maybe it's the client's fault? 
So I could also still be TOTALLY wrong. 

> Sent: Thursday, April 04, 2019 at 10:41 AM
> From: "alexander golks" 
> To: No recipient address
> Cc: interest@qt-project.org
> Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting 
> connections
>
> i was going to switch some codebase to websocket server, too,
> but reading this lets me think again...
> 
> thanks ;)
> 
> Am Thu, 4 Apr 2019 16:33:19 +0200
> schrieb "Jason H" :
> 
> > I looked at the private implementation of QWebSocketServer, 
> > QWebSocketServerPrivate.
> >  
> > I haven't tested it, but there are a few concerns:
> >  
> > 1. That for errorString(), it first checks if it doesn't have an error then 
> > returns the QTcpSocket errorString(). But if you just look at serverError() 
> > it only reports it's own error and nothing at the QTcpSocket level. This 
> > means that if you only check serverError() you won't catch QTcpServer 
> > error. This is probably a bug. QWebSocketProtocol::CloseCode needs to be 
> > able to express QAbstractSocket::SocketErrors as well.
> >  
> > 2. QWebSocketServerPrivate::handshakeReceived() has a check of 
> > pTcpSocket->bytesAvailable()).endsWith(QByteArrayLiteral("\r\n\r\n") Such 
> > position-reliant checks are bad form. There's no reason for it to end with, 
> > it should probably be using contains()
> >  
> > 3. There are multiple `if` blocks that don't set an error. This isn't 
> > wrong, as the handhake bytes may come in slowly and take multiple 
> > re-parsings, (something to add to your fuzzer?) but you can wind up in an 
> > uncaught error state.
> >  
> >  
> >  
> > Sent: Thursday, April 04, 2019 at 10:07 AM
> > From: "Jason H" 
> > To: "Narolewski Jakub" 
> > Cc: interest@qt-project.org
> > Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting 
> > connections
> > So, yeah, I was thinking of QTcpServer::incommingConnection(). That 
> > function is used in multithreadding because you use the descriptor to make 
> > a socket on the proper thread. Looks like QWebSocketServer is not 
> > multithreaded. 
> >  
> > I've used Qt's websockets, and I've used QTcpServer extensively on 5-nines 
> > stuff. Never saw anything like this. 
> >  
> > Next steps: 
> > - QWebSocketServer::setMaxPendingConnections() set this to 0, 1, or 100, 
> > see what (if anything) changes.
> > - Use QTcpServer to and QWebSocketServer::handleConnection(QTcpSocket*) to 
> > handle the connection yourself just to get QWebSocketServer out of the 
> > initial connection stuff.
> >  
> > Whatever the cause, I think you're in bug territory, either in Qt or the 
> > linux kernel. Both of those is unlikely.  There is one more possibilty, if 
> > you're using secure sockets, maybe something is failing at the SSL level? 
> > Like your SSL implementation stops working for whatever reason?
> >  
> > Sent: Thursday, April 04, 2019 at 9:13 AM
> > From: "Narolewski Jakub" 
> > To: "Jason H" 
> > Cc: interest@qt-project.org
> > Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting 
> > connections
> > That's the thing. I already handle connections and disconnections in my 
> > code - including logging relevant information.
> > When I implemented this I heavily based on the example that you linked to.
> > WSS communication is single threaded - only way to communicate with the 
> > outside world from different thread is to send custom QEvent onto the 
> > Server instance.
> > QWebSocketServer does not seem to have the method incomingConnection in 
> > it's public API or maybe I al

Re: [Interest] QWebSocketServer - server randomly stops accepting connections

[Jason H]

I looked at the private implementation of QWebSocketServer, QWebSocketServerPrivate.

 

I haven't tested it, but there are a few concerns:

 

1. That for errorString(), it first checks if it doesn't have an error then returns the QTcpSocket errorString(). But if you just look at serverError() it only reports it's own error and nothing at the QTcpSocket level. This means that if you only check serverError() you won't catch QTcpServer error. This is probably a bug. QWebSocketProtocol::CloseCode needs to be able to express QAbstractSocket::SocketErrors as well.

 

2. QWebSocketServerPrivate::handshakeReceived() has a check of pTcpSocket->bytesAvailable()).endsWith(QByteArrayLiteral("\r\n\r\n") Such position-reliant checks are bad form. There's no reason for it to end with, it should probably be using contains()


 

3. There are multiple `if` blocks that don't set an error. This isn't wrong, as the handhake bytes may come in slowly and take multiple re-parsings, (something to add to your fuzzer?) but you can wind up in an uncaught error state.

 

 

 


Sent: Thursday, April 04, 2019 at 10:07 AM
From: "Jason H" 
To: "Narolewski Jakub" 
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections




So, yeah, I was thinking of QTcpServer::incommingConnection(). That function is used in multithreadding because you use the descriptor to make a socket on the proper thread. Looks like QWebSocketServer is not multithreaded. 

 

I've used Qt's websockets, and I've used QTcpServer extensively on 5-nines stuff. Never saw anything like this. 

 

Next steps: 

- QWebSocketServer::setMaxPendingConnections() set this to 0, 1, or 100, see what (if anything) changes.

- Use QTcpServer to and QWebSocketServer::handleConnection(QTcpSocket*) to handle the connection yourself just to get QWebSocketServer out of the initial connection stuff.

 

Whatever the cause, I think you're in bug territory, either in Qt or the linux kernel. Both of those is unlikely.  There is one more possibilty, if you're using secure sockets, maybe something is failing at the SSL level? Like your SSL implementation stops working for whatever reason?

 



Sent: Thursday, April 04, 2019 at 9:13 AM
From: "Narolewski Jakub" 
To: "Jason H" 
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections


That's the thing. I already handle connections and disconnections in my code - including logging relevant information.
When I implemented this I heavily based on the example that you linked to.
WSS communication is single threaded - only way to communicate with the outside world from different thread is to send custom QEvent onto the Server instance.
QWebSocketServer does not seem to have the method incomingConnection in it's public API or maybe I already went mad :P I react to the QWebSocketServer::newConnection signal.

Last RST from client at 33 second mark is our client-side timeout.
This is the code that handles websocket stuff, I have stripped some parts that are less important:

// server connects
connect(m_wsServer, ::acceptError, this, [this](QAbstractSocket::SocketError socketError) {
        qCritical() << "QWebSocketServer - acceptError:" << socketError;
});

connect(m_wsServer, ::peerVerifyError, this, [this](const QSslError& error) {
        qCritical() << "QWebSocketServer - peerVerifyError:" << error;
});

connect(m_wsServer, ::serverError, this, [this](QWebSocketProtocol::CloseCode closeCode) {
        qCritical() << "QWebSocketServer - serverError:" << closeCode;
});

connect(m_wsServer, ::sslErrors, this, [this](const QList& errors) {
        qCritical() << "QWebSocketServer - sslErrors:" << errors;
});

connect(m_wsServer, ::closed, this, [this]() {
        qCritical() << "QWebSocketServer - closed, serverError():" << m_wsServer->errorString();
});

connect(m_wsServer, ::newConnection, this, [this]() {
        QWebSocket* clientSocket = m_wsServer->nextPendingConnection();
        qInfo() << "Got connection from client:" << clientSocket->peerAddress();

        [ client initialization stuff ]

        connect(clientSocket, ::binaryMessageReceived, this, [this](const QByteArray& message) {
                auto client = sender()->property("client").value();

                [ message deserialization ]
        });

        connect(clientSocket, ::disconnected, this, [this]() {
                auto client = sender()->property("client").value();
                qInfo() << client->sayHello() << "is disconnected.";

                client->handleDisconnection();

                [ clinet cleanup stuff ]
        });
});

Client's handleDisconnection() function does:

void

Re: [Interest] QWebSocketServer - server randomly stops accepting connections

[Jason H]

So, yeah, I was thinking of QTcpServer::incommingConnection(). That function is used in multithreadding because you use the descriptor to make a socket on the proper thread. Looks like QWebSocketServer is not multithreaded. 

 

I've used Qt's websockets, and I've used QTcpServer extensively on 5-nines stuff. Never saw anything like this. 

 

Next steps: 

- QWebSocketServer::setMaxPendingConnections() set this to 0, 1, or 100, see what (if anything) changes.

- Use QTcpServer to and QWebSocketServer::handleConnection(QTcpSocket*) to handle the connection yourself just to get QWebSocketServer out of the initial connection stuff.

 

Whatever the cause, I think you're in bug territory, either in Qt or the linux kernel. Both of those is unlikely.  There is one more possibilty, if you're using secure sockets, maybe something is failing at the SSL level? Like your SSL implementation stops working for whatever reason?

 



Sent: Thursday, April 04, 2019 at 9:13 AM
From: "Narolewski Jakub" 
To: "Jason H" 
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops accepting connections


That's the thing. I already handle connections and disconnections in my code - including logging relevant information.
When I implemented this I heavily based on the example that you linked to.
WSS communication is single threaded - only way to communicate with the outside world from different thread is to send custom QEvent onto the Server instance.
QWebSocketServer does not seem to have the method incomingConnection in it's public API or maybe I already went mad :P I react to the QWebSocketServer::newConnection signal.

Last RST from client at 33 second mark is our client-side timeout.
This is the code that handles websocket stuff, I have stripped some parts that are less important:

// server connects
connect(m_wsServer, ::acceptError, this, [this](QAbstractSocket::SocketError socketError) {
        qCritical() << "QWebSocketServer - acceptError:" << socketError;
});

connect(m_wsServer, ::peerVerifyError, this, [this](const QSslError& error) {
        qCritical() << "QWebSocketServer - peerVerifyError:" << error;
});

connect(m_wsServer, ::serverError, this, [this](QWebSocketProtocol::CloseCode closeCode) {
        qCritical() << "QWebSocketServer - serverError:" << closeCode;
});

connect(m_wsServer, ::sslErrors, this, [this](const QList& errors) {
        qCritical() << "QWebSocketServer - sslErrors:" << errors;
});

connect(m_wsServer, ::closed, this, [this]() {
        qCritical() << "QWebSocketServer - closed, serverError():" << m_wsServer->errorString();
});

connect(m_wsServer, ::newConnection, this, [this]() {
        QWebSocket* clientSocket = m_wsServer->nextPendingConnection();
        qInfo() << "Got connection from client:" << clientSocket->peerAddress();

        [ client initialization stuff ]

        connect(clientSocket, ::binaryMessageReceived, this, [this](const QByteArray& message) {
                auto client = sender()->property("client").value();

                [ message deserialization ]
        });

        connect(clientSocket, ::disconnected, this, [this]() {
                auto client = sender()->property("client").value();
                qInfo() << client->sayHello() << "is disconnected.";

                client->handleDisconnection();

                [ clinet cleanup stuff ]
        });
});

Client's handleDisconnection() function does:

void i9ms::Client::handleDisconnection()
{
        m_isConnected = false;
        m_websocket->deleteLater();
        m_websocket   = nullptr;
}

Nothing from this lands in system logs. It seems that QWebSocketServer::newConnection() is just not emited.
As I wrote earlier I have a timerEvent that logs QWebSocketServer's state - once every ten minutes.
It happily reports that server is listening, has no pending connections and it's internal 'errorString' is empty - even if it is mute from the outside.

It's hard for me to pinpoint exactly what causes this. 'Time' is my best guess.
I'm also not sure if quantity of connections plays a role here.

I have a 'fuzzer-bot' that spams hundreds of connections and messages at the server in short period of time.
Malformed messages, out-of-order client state changes, ugly words - you name it we have it.
QWebSocketServer handles it well enough for us but then, at some time in future WHILE being completely idle, server goes silent.
On the other hand I can start the server, connect - disconnect one client, leave it for a while in idle and same thing happens, leaving me one step closer to dementia.
 

On Wed, 3 Apr 2019, 22:32 Jason H, <jh...@gmx.com> wrote:




Addendum, 

 

How much does you code diverge from the example? https://doc.qt.io/qt-5/ech

Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections

[Jason H]

So full disclosure it's been a while. But it does look like the connection was accepted by the server, the client sent 334 bytes of data and 33 seconds later the client disconnected.

 

To me this would mean that the OS accepted the connection because Qt was listening on it, and Qt failed to emit incommingConnection() or  emit readyRead(). Looking at the source, this class is a very thin wrapper around QTcpServer. In the docs, it says if you have more than the maxPendingConnections() limit (30) it will start emitting errors. " QWebSocketServer will emit the error() signal with the QWebSocketProtocol::CloseCodeAbnormalDisconnection close code when the maximum of connections has been reached."

Given that it takes time for this to show up, this may be it. Also if you have a lot of clients, you might take a while, make sure that you socket->deleteLater()  when the connection is closed. 

 

I can't be sure how you are using it, but my next steps would be to:

- QWebSocketServer::error()

- make sure idle (implement your own timeout mechanism) and closed connections are deleteLater()ed.

- maybe maintain a list of connections and log that?

- Check your threading model. If you're not multithreaded maybe some previous client is blocking you? (Log incommingConnection, with object addresses)

 

 

 

 

 

Sent: Wednesday, April 03, 2019 at 1:32 PM
From: "Jakub Narolewski" 
To: "Jason H" 
Cc: "interest@qt-project.org" 
Subject: RE: [Interest] QWebSocketServer - server randomly stops acceptingconnections




Hello Jason,

 

Thank you very much for your reply.

 

I’m not sure if I can / should directly attach binaries here. I’ve uploaded a wireshark dump of the connection attempt at:

 

https://drive.google.com/open?id=1juNXd7pkI9Xryt_enjh6i2LWm3RL5iQV

 

I call listen() method with QHostAddress::Any parameter value:

 

m_wsServer->listen(QHostAddress::Any, m_port)

 

No proxy is used.

No other custom, network oriented software is running on this box. Only vanilla stuff that came post VPS provisioning.

 

 


From: Jason H
Sent: 03 April 2019 18:23
To: Jakub Narolewski
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections


 

What happens when you telnet to it?



Are you getting stuff (SYN_ACK) rom the OS, is the OS resetting (RST) the connection?



Is this listening on localhost, virtual or a physical interface?



Linux is generally bad at power managment and networking and maybe that has something to do with it? There is/was an issue with QNetworkAccessManager which after the task got suspended, would not work anymore (I saw this mostly on mobile OSs)



Is it proxied? i.e. behind NGINX?



 



Wireshark dump of a connection attemp while it's dead would really help.




Sent: Wednesday, April 03, 2019 at 11:59 AM
From: "Jakub Narolewski" 
To: "interest@qt-project.org" 
Subject: [Interest] QWebSocketServer - server randomly stops accepting connections





I have this one, strange problem with QWebSocketServer that is driving me insane.

My project is a very simple, websocket-based online game server. It uses Qt SQL modules and makes use of some light QEvent'ing.

Up until recently I used uWebSockets to drive my wss communications. To make matters simpler to me I decided to reimplement 'network' part of the application using Qt native module - QWebSocketServer.

It generally works nice - it survives my naive fuzzing tech and cleanly integrates with Qt's event loop.

 

But here is the thing.

 

It randomly, without any error, stops accepting incoming connections. This is VERY hard for me to debug. It happens anywhere between 8 to about 60ish hours after I start my debian unit with systemctl and is fixed immediately when I restart it's service.

I'm connected to every possible error related signal from QWebSocketServer interface, ssl or otherwise - nothing is emited when this happens.

When I ssh to my server I see nominal CPU and memory usage - no leaks, infinite loops or other fun things.

I recently used QObject's timerEvent to spam some qInfos into sys logs. I log:

 

void i9ms::Server::dumpServerStatus() const

{

    qInfo() << "[Server status]"

    << "isListening:" << m_wsServer->isListening()

    << "hasPendingConnections:" << m_wsServer->hasPendingConnections()

    << "errorString:" << m_wsServer->errorString();

}

 

Right now, at the time of writing this message, the server is 'frozen' for about 5 hours and all I see in logs are lines:

 

Apr 03 16:56:12 vps504293 mrserver_release[22148]: [info    ] [Server status] isListening: true hasPendingConnections: false errorString: ""

 

Problem goes away when I 

Re: [Interest] QWebSocketServer - server randomly stops accepting connections

[Jason H]

What happens when you telnet to it?


Are you getting stuff (SYN_ACK) rom the OS, is the OS resetting (RST) the connection?

Is this listening on localhost, virtual or a physical interface?

Linux is generally bad at power managment and networking and maybe that has something to do with it? There is/was an issue with QNetworkAccessManager which after the task got suspended, would not work anymore (I saw this mostly on mobile OSs)

Is it proxied? i.e. behind NGINX?

 

Wireshark dump of a connection attemp while it's dead would really help.


Sent: Wednesday, April 03, 2019 at 11:59 AM
From: "Jakub Narolewski" 
To: "interest@qt-project.org" 
Subject: [Interest] QWebSocketServer - server randomly stops accepting connections




I have this one, strange problem with QWebSocketServer that is driving me insane.

My project is a very simple, websocket-based online game server. It uses Qt SQL modules and makes use of some light QEvent'ing.

Up until recently I used uWebSockets to drive my wss communications. To make matters simpler to me I decided to reimplement 'network' part of the application using Qt native module - QWebSocketServer.

It generally works nice - it survives my naive fuzzing tech and cleanly integrates with Qt's event loop.

 

But here is the thing.

 

It randomly, without any error, stops accepting incoming connections. This is VERY hard for me to debug. It happens anywhere between 8 to about 60ish hours after I start my debian unit with systemctl and is fixed immediately when I restart it's service.

I'm connected to every possible error related signal from QWebSocketServer interface, ssl or otherwise - nothing is emited when this happens.

When I ssh to my server I see nominal CPU and memory usage - no leaks, infinite loops or other fun things.

I recently used QObject's timerEvent to spam some qInfos into sys logs. I log:

 

void i9ms::Server::dumpServerStatus() const

{

    qInfo() << "[Server status]"

    << "isListening:" << m_wsServer->isListening()

    << "hasPendingConnections:" << m_wsServer->hasPendingConnections()

    << "errorString:" << m_wsServer->errorString();

}

 

Right now, at the time of writing this message, the server is 'frozen' for about 5 hours and all I see in logs are lines:

 

Apr 03 16:56:12 vps504293 mrserver_release[22148]: [info    ] [Server status] isListening: true hasPendingConnections: false errorString: ""

 

Problem goes away when I return to uWebSockets-based wss implementation. I let the test server run on it for weeks without problems.

I have tested this on Ubuntu 18.04.2 LTS and Debian 9 both provided 'as-is' from my VPS provider - OVH.

 

I appreciate any feedback or help, have no idea where to go from here. I could possibly try master or 5.12.X branches but this will force me to add 'another configure step' for deployment and is not trival.

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



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

Re: [Interest] android deployment is painfully slow (Windows 10, Qt Creator 4.8.2)

[Jason H]

This is the little play/debug button by application output.
(Screenshot attached - only play is active)

> Sent: Friday, March 29, 2019 at 11:45 AM
> From: "Nikos Chantziaras" 
> To: interest@qt-project.org
> Subject: Re: [Interest] android deployment is painfully slow (Windows 10, Qt 
> Creator 4.8.2)
>
> On 29/03/2019 10:13, Alexander Ivash wrote:
> > Is there any way to avoid re-packaging apk on debugging ? Currently
> > QtCreator seems to be doing something unnecessary every time I press
> > 'debug' even if no changes happened between two debug sessions.
>
> If there's no changes, then you can instead use the "Start Debugging
> Without Deployment" option in the Debug menu.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] android deployment is painfully slow (Windows 10, Qt Creator 4.8.2)

[Jason H]

Minutes? No.

Do you have a virus scanner installed? Can your disable and try that? Maybe 
androiddeployqt is hitting the disk a lot?

Try it on an empty project. Give numbers based on that.

 I deploy frequently and at tolerable speed. Definitely not fast, and the 
number of times I see "deploy to device: no" makes me think it's not optimal.

Also I think i remember seeing that android can now patch apks to cut down on 
deploy time? I don't think qt has implemented this?

> Sent: Friday, March 29, 2019 at 9:08 AM
> From: "Alexander Ivash" 
> To: "interestqt-project.org" 
> Subject: [Interest] android deployment is painfully slow (Windows 10, Qt 
> Creator 4.8.2)
>
> Maybe there is something wrong with my environment, not sure, but it
> takes several minutes to even start debugging! In android studio it
> happens much much faster...
>
> Is there any tricks to speedup this process (besides dropping Windows
> as development platform, because it is not that bad on linux)? If I'm
> not mistaken in the past there were options allowing to upload qt
> libraries once but I don't see anything like this anymore besides 'Use
> Ministro service to install Qt' (which I checked - but it broke the
> build).
>
> Is there any way to avoid re-packaging apk on debugging ? Currently
> QtCreator seems to be doing something unnecessary every time I press
> 'debug' even if no changes happened between two debug sessions.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] 3DTouch under iOS

[Jason H]

Feel free to add a request at: https://bugreports.qt.io/browse/QTBUG-74049

 

 

 

Sent: Monday, March 25, 2019 at 9:47 AM
From: "Jason H" 
To: "Roman Wüger" 
Cc: "Qt Project MailingList" 
Subject: Re: [Interest] 3DTouch under iOS




I don't think this is possible.

 

We've recently had threads about the lack of mobile development as of late. It's not impossible though, I think you'll have to DIY in Objective-C, but that means learning iOS and Objective-C...

 

Sent: Monday, March 25, 2019 at 5:34 AM
From: "Roman Wüger" 
To: "Qt Project MailingList" 
Subject: [Interest] 3DTouch under iOS


Hi,
 

 

Regarding the document https://developer.apple.com/documentation/uikit/peek_and_pop/add_home_screen_quick_actions I only need to add a list in the Info.plist for a static 3D Touch menu

 

But how can I respond to triggered quick actions from a Qt application.

 

Any hints?

 

Regards

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





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



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

Re: [Interest] Build problems, Android app on Qt 5.12.2

[Jason H]

Whenever I've seen that, it's been an issue with config/install path.

For example you're saying API 28, but you're clearly referencing 29

> Sent: Monday, March 25, 2019 at 10:01 PM
> From: "Nelson, Michael" 
> To: "interest@qt-project.org" 
> Subject: [Interest] Build problems, Android app on Qt 5.12.2
>
> Questions:
> 1) What successful tool sets are working for others to build Qt apps for 
> Android?
> 2) Any idea what might be causing the following problem?
>
> Using these tools:
>Qt 5.12.2
>Android SDK 28
>Android SDK Tools 26.1.1
>Android NDK r19c
>Java jdk1.8.0_172
>
> androiddeployqt fails:
>
> :compileDebugAidl FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':compileDebugAidl'.
> > java.io.IOException: com.android.ide.common.process.ProcessException: Error 
> > while executing process 
> > C:\Users\nelson\AppData\Local\Android\Sdk\build-tools\29.0.0-rc1\aidl.exe 
> > with arguments ...
>
> Thanks,
> Mike
>
> Please be advised that this email may contain confidential information. If 
> you are not the intended recipient, please notify us by email by replying to 
> the sender and delete this message. The sender disclaims that the content of 
> this email constitutes an offer to enter into, or the acceptance of, any 
> agreement; provided that the foregoing does not invalidate the binding effect 
> of any digital or other electronic reproduction of a manual signature that is 
> included in any attachment.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] 3DTouch under iOS

[Jason H]

I don't think this is possible.

 

We've recently had threads about the lack of mobile development as of late. It's not impossible though, I think you'll have to DIY in Objective-C, but that means learning iOS and Objective-C...

 

Sent: Monday, March 25, 2019 at 5:34 AM
From: "Roman Wüger" 
To: "Qt Project MailingList" 
Subject: [Interest] 3DTouch under iOS


Hi,
 

 

Regarding the document https://developer.apple.com/documentation/uikit/peek_and_pop/add_home_screen_quick_actions I only need to add a list in the Info.plist for a static 3D Touch menu

 

But how can I respond to triggered quick actions from a Qt application.

 

Any hints?

 

Regards

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




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

Re: [Interest] Track global mouse position in QML

[Jason H]

Please forgive me if I don't completely understand...

 

Maybe you want an underlying mouse area, not an overlaynig one? I'd suggest you just move the MouseArea in the file.

You can always use an overlaying one and translate the mouse events to the child, if there is one. This is what I do for a sample drawing app I have:


In TouchTestRect.qml:

function dispatchTouchEvent(x,y) {
var c = childAt(x,y);
var typename =  "" + c;

var box;

if (c && (typename.startsWith("QQuickRow") || typename.startsWith("QQuickColumn"))) {
	var point = mapToItem(c, x, y);
	box = c.childAt(point.x, point.y);
	typename =  "" + box;
} else if(typename.startsWith("TouchHitBox_QMLTYPE")) {



}

...

}

 

then:

MouseArea {

anchors.fill: parent

onMouseXChanged: {

touchTestRect.dispatchTouchEvent(mouseX, mouseY)

}

onMouseYChanged: {

touchTestRect.dispatchTouchEvent(mouseX, mouseY)

}
}




Sent: Thursday, March 21, 2019 at 7:50 AM
From: "René Hansen" 
To: interest 
Subject: [Interest] Track global mouse position in QML


Hi all,
 

 

I want to track mouse movement within my entire application window, because I need to show/hide/move items around where my cursor is at certain times. (Think e.g. custom cursor)

I can do it easily by filling the entire window with a MouseArea and handle onPositionChanged. The problem is that any mouse sensitive inputs underneath, then get's blocked by the overlaying MouseArea. E.g. a TextField that is usually highlighted on hover and clickable, no longer receives any mouse events.

Is there any straightforward solution to this?

I know QQuickWindow has a mouseMoveEvent, but that doesn't seem to be exposed in QML and if I can avoid subclassing and exposing a custom class, I'd rather do that.


Cheers,

 

René Hansen

___ 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] Qt::GlobalColor to pixel value

[Jason H]

What is the simplest way to go from:

QList pallette 
{Qt::black,Qt::red,Qt::darkRed,Qt::green,Qt::darkGreen,Qt::blue,Qt::darkBlue,Qt::cyan,Qt::darkCyan,Qt::magenta,Qt::darkMagenta,Qt::yellow,Qt::darkYellow};

To a pixel QRgb?

image.setPixel(x,y, pallette[5]);

The .toRgb() of QColor does not actually return a QRgb, instead it converts the 
color to RGB representation internally.

I've hacked this:
uint toRgb(const QColor ) {
return qRgb(c.red(), c.blue(), c.green());
}

image.setPixel(x,y, toRgb(pallette[5]));

but it seems so obtuse.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QProcess overload slot connection

[Jason H]

> > > perhaps adding a QProcess::notRunning signal is in order? Or at least some
> > > clarification in the docs?
> > 
> > Sorry, no. Just the name of the signal you proposed shows it's a bad idea. 
> > Signals are always named after verbs in the past tense, indicating 
> > something 
> > that happened. A process that wasn't running and still isn't running does 
> > not 
> > indicate something that happened. You're proposing a signal to show that 
> > nothing happened, which is not something we want for signals.
> 
> I don't consider the request unreasonable. It's effectively an "I am done
> with this task, you may ask me whether it was successful or what failed
> if you really insist" kind of notification that's "good enough" for quite
> a few use cases.
> 
> As it stands, from a user code perspective, setting up proper communication
> with a QProcess is a bit more boiler-plate than one would naïvely expect
> from a Qt solution...
> 
> > At best, we that signal would be "failedToStart", but that's just the 
> > errorOccurred signal we already have.
> 
> Right.

I agree with both of you. "finished" is ambiguous. "Finished" means the 
QProcess completed. Let's add completed! That won't ever be confusing...

If my English nuance is right, "completed" would connotate it did what was 
intended where as "finished" would just mean done. "I'm finished with borrowing 
the tool, having completed my work with it" 

The fact remains that the developer intention is "when this is over by any 
means, exit the event loop" is not plainly conveyed by the API.

At a minimum the docs should elaborate that finished() only happens after 
started, and started only happens if the... process is scheduled?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QProcess overload slot connection

[Jason H]

> > Because the NotRunning will occur always, and immediately, and finished
> > won't. Failed command:
> > stateCanged QProcess::Starting
> > stateCanged QProcess::NotRunning
> > // no finished!
> 
> Good catch. A process that didn't start can't finish.
> 
> Another way would be to waitForStarted() before entering the loop. Unlike the 
> other waitFor functions, waitForStarted can be relied upon to finish rather 
> quickly, since it only depends on the current thread anyway. If it takes 
> long, 
> then it's because the entire system is swapping hard and taking time to do 
> everything.

From an API perspective, I think most people, when connecting to 
QProcess::finished, are really looking for a way to do NotRunning, but there is 
not a signal for this.

perhaps adding a QProcess::notRunning signal is in order? Or at least some 
clarification in the docs?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QProcess overload slot connection

[Jason H]

> > What's the "right way" to connect QProcess::finished to QEventLoop::quit?
> 
> The one you listed above.

It turns out that I'm not even using that anymore. 

In the situation that there's a problem, you end up waiting for timeout.
So:
connect(process,QOverload::of(::finished), 
, ::quit);
becomes:
connect(process, ::stateChanged,[=, ](QProcess::ProcessState 
state) {
qDebug() << "stateCanged" << state;
if (state == QProcess::ProcessState::NotRunning) loop.quit();
});

Because the NotRunning will occur always, and immediately, and finished won't.
Failed command:
stateCanged QProcess::Starting
stateCanged QProcess::NotRunning
// no finished!

Successful command:
stateCanged QProcess::Starting
stateCanged QProcess::Running
stateCanged QProcess::NotRunning
finished 0 QProcess::NormalExit

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

[Interest] QProcess overload slot connection

[Jason H]

void waitForProcessFinished(QProcess *process, const QString , int 
timeout) {
QTimer timer;
QEventLoop loop;
connect(, ::timeout, , ::quit);
connect(process, ::finished, , ::quit); // 
can't resolve ::finished

if (timeout > 0 ) {
timer.setSingleShot(true);
timer.start(timeout);

}
process->start(command);
loop.exec();
}


I can't seem to figure this out. There is code online that resolves it as 
above, but there is also code that uses qOverload() but I get:
use of undeclared identifier 'qOverload'

So you say that's only availible for C++14, ok I say:
connect(process, QOverload<>::of(::finished), , 
::quit);

which then gives:
no matching function call to 'of'

QOverload gives an error

This does not give an error, but is also wrong, I think:
connect(process, QOverload::of(::finished), , 
::quit); 


QEventLoop::quit slot does not take any parameters


What's the "right way" to connect QProcess::finished to QEventLoop::quit?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] GStreamer on OSX?

[Jason H]

I am trying to develop a app on my mac that will run on linux, and it uses 
gstreamer. There's a couple routes I could go. If it's a video source, I can 
use Qt's existing support, but there are some advantages to using gstreamer 
directly. I just need stills, no video, so I'm giving that a shot.

There is a OSX package for GStreamer (two actually, runtime and dev).  
https://gstreamer.freedesktop.org/data/pkg/osx/1.15.2/

After installing, I add these lines to the .pro:
macx {
LIBS += -framework GStreamer
}

Qt is supposed to have automatic support for frameworks (and in my experience 
it works)
But when it goes to link, I get:
ld: framework not found GStreamer

It's definitely there. From a command line I try:
$ ld -framework GStreamer
ld: warning: No version-min specified on command line
ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.11
ld: file not found: @rpath/lib/libgstcontroller-1.0.0.dylib for inferred 
architecture x86_64

But:
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib$ ls 
libgstcontroller-1.0.0.dylib
libgstcontroller-1.0.0.dylib*

So it's there. 

Does anyone know what I'm doing wrong? I am wondering if it's me or if somehow 
the GStreamer package is bad?

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

Re: [Interest] Qt WebAssembly caching

[Jason H]

Not sure this will help but I was thinking a Progressive Web App was the way to go. Maybe that is relevant to this, maybe not. But they are "installable". I haven't tried but maybe a PWA with WebAssembly is the way to go?

 

https://medium.com/@amberleyjohanna/seriously-though-what-is-a-progressive-web-app-56130600a093

 

 

 

Sent: Wednesday, March 06, 2019 at 12:06 PM
From: "Alexander Rössler" 
To: interest@qt-project.org
Subject: [Interest] Qt WebAssembly caching




Hello Qt WA devs,
 

I have noticed that Qt WA needs to load and recompile every time I start the browse to the location of the application.

 

On the other hand, the WebAssembly Tanks demo seems to be cached and doesn't need to reload https://webassembly.org/demo/Tanks/.

 

I've also found a blog post about caching WebAssembly from a PDF reader toolkit (https://pspdfkit.com/blog/2018/optimize-webassembly-startup-performance/#compiling-and-caching).

 

I think it would be great if Qt WA also supports caching as the loading and especially compile times are relatively high, especially on mobile devices.

 

Best regards,

Alex



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



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

Re: [Interest] CBOR Questions

[Jason H]

> > So the protocol it expects to work with assumes a message-based upper bound,
> > and of trivial size. This is not good.  In light of this, I would suggest a
> > QCborDataStream class that implements efficient parsing.
> 
> No needed. You simply misunderstood the CoAP spec.

In what way? The spec continues:

 Implementation Note:  CoAP's choice of message size parameters works
  well with IPv6 and with most of today's IPv4 paths.  (However,
  with IPv4, it is harder to absolutely ensure that there is no IP
  fragmentation.  If IPv4 support on unusual networks is a
  consideration, implementations may want to limit themselves to
  more conservative IPv4 datagram sizes such as 576 bytes; per
  [RFC0791], the absolute minimum value of the IP MTU for IPv4 is as
  low as 68 bytes, which would leave only 40 bytes minus security
  overhead for a UDP payload.  Implementations extremely focused on
  this problem set might also set the IPv4 DF bit and perform some
  form of path MTU discovery [RFC4821]; this should generally be
  unnecessary in realistic use cases for CoAP, however.)  A more
  important kind of fragmentation in many constrained networks is
  that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited
  to 127 bytes including various overheads); this may motivate
  implementations to be frugal in their packet sizes and to move to
  block-wise transfers [BLOCK] when approaching three-digit message
  sizes.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] CBOR Questions

[Jason H]

> If you know the size of the payload prior to sending it, you can simply send 
> it using CBOR itself. That is, you'll send pairs of unsigned numbers and 
> maps. 
> And both QCborValue and QCborStreamReader need the entire number to have 
> arrived to parse anything: it's always all or nothing. More importantly, 
> QCborValue allocates no memory to store a simple number.
> 
> Or you can decide to store it as a 16- or 32-bit number, with a specific 
> endianness. I'd use  for that, instead of QDataStream. You'd 
> accomplish the same thing, but with far less memory consumption.
> 
> > But short of that, it seems maybe like we need a API that has update() like
> > a Hashing algorithm, and a way to return a list of top-level objects with a
> > function that much implements the loop with the logic you expressed.
> 
> QCborStreamReader can resume reads. The unit test even has that. 
> Unfortunately, it's a bit cumbersome.
> 
> The API for QCborValue will come.

Excellent

> > I'm not a fan of keep "trying until it works". Such protocols are never
> > good. HTTP has content-length, or chunked encoding, but there's no "keep
> > trying until it works" header. I realize this is more an issue with the
> > CBOR standard not having a top-level item sentinel, and not a Qt
> > implementation thing.
> 
> Again, if you know the length from other means, you can just wait until you 
> have it.

Well one end knows it, the sending end that serialized it. This after reading 
the standards, this seems to be an assumption, the the generation of data will 
be on the lower-power leaf nodes of the network. But the lengths need to be 
communicated to the receiver. For CoAP, it is assuming packet length-header 
size is the payload. Thniag, the use of CBOR prefix object to indicate next 
object length is a clever hack. These lengths do vary, but at least you won't 
be parsing whole object trees repeatedly, you'll need at most parse 5 bytes:

1A 00752228 # unsigned(7676456)
19 1938 # unsigned(6456)
18 38 # unsigned(56)

So thanks for the suggestion. I will be implementing it!

Still seems like a length-indicated CBOR data stream would be a good idea 
though. At least with your suggested approach it can all be done in CBOR.

Thanks!

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

Re: [Interest] CBOR Questions

[Jason H]

Perhaps you are correct, but this is an issue with the deserialization, and 
since these objects exist to be transferred (via CoAP, or other means) failing 
to include features that support the typical use cases is a failure of the 
format. We don't have infinite reads on disk because they are block devices, 
infinite socket reads because there is MTU, and it all gets buffered. Knowing 
when an object is complete and parsable. From the spec:
"The code for an encoder or decoder must be able to be compact in order to 
support systems with very limited memory, processor power, and instruction 
sets."

So the approved way we have to repeatedly attempt to deserialize on "systems 
with very limited [...] processor power"?

So I looked at the CoAP protocol, and it says:
"The payload data extends from after the marker to the end of the UDP 
   datagram, i.e., the Payload Length is calculated from the datagram size."
...
" CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously needs to fit within a single IP datagram.
   If the Path MTU is not known for a destination, an IP MTU of 1280
   bytes SHOULD be assumed; if nothing is known about the size of the
   headers, good upper bounds are 1152 bytes for the message size and
   1024 bytes for the payload size."

So the protocol it expects to work with assumes a message-based upper bound, 
and of trivial size. This is not good.  In light of this, I would suggest a 
QCborDataStream class that implements efficient parsing. 





> Sent: Wednesday, March 06, 2019 at 10:12 AM
> From: "Jérôme Godbout" 
> To: "Jason H" , "Thiago Macieira" 
> Cc: "interest@qt-project.org" 
> Subject: RE: [Interest] CBOR Questions
>
> I think the CBOR is the (de)serialization, the length and CRC or any other 
> features like that is part of your transport protocol and not the CBOR 
> itself. You need to transfer the whole data first and then pass it to CBOR 
> deserialization when all data is received, you could also split with start 
> delimiter. I think you want to mix 2 different layers.
> 
> -Original Message-
> From: Interest  On Behalf Of Jason H
> Sent: March 6, 2019 9:50 AM
> To: Thiago Macieira 
> Cc: interest@qt-project.org
> Subject: Re: [Interest] CBOR Questions
> 
> 
> 
> > Sent: Tuesday, March 05, 2019 at 11:42 PM
> > From: "Thiago Macieira" 
> > To: interest@qt-project.org
> > Subject: Re: [Interest] CBOR Questions
> >
> > On Tuesday, 5 March 2019 11:09:52 PST Jason H wrote:
> > > It seems the simplest, most reliable way to implement complete reads 
> > > is to serialize the QByteArray data in a QDataStream. Unfortunately 
> > > it looks like CBOR types do not have QDataStream support? If I were 
> > > to request anything in terms of new API that would probably be it.
> > 
> > The simplest is to use the QCborValue::fromCbor overload that takes a 
> > QByteArray (your buffer) and QCborParserError. Every time you receive 
> > data, you try to parse and then you check the error
> >  - if it's QCborError::EndOfFile, wait for more data
> >  - if it's QCborError::NoError, remove "offset" bytes from the beginning of 
> >the buffer and process the loaded map
> >  - if it's anything else, give up
> 
> That seems extremely CPU wasteful. While a QDataStream would know exactly 
> when all the bytes are there and would parse the object in one go. 
> 
> But short of that, it seems maybe like we need a API that has update() like a 
> Hashing algorithm, and a way to return a list of top-level objects with a 
> function that much implements the loop with the logic you expressed. 
> 
> I'm not a fan of keep "trying until it works". Such protocols are never good. 
> HTTP has content-length, or chunked encoding, but there's no "keep trying 
> until it works" header. I realize this is more an issue with the CBOR 
> standard not having a top-level item sentinel, and not a Qt implementation 
> thing. 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] CBOR Questions

[Jason H]

> Sent: Tuesday, March 05, 2019 at 11:42 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] CBOR Questions
>
> On Tuesday, 5 March 2019 11:09:52 PST Jason H wrote:
> > It seems the simplest, most reliable way to implement complete reads is to
> > serialize the QByteArray data in a QDataStream. Unfortunately it looks like
> > CBOR types do not have QDataStream support? If I were to request anything
> > in terms of new API that would probably be it.
> 
> The simplest is to use the QCborValue::fromCbor overload that takes a 
> QByteArray (your buffer) and QCborParserError. Every time you receive data, 
> you try to parse and then you check the error
>  - if it's QCborError::EndOfFile, wait for more data
>  - if it's QCborError::NoError, remove "offset" bytes from the beginning of 
>the buffer and process the loaded map
>  - if it's anything else, give up

That seems extremely CPU wasteful. While a QDataStream would know exactly when 
all the bytes are there and would parse the object in one go. 

But short of that, it seems maybe like we need a API that has update() like a 
Hashing algorithm, and a way to return a list of top-level objects with a 
function that much implements the loop with the logic you expressed. 

I'm not a fan of keep "trying until it works". Such protocols are never good. 
HTTP has content-length, or chunked encoding, but there's no "keep trying until 
it works" header. I realize this is more an issue with the CBOR standard not 
having a top-level item sentinel, and not a Qt implementation thing. 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] CBOR Questions

[Jason H]

> Sent: Tuesday, March 05, 2019 at 1:23 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] CBOR Questions
>
> On Tuesday, 5 March 2019 09:13:29 PST Jason H wrote:
> > > The parser will tell you when it's done. Both QCborStreamReader and
> > > QCborValue will read exactly one top-level value from the byte array or
> > > QIODevice and return it to you. If you have more than one value, only the
> > > first one will be read. It's up to you to decide to read more, if your
> > > protocol or file format implied that.
> > 
> > Ok, so this sounds like as long as my top-level is a QCborMap, then I should
> > get the complete map, or nothing at all. Given: 
> 
> No, you will get a partial map. My point is that you will never get more than 
> one top-level QCborValue from the parsing, but whether it's complete or not 
> can only be inferred by looking at the parser's error status.
> 
> > A1# map(1)
> >63 # text(3)
> >   6D6170  # "map"
> >A3 # map(3)
> >   61  # text(1)
> >  61   # "a"
> >   19  # unsigned(65535)
> >   61  # text(1)
> >  62   # "b"
> >   20  # negative(0)
> >   61  # text(1)
> >  63   # "c"
> >   61  # text(1)
> >  66   # "f"
> > 
> > I should get the entirety of it in one read?
> 
> If all the bytes are available when you parse, yes. But if some bytes are 
> missing, you'll find that elements will be missing too. For example, if the 
> last three or four bytes are missing, you'll see the inner QCborMap with a 
> size() == 2, despite the stream clearly saying it should have had 3 items.
> 
> DO NOT rely on how the parser currently returns incomplete data. That will 
> change in the future. I'll probably insert some elements at the end to 
> indicate that the parsing is incomplete, so when resuming is possible, I can 
> find out where to continue resuming from.
> 
> > > If there's less than one full value, you'll get a parsing error. Both
> > > classes will return the partially-read value to you, but how complete
> > > that will be is really dependent on what they could make of the content.
> > > QCborStreamReader can resume parsing when you have more data (call
> > > addData() or reparse()), while QCborValue cannot yet. I have an idea how
> > > to implement that but haven't yet.
> > However if byte 0 was A2 (map(2)) that would be partial read.
> 
> Yes. And like above, the returned top QCborMap would indicate size() == 1.
> 
> > > > Fundamentally I am sending 256-1024 byte objects around which correspond
> > > > to
> > > > a QVariantMap, so ideally I would like to do: QCborMap map =
> > > > QCborValue::fromDevice(socket).toMap();
> > > > if (map.size()==0) { /* partial or no object read, retry on next
> > > > ReadyRead
> > > > */ } or
> > > > QCborMap map = QCborValue::fromByteArray(socket, ).toMap(); /*
> > > > modifies bytearray on successful decode to start at next object */
> > > 
> > > Right now, because QCborValue cannot resume parsing, you need to perform
> > > your own buffering. If you told it to read from a sequential QIODevice
> > > (like a socket) and the contents are incomplete, you won't be able to
> > > parse again, as the bytes will have been read from the socket.
> > 
> > So I'll need an application level buffer, ok.
> 
> Yes. When I have a chance to implement the parse-resuming functionality, I'll 
> post here to get feedback.

Thank you Thiago.

It seems the simplest, most reliable way to implement complete reads is to 
serialize the QByteArray data in a QDataStream. Unfortunately it looks like 
CBOR types do not have QDataStream support? If I were to request anything in 
terms of new API that would probably be it. 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] CBOR Questions

[Jason H]

Questions embedded below.

> Sent: Tuesday, March 05, 2019 at 11:33 AM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] CBOR Questions
>
> On Tuesday, 5 March 2019 08:15:40 PST Jason H wrote:
> > I am looking at adapting some code to move from JSON/packed data to CBOR.
> > However the first question I have is how do I know when a CBOR object is
> > done?  If I have multiple or partial CBOR objects in a QByteArray how do I
> > handle that? What if it's coming in through a QIODevice? With JSON I could
> > just look for a } of the same stack level (0) and know the object was done.
> >  How is this handled in Qt/CBOR?
> 
> The parser will tell you when it's done. Both QCborStreamReader and 
> QCborValue 
> will read exactly one top-level value from the byte array or QIODevice and 
> return it to you. If you have more than one value, only the first one will be 
> read. It's up to you to decide to read more, if your protocol or file format 
> implied that.

Ok, so this sounds like as long as my top-level is a QCborMap, then I should 
get the complete map, or nothing at all. Given:
A1# map(1)
   63 # text(3)
  6D6170  # "map"
   A3 # map(3)
  61  # text(1)
 61   # "a"
  19  # unsigned(65535)
  61  # text(1)
 62   # "b"
  20  # negative(0)
  61  # text(1)
 63   # "c"
  61  # text(1)
 66   # "f"

I should get the entirety of it in one read?

> If there's less than one full value, you'll get a parsing error. Both classes 
> will return the partially-read value to you, but how complete that will be is 
> really dependent on what they could make of the content. QCborStreamReader 
> can 
> resume parsing when you have more data (call addData() or reparse()), while 
> QCborValue cannot yet. I have an idea how to implement that but haven't yet.

However if byte 0 was A2 (map(2)) that would be partial read.

> > Fundamentally I am sending 256-1024 byte objects around which correspond to
> > a QVariantMap, so ideally I would like to do: QCborMap map =
> > QCborValue::fromDevice(socket).toMap();
> > if (map.size()==0) { /* partial or no object read, retry on next ReadyRead
> > */ } or
> > QCborMap map = QCborValue::fromByteArray(socket, ).toMap(); /*
> > modifies bytearray on successful decode to start at next object */
> 
> Right now, because QCborValue cannot resume parsing, you need to perform your 
> own buffering. If you told it to read from a sequential QIODevice (like a 
> socket) and the contents are incomplete, you won't be able to parse again, as 
> the bytes will have been read from the socket.

So I'll need an application level buffer, ok.

> If you use the QByteArray overload of QCborValue::fromCbor, the number of 
> bytes used to parse will be stored in the QCborParserError output parameter 
> (offset member). In fact, you should use that parameter to determine whether 
> the returned QCborValue is complete or not: if the error member is NoError or 
> EndOfFile. It's entirely possible that the returned object *looks* complete 
> but isn't.

That's good to know.

Many thanks!

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

[Interest] CBOR Questions

[Jason H]

I am looking at adapting some code to move from JSON/packed data to CBOR. 
However the first question I have is how do I know when a CBOR object is done?  
If I have multiple or partial CBOR objects in a QByteArray how do I handle 
that? What if it's coming in through a QIODevice? With JSON I could just look 
for a } of the same stack level (0) and know the object was done.  How is this 
handled in Qt/CBOR?

Fundamentally I am sending 256-1024 byte objects around which correspond to a 
QVariantMap, so ideally I would like to do:
QCborMap map = QCborValue::fromDevice(socket).toMap();
if (map.size()==0) { /* partial or no object read, retry on next ReadyRead */ }
or 
QCborMap map = QCborValue::fromByteArray(socket, ).toMap(); /* 
modifies bytearray on successful decode to start at next object */


I am not using indeterminate length objects.


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

[Interest] Python support in QtCreator 4.9

[Jason H]

I was just taking a look at the beta, and am sharing my findings.

1. it looks like there isn't a way to import an existing python project?
1a. With an existing project how do I configure a .pyproject file, including 
specify the file with main / QApplication / entry point?
 I cannot find any documentation on the file format.

2. I also created and selected the default Qt for Python - Window project and 
hit run, and I got:
15:25:00: Starting /usr/bin/python 
/Users/jhihn/Projects/test_pythonwindow/main.py...

Traceback (most recent call last):
File "/Users/jhihn/Projects/test_pythonwindow/main.py", line 3, in 
from PySide2.QtWidgets import QApplication, QMainWindow
ImportError: No module named PySide2.QtWidgets
15:25:00: /usr/bin/python exited with code 1

But if I run it from the command line it works: 
python main.py # works

3. Starting QtCreator is slow. I get a beach ball and then a Secchi disk. Takes 
about 10 seconds.

4. Unfortunately all python projects will be called "main" in the project 
explorer.
Maybe the entry point should be $1.py where $1 is the name of the directory? 
i.e. test_pythonwindow 

5. How do I specify python3 for a project? It seems to default to python 2?
Python 2 will be dead in 2020. Also, I have python code that uses async/await, 
so I need Python3

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

[Interest] Adding/Tweaking camera support

[Jason H]

I have a USB camera that does not work with Qt. I'm not sure I should file a 
bug just yet, as it's not really a standard camera. Below is the code and the 
output. How can I go about diagnosing the issue? It's detected and it uses 
gstreamer/v4l.  The error messages aren't that informative. 


import QtQuick 2.12
import QtQuick.Window 2.12
import QtMultimedia 5.12

Window {
visible: true
width: 640
height: 480
title: qsTr("Hello World")
Camera {
id: camera
}
VideoOutput {
source: camera
anchors.fill: parent
}
Component.onCompleted: 
console.log(JSON.stringify(QtMultimedia.availableCameras))
}

Which produces the following output:

QML debugging is enabled. Only use this in a safe environment.
qml: [{"deviceId":"/dev/video0","displayName":"DFK 
27AUJ003","position":0,"orientation":0}]
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
libv4l2: error set_fmt gave us a different result then try_fmt!
CameraBin error: "Device '/dev/video0' cannot capture in the specified format"

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

Re: [Interest] iPhone XS App area

[Jason H]

Thanks Ekke,

 

I filed: https://bugreports.qt.io/browse/QTBUG-74202

 

 

Sent: Saturday, March 02, 2019 at 10:06 AM
From: "ekke" 
To: "Jason H" 
Cc: interest@qt-project.org
Subject: Re: [Interest] iPhone XS App area



from this bug comment

https://bugreports.qt.io/browse/QTBUG-64574?focusedCommentId=417073=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-417073

 

it's not supported on Android yet and no plans on 5.12.x

 

Am 01.03.19 um 19:39 schrieb Jason H:




So for Android, if that is modified to:


flags: ["ios", "android"].includes(Qt.platform.os) ? Qt.Window | Qt.MaximizeUsingFullscreenGeometryHint : Qt.Window

And the navigation bar is still there and the app is not behind the bar,  that would be a bug? The docs don't mention Navigation bar:

'''

Informs the window system that when maximizing the window it should use as much of the available screen geometry as possible, including areas that may be covered by system UI such as status bars or application launchers. This may result in the window being placed under these system UIs, but does not guarantee it, depending on whether or not the platform supports it. When the flag is enabled the user is responsible for taking QScreen::availableGeometry() into account, so that any UI elements in the application that require user interaction are not covered by system UI.

'''

 

But I think it should?


 

Sent: Friday, March 01, 2019 at 12:25 PM
From: "ekke" 
To: interest@qt-project.org
Subject: Re: [Interest] iPhone XS App area



Am 01.03.19 um 18:06 schrieb Jason H:


I have an app and the LaunchScreen on the XS/XS Max shows up full-full-screen  but then the Qt app only goes full-screen, with the phone reaining the area for home button and the status bar.

What do I need to do to get Qt to take the full area? My code worked for the X
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest



so this doesn't work for XS/XS Max ?

flags: Qt.platform.os === "ios"? Qt.Window | Qt.MaximizeUsingFullscreenGeometryHint : Qt.Window





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











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

Re: [Interest] iPhone XS App area

[Jason H]

It does indeed work!

 

Thanks!

 

Sent: Friday, March 01, 2019 at 12:52 PM
From: "Nuno Santos" 
To: ekke 
Cc: interest@qt-project.org
Subject: Re: [Interest] iPhone XS App area


It works with Qt 5.12
 

On 1 Mar 2019, at 17:25, ekke <e...@ekkes-corner.org> wrote:
 


Am 01.03.19 um 18:06 schrieb Jason H:


I have an app and the LaunchScreen on the XS/XS Max shows up full-full-screen  but then the Qt app only goes full-screen, with the phone reaining the area for home button and the status bar.

What do I need to do to get Qt to take the full area? My code worked for the X
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest



so this doesn't work for XS/XS Max ?

flags: Qt.platform.os === "ios"? Qt.Window | Qt.MaximizeUsingFullscreenGeometryHint : Qt.Window

 

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



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



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

[Interest] iPhone XS App area

[Jason H]

I have an app and the LaunchScreen on the XS/XS Max shows up full-full-screen  
but then the Qt app only goes full-screen, with the phone reaining the area for 
home button and the status bar.

What do I need to do to get Qt to take the full area? My code worked for the 
X
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] using a custom class as parameter of signal/slot, used in QML

[Jason H]

Check out qtmultimedia/examples/multimedia/video/qmlvideofilter_opencl fo the filter result types. I think that's what you want?

 

I find it easier to code and work with to just rely on QVariant conversion. QVariantList and QVariantMap are transparently converted to JS Objects. 

 

Sent: Friday, March 01, 2019 at 6:43 AM
From: "Sylvain Pointeau" 
To: "Qt Project" 
Subject: [Interest] using a custom class as parameter of signal/slot, used in QML




Dear all,

 

I understood how to use a struct / simple class as a parameter of a signal / slot, and it works well by value.

 

However as soon as we have to declare the type for QML, it is not good anymore.

It seems that it must be derived from QObject and passed by pointer.

 



Do I understand well that the QML world does only accept pointers on QObject?

 



However I don't understand, who owns the pointer of the custom class (derived from QObject) and who actually deletes it?

(I tried a sharepointer but QML does not know how to handle it)

 

Do you have any idea?

 

Best regards,

Sylvain

 

 


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


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

Re: [Interest] Fwd: vs. Flutter

[Jason H]

Good finds Markus! This makes me insanely happy. 
I've filed at least a bug on notifications before, but it went nowhere. 
But 74049 at least acknowledges that there's a difference from where it is, to 
where it should be.

> Sent: Thursday, February 28, 2019 at 1:39 AM
> From: "Markus Maier" 
> To: interest 
> Subject: Re: [Interest] Fwd: vs. Flutter
>
> I stumbled upon these two EPIC's in JIRA today - the first was
> recently updated, the second one is two days old now:
> https://bugreports.qt.io/browse/QTBUG-72086
> https://bugreports.qt.io/browse/QTBUG-74049
> 
> So while there is currently no commitment to start a bigger
> development task, it seems that this thread here triggered some active
> research inside TQtC how mobile support can be improved. Which is a
> good thing IMHO.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

> Sent: Wednesday, February 27, 2019 at 2:59 PM
> From: "Richard Weickelt" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Fwd: vs. Flutter
>
> > Your every response has indicated this will not happen, just that mobile
> > will follow the other platforms. I don't understand why Qt won't commit
> > to adding the missing Mobile APIs.
> The company is a joint stock company with the sole purpose of making as much
> profit as possible and filling the pockets of its owners.

So this is the best reply so far. I just wish it was more than speculation.

> I guess someone in TQtC has done the math and came to the conclusion that
> they could make much more profit by investing their limited resources in
> growth markets like Industrial & Automotive. Mobile apps are probably a
> mature business and the marketing department doesn't expect any more growth
> there, at least no growth in their market share. This means that the cow
> will be milked and only maintained.

A very valid point. But there's a bit of chicken and egg. They are a mature 
business, but everyone expects iOS and Android availability at launch. Qt is
the best API (so far) to deliver this. However there is a bit of chicken and 
egg. If you build it, they will come, but you want to know that they will
come before you build it. QML is dead-simple and the best way to make an
app, but then you run into these missing APIs and you're in a world of hurt. 
One moment cross-platform as can be, playign video, then writing ObjectiveC 
to keep the screen from locking. It's a combination of both extremes.

> In addition, TQtC may not be able to keep up with the big players who are
> constantly pushing new programming languages and frameworks into the market.
> Simply because the big players have a multiple of manpower and don't have to
> earn any money with their frameworks. Google & co earn a lot of money with
> every sold app anyway. TQtC doesn't have this opportunity.

This really isn't how I see it. The platforms have reached maturity and what
we're after is only the missing bits - device control and notifications - 
that have been standard on smart phones for 10+ years. I don't expect that 
anyone expects Qt to be cutting edge.

> But what I can recommend, and this is the special thing about TQtC: Submit
> patches because the product is open source and the developers are very
> responsive. Stories in JIRA with suggestions and wishes are in my experience
> like write accesses to /dev/null. You have to do it yourself. Once you've
> overcome this hurdle, you usually get a decent code review and constructive
> feedback.
> 
> Of course, this is all pure speculation. ;-)

And reasonable speculation at that. I just I wish it weren't, and we could 
have clarity on this.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

Ok, thanks for clarifying that.

It's not just me though, there are *many* people using Qt that have +1d me and 
stated that they agree with me. Your customer survey reported 20% using Mobile. 
I'm just very vocal about it. I've done many Mobile apps in Qt, each with their 
own constellation of features that Qt does not cover. However as someone with 
extensive linux experience, learning Android is it's own thing. Activities and 
BroadcastReceivers, all in Java. The best way to manage that is with JNI, which 
is it's own beast... Once you get that working, then comes the iOS version, 
which is completely separate concepts and technologies. 

Again, we're not looking to every possible API to be supported, just the common 
ones that we all use, that are an essential part of the mobile experience. The 
80/20 proposition. 

My expectation is as follows: That a developer new to Qt, can create an app in 
QML on one platform and then have it "just work" by adding the other iOS or 
Android kit. This is mostly realized as long as you're just talking about 
putting things on the screen. But as soon as you want to do things like Push 
Notifications (or even Local Notifications) you're into a world of pain. The 
thing is, there is a huge amount of overlap. We just want the overlapping parts 
covered. It's not an unreasonable ask for a cross platform UI.

You say you're "investing in and improving" Mobile. I just don't see it. I've 
been actively using Qt on mobile since 5.4. I've gone over the release notes 
from each release and they are minor. iOS got some accessibility stuff, Android 
got Services. There have been efforts to keep things working, but nothing 
really new has been added. 

5.2 
- iOS/Android platforms added
In terms of big picture:
5.3 
-iOS platform plugin:
-- Support for input methods added.
-- Support for word completion and spell checking added.
-- Support for QClipboard added.
-- "Hide keyboard" gesture added.
- WinRt/8
- Android: Bluetooth
- Positioning: added iOS Android.
5.4
- iOS
-- Accessibility support added. This enables Qt applications to be read by 
VoiceOver.
-- iOS port now uses fat builds with both 32-bit and 64-bit support.
-- Improved support for iPhone6/6+.
-- QtQuick Controls now uses native text selection and popup menus.
-- Default theme fonts now uses Dynamic Type, which is based on user system 
settings.
5.5 - Nothing*
5.6 
- NFC
-- Android
5.7
- Android 
-- Android Services
5.8 - Nothing*
5.9 - Nothing*
5.10 - Nothing*
5.11 - Nothing*
5.12 - Nothing*

*Nothing does not mean nothing at all. The iOS and android modules are clearly 
being maintained, and in a lot of cases iOS and Android platforms is being 
added to existing features. (Like adding android support to Qt3D(5.5), 
Bluetooth LE (5.5), NFC(5.6), etc.) 

We're very happy that Qt is supporting these platforms, but the fear is that 
unless Qt also adds modules for Mobile APIs and delivers what developers expect 
to already exist on the platform, people will choose other toolkits like 
Flutter, ReactNative, Xamarian, and that undermines the mobile investment. I 
*want* Qt to be a top-tier cross-platform solution on mobile. It does some 
things excellently - better than anywhere else. I like not having to learn 
AVFoundation to record or playback audio and video, and then have to learn the 
Android way. Qt has delivered on this exceedingly well. I just want the same 
for the other things that Mobile Developers (and Users) expect. Some things are 
so easy in Qt. But to make a full-fledged Mobile app, Qt falls short and you're 
in a painful world of platform-sepecifics very quickly, which limits the 
adoption of Qt. 

Unless Qt commits to Mobile APIs, I'm just going to switch to Flutter for any 
new apps, and only maintain the Qt ones. I'd rather bite that bullet once 
rather than having to maintain separate code bases for each platform. Thanks to 
this discussion, I've gone from biggest champion of Qt to, well, not an 
advocate on Mobile. I had always held onto hope that these things would get 
done "eventually", but I see now that's not the intent. Maybe this is done to 
protect V-Play, but not having any Qt mobile users won't help them either.

Your every response has indicated this will not happen, just that mobile will 
follow the other platforms. I don't understand why Qt won't commit to adding 
the missing Mobile APIs. 


> Sent: Wednesday, February 27, 2019 at 12:03 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Bernhard B" , "interestqt-project. org" 
> 
> Subject: Re: [Interest] Fwd: vs. Flutter
>
> 
> Hi, 
> 
> No, that is not correct understanding. Mobile is well maintained and 
> developed further - just like the desktop and embedded platforms. 
> 
> We are constantly investing to the mobile and improving it with each release. 
> For all the new features we always aim to get it 

Re: [Interest] Fwd: vs. Flutter

[Jason H]

So am I correct interpreting that Qt on mobile is "finished", and we're on our 
own? (Aside from maintenance) Your statement "often quite straightforward to 
capture in a cross-platform API." seems like a "let them eat cake" moment. I 
really think you are missing the point that these "straightforward" are 
anything but. Who knows Objective C and Java? Not many. Not to mention there 
are enough pain points in moving to another platform already. I believe the 
promise of cross platform Qt is at least to handle the code. 

What would it take to get Qt to commit to supporting device APIs?

> Sent: Tuesday, February 26, 2019 at 11:34 PM
> From: "Tuukka Turunen" 
> To: "Jason H" 
> Cc: "Bernhard B" , "interestqt-project. org" 
> 
> Subject: Re: [Interest] Fwd: vs. Flutter
>
> 
> Hi,
> 
> Like you said, different users have slightly different needs, but there are 
> also many things common. Our focus recently has been to make sure that old 
> and new Qt features work nicely on mobile and in making sure new mobile 
> platforms are supported swiftly. A lot of effort was put to WinRT / UWP to be 
> supported in addition to iOS and Android. It is true that we have not been 
> actively extending the support for device APIs, even though these are often 
> quite straightforward to capture in a cross-platform API.
> 
> Yours,
> 
> Tuukka
> 
> From: Jason H 
> Date: Monday, 25 February 2019 at 11.06
> To: Tuukka Turunen 
> Cc: Bernhard B , "interestqt-project. org" 
> 
> Subject: Re: [Interest] Fwd: vs. Flutter
> 
> Tukka,
> 
> I don't think that there is a single Mobile user that finds your reply 
> adequate.
> 
> It sounds like you're dragging Mobile users along. We need a specific mobile 
> effort to add those mobile specific APIs the platform should have.  Without 
> these APIs, my organization will not be able to justify continued usage of 
> Qt. I have to continually defend our selection of Qt. I've never spoken to 
> someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative 
> are what other developers want to use. I cannot expect to continue to win 
> this fight as Qt falls behind.
> 
> 
> I'm not the only one. I'm just the Squeakiest wheel. I can't really justify 
> another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent 
> pricing) after spending $3000 on Qt.
> 
> I'm begging you to add mobile APIs for:
> - Device Hardware Control
> -- Device Button Integration (volume, etc)
> -- Display Brightness
> -- Volume Control
> -- Screen Control (Full Screen/ Nav Buttons, Wake Lock)
> - Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain 
> point)
> - iOS NFC (starts at iPhone 7, iOS 10)
> 
> These all might seem "not that hard", until you consider I have to do it for 
> 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, 
> Java) This is a huge pain point, considering that is the fundamental problem 
> that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm 
> asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 
> 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and 
> those are pretty basic features. Since that time there were some early iOS 
> accessibilty additions and Android service capabilty. That's it.
> 
> I'm not asking for every possible mobile API to be supported, just a 80/20. 
> Other developers have their own needs, and I'm in favor of us together coming 
> up with that list, and having Qt commit to the top item(s) each release. 
> That's what I mean when I say I want a transparent roadmap for mobile.
> 
> 
> 
> Sent: Monday, February 25, 2019 at 3:20 AM
> From: "Tuukka Turunen" 
> To: "Bernhard B" , "interestqt-project. org" 
> 
> Subject: Re: [Interest] Fwd: vs. Flutter
> Hi,
> 
> I focused mainly in the tooling and cross-platform features in the roadmap 
> blog post. There are other items done as well – more than what reasonably 
> fits into a post. Mobile is an area where we are making constant development, 
> just like we do on desktop and embedded.
> 
> Currently the biggest new investment goes towards tooling and 3D – both of 
> which have some benefits for mobile as well. This of course eats some 
> development capacity away from other things, but it does not mean nothing 
> else would be done.
> 
> Many of our desktop and embedded users also address mobile – in addition to 
> those who address mobile only (or start with mobile). That is the beauty of 
> the cross-platform, with a growing number of users deploying to mob

[Interest] QQuickProviders and proper drawing / caching?

[Jason H]

I've got a custom QQuickImageProvider that I want to have always rendered at 
native resolution.
However on every call requestedSize is QSize(-1, -1) forcing me to use my 
default resolution which then gets scaled, which gives me fuzzy pixels. 

I thought maybe fillMode was an issue, but is it not. Even with an explicit 
height and width in the Image, it never changes from QSize(-1, -1).

Then, I was reading the docs and it says 
'''
Image Caching
Images returned by a QQuickImageProvider are automatically cached, similar to 
any image loaded by the QML engine. When an image with a "image://" prefix is 
loaded from cache, requestImage() and requestPixmap() will not be called for 
the relevant image provider. If an image should always be fetched from the 
image provider, and should not be cached at all, set the cache property to 
false for the relevant Image, BorderImage or AnimatedImage object.
'''

However setting cache: false in the Image element does not change anything.

I've also set 
painter.setRenderHint(QPainter::Antialiasing, false);
painter.setRenderHint(QPainter::SmoothPixmapTransform, false);
In painter and I still get blurry output. I want aliased pixels like in the 
Concentric Circles example.

I've tried various achorings, fillModes, widths and heights.

Does anyone have any pointers? I would expect that the requested size be the 
pixel dimensions of the Image requesting it?

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

Re: [Interest] vs. Flutter

[Jason H]

1. Because my code is my organizations code and I don't have permission to share. (Commercial license) I do however file bugs, minimal examples and such, openly. 

2. Because the code I write is done to satisfy a specific requirement, not Qt in general. Qt does have some of the best APIs, whereas mine is writtenwith one goal: fill the immediate requirement. As a result, it may not be ideally implemented and is not likely to work for others..  I don't know my ObjC or JNI code is proper, it just does what I need and doesn't crash.

3. For things like notifications: I cannot test all the notification providers (AWS, Firebase, etc) on allt he platforms. (i.e. Apple Push Notification data structure does not match any of the others)

3a. We'd need to agree to a standard because you should be able to swap providers and the app not need any changes. Whereas if "Qt" did it, they wouldn't need a committee.

 

I could probably assist an effort by sharing experiences and non-application specific platform code but I would not want to lead/do it. For me, over the last 5 years I've  bit the bullet and hacked the native platform code, so I generally have it. So for me, it's not the biggest deal. But for anyone new to Qt or new to iOS/Android, the moment they learn that Qt doesn't have API coverage for some feature that mobile phones have had for 10 years, I'm sure they get a sinking feeling and vertigo. I get a mini version of it every time I start a new app because the first few hours is spent just getting a skeleton app set up with native feature that I do have code for. 

 

It also doesn't help that Qt does not (and can't, apparently) use Swift, as that code is much more friendly and is becoming plentiful. 

 

In the mean time, my company's staffing is complicated by having to find people knowlegeable in ObjC, Java, C, C++, _javascript_ and threading that needle is increasingly difficult. ObjC, C, C++ are in decline. Maybe this is a way to sell Qt Developer licenses? But I honestly don't think so.

 

So Qt's lack of mobile integration really hurts my organization. 

 

Unless Tukka et al commit to enhancing mobile, I will cease using Qt on Mobile. I think a lot of others will too. If Qt on Mobile is dead, I might as well take my chances with Google. At least people won't ask "What's Google" as they do with Qt.

 



Sent: Tuesday, February 26, 2019 at 12:03 AM
From: "Vlad Stelmahovsky" 
To: interest@qt-project.org
Subject: Re: [Interest] vs. Flutter



if you guys already did some code for mobiles, why dont just contribute back?

On 2/20/19 3:32 AM, Jason H wrote:



There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS.

 

Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted.


 

 


Sent: Tuesday, February 19, 2019 at 8:09 PM
From: "Jérôme Godbout" 
To: "Lorne Sturtevant" , "interest@qt-project.org" 
Subject: Re: [Interest] vs. Flutter




I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess.

 



From: Interest  On Behalf Of Lorne Sturtevant
Sent: February 19, 2019 7:04 PM
To: interest@qt-project.org
Subject: Re: [Interest] vs. Flutter



 


On 2019-02-19 3:22 p.m., Jason H wrote:






Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/



 



This Neptune3 thing, is that something we can use on the phones?



  





I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay).  I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself.   Only took a couple of weeks.  My main point is that Qt can do all of this stuff because the felgo people already did.  It just has to be done by Qt and put into the core.
 

-- 

Lorne Sturtevant

Sum Ergo Cogito

_

Re: [Interest] Fwd: vs. Flutter

[Jason H]

 

1. "Access to media gallery on android" ? If you're taking pictures in Qt and want them to appear in the gallery, you currently have to save them to the gallery and reboot the device. Or implement a Broadcast message to tell Android to scan/add the image.  Yet another thing Qt is missing on mobile...

 

2. Sensors (accelerometer) work. In fact I regularly use most of the sensors. 

 

3. Can you elaborate on your keychain needs?

 


Sent: Monday, February 25, 2019 at 2:48 PM
From: "Bernhard B" 
To: "Jason H" 
Cc: "Tuukka Turunen" , "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter





definitely a +1 from my side.

 

I totally get that there are limited resources and therefore management has to focus on some parts, but if I just look at the Qt mobile functionality (and blend away everything else), I have to agree with Jason. Fortunately I am in a position where I do not "depend" on Qt in any way - I am just a hobby developer that likes to tinker around. So, if it turns out that the mobile development halts, I'll probably migrate my apps away from Qt at some point and/or use a different framework for new projects. But I guess that's a bit more difficult for developers that earn a living with their Qt apps - porting away from Qt then will be a huge pain (and most often not worth it from a business point of view, unless it gets unbearable).

 

The main reason, why I am still with Qt on mobile is, that I know most of Qt's quirks and that I really LOVE QML. Another huge plus is, that I've grown a pretty solid set of

device dependend helper tools/functionalities over the years. Namely:

 

- Notifications (GCM)

- Hardware buttons

- Vibration

- Sensors (Accelerometer)

- Screen Control (keep screen on)

- Keystore/Keychain integration to store credentials

- Access to media gallery on android (I have to check, but I _think_ that functionality is now part of Qt 5.13; at least according to https://wiki.qt.io/New_Features_in_Qt_5.13)

 

If I wouldn't have those ready at my fingertips, I am not really sure whether I would choose Qt again...

I also found it pretty hard (I would almost say impossible) to convince my friends to give Qt a shot. No matter how good Qt's declarative language is, there are certain functionalities that every mobile app developer expects from a framework and unfortunately, Qt's missing quite a few of them :/

 

Cheers,

Bernhard



 


Am Mo., 25. Feb. 2019 um 17:06 Uhr schrieb Jason H <jh...@gmx.com>:




Tukka, 

 

I don't think that there is a single Mobile user that finds your reply adequate.

 

It sounds like you're dragging Mobile users along. We need a specific mobile effort to add those mobile specific APIs the platform should have.  Without these APIs, my organization will not be able to justify continued usage of Qt. I have to continually defend our selection of Qt. I've never spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what other developers want to use. I cannot expect to continue to win this fight as Qt falls behind.

 

 

I'm not the only one. I'm just the Squeakiest wheel. I can't really justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent pricing) after spending $3000 on Qt. 

 

I'm begging you to add mobile APIs for:

- Device Hardware Control

-- Device Button Integration (volume, etc)

-- Display Brightness

-- Volume Control

-- Screen Control (Full Screen/ Nav Buttons, Wake Lock)

- Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain point)

- iOS NFC (starts at iPhone 7, iOS 10)

 

These all might seem "not that hard", until you consider I have to do it for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) This is a huge pain point, considering that is the fundamental problem that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and those are pretty basic features. Since that time there were some early iOS accessibilty additions and Android service capabilty. That's it. 

 

I'm not asking for every possible mobile API to be supported, just a 80/20. Other developers have their own needs, and I'm in favor of us together coming up with that list, and having Qt commit to the top item(s) each release. That's what I mean when I say I want a transparent roadmap for mobile.

 

 

 



Sent: Monday, February 25, 2019 at 3:20 AM
From: "Tuukka Turunen" <tuukka.turu...@qt.io>
To: "Bernhard B" <schluc...@gmail.com>, "interestqt-project. org" <interest@qt-project.org>
Subject: Re: [Interest] Fwd: vs. Flutter




Hi,

 

I focused mainly in the tooling and cross-platform features in the roadmap blog post. There are other items do

Re: [Interest] Replacement for Qt4 QMatrix4x4?

[Jason H]

> Sent: Friday, February 22, 2019 at 4:27 AM
> From: "Christian Gagneraud" 
> Would you consider making arm v8 the minimum requirement for Qt6?

You might anger the raspberry pi people who still use ARM11 in the Pi Zero, and 
other embedded users. I don't see 32bit arm cores going away any time soon, 
particularly in embedded designs. It may be acceptable to cap these at a Qt5 
version. Since ARM v8 is only 7 years old (about the same age of Qt5), I would 
hesitate to leave 32-bit arm out.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

Tukka, 

 

I don't think that there is a single Mobile user that finds your reply adequate.

 

It sounds like you're dragging Mobile users along. We need a specific mobile effort to add those mobile specific APIs the platform should have.  Without these APIs, my organization will not be able to justify continued usage of Qt. I have to continually defend our selection of Qt. I've never spoken to someone who was happy to have to use Qt. Xamarin, Flutter, and ReactNative are what other developers want to use. I cannot expect to continue to win this fight as Qt falls behind.

 

 

I'm not the only one. I'm just the Squeakiest wheel. I can't really justify another $1000/yr (1. that's just Indie, not Enerprise, 2. No transparent pricing) after spending $3000 on Qt. 

 

I'm begging you to add mobile APIs for:

- Device Hardware Control

-- Device Button Integration (volume, etc)

-- Display Brightness

-- Volume Control

-- Screen Control (Full Screen/ Nav Buttons, Wake Lock)

- Notifications (Push & Local, Desktop?) (Probably the dingle biggest pain point)

- iOS NFC (starts at iPhone 7, iOS 10)

 

These all might seem "not that hard", until you consider I have to do it for 3 platforms: OSX, iOS, Android, each with their own tech stack. (ObjC, JNI, Java) This is a huge pain point, considering that is the fundamental problem that Qt claims solve. Except it doesn't... on Mobile. It's not like I'm asking for bleeding edge APIs. Qt started supporting iOS & Android 12th Dec 2013 with Qt 5.2. In the 5 years since, none of the above have made it in and those are pretty basic features. Since that time there were some early iOS accessibilty additions and Android service capabilty. That's it. 

 

I'm not asking for every possible mobile API to be supported, just a 80/20. Other developers have their own needs, and I'm in favor of us together coming up with that list, and having Qt commit to the top item(s) each release. That's what I mean when I say I want a transparent roadmap for mobile.

 

 

 



Sent: Monday, February 25, 2019 at 3:20 AM
From: "Tuukka Turunen" 
To: "Bernhard B" , "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter




Hi,

 

I focused mainly in the tooling and cross-platform features in the roadmap blog post. There are other items done as well – more than what reasonably fits into a post. Mobile is an area where we are making constant development, just like we do on desktop and embedded. 

 

Currently the biggest new investment goes towards tooling and 3D – both of which have some benefits for mobile as well. This of course eats some development capacity away from other things, but it does not mean nothing else would be done. 

 

Many of our desktop and embedded users also address mobile – in addition to those who address mobile only (or start with mobile). That is the beauty of the cross-platform, with a growing number of users deploying to mobile. 

 

Yours,

 

    Tuukka

 


From: Interest  on behalf of Bernhard B 
Date: Friday, 22 February 2019 at 14.28
To: "interestqt-project. org" 
Subject: Re: [Interest] Fwd: vs. Flutter



 



Many thanks to Tuukka for the Qt Roadmap 2019 blog post (https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/) - very much appreciated! 


 



As the mobile part was not explicitly mentioned, I assume that it won't be a focusing area for 2019 then? :/



 



Jean-Michaël Celerier  schrieb am Fr., 22. Feb. 2019, 12:09:





> They even included, scripts to build the app. I'm not sure you have to go quite that far to be compliant, but awesome nevertheless.



 



You explicitely have to:



 



LGPLv3 4. e): Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)



 



And the corresponding GPL part (section 6, emphasis mine) :



The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.





 




 


 



On Fri, Feb 22, 2019 at 11:55 AM René Hansen  wrote:



 



On Fri, 22 Feb 2019, 13:47 Jean-Michaël 

Re: [Interest] Taking back a widget from a QBoxLayout?

[Jason H]

> Sent: Friday, February 22, 2019 at 3:10 PM
> From: "Matthew Woehlke" 
> To: "Jason H" , "interest@qt-project.org" 
> 
> Subject: Re: Taking back a widget from a QBoxLayout?
>
> On 22/02/2019 14.42, Jason H wrote:
> >>> https://doc.qt.io/qt-5/layout.html#tips-for-using-layouts
> > From that: 
> > '''
> > When you use a layout, you do not need to pass a parent when
> > constructing the child widgets. The layout will automatically
> > reparent the widgets (using QWidget::setParent()) so that they are
> > children of the widget on which the layout is installed.
> > 
> > Note: Widgets in a layout are children of the widget on which the 
> > layout is installed, not of the layout itself. Widgets can only have
> >  other widgets as parent, not layouts.> '''
> > 
> > However:
> > '''
> > void QLayout::addItem(QLayoutItem *item)
> > [...]
> > Note: The ownership of item is transferred to the layout, and it's the 
> > layout's responsibility to delete it.
> > 
> > void QLayout::addWidget(QWidget *w)
> > Adds widget w to this layout in a manner specific to the layout. This 
> > function uses addItem().
> > '''
> 
> ...but that's talking about a *QLayoutItem*, which is *not* a QWidget
> (or even a QObject). It's a class that encapsulates a "thing" (widget,
> other layour, spacer, ...) that is present in a QLayout.
> 
> Let's say you have widgets P and C, with P having layout L which
> contains C.
> 
> P "owns" C and (AFAIK) L.
> 
> There *also* exists a layout item I. L owns I. I *references*, but does
> not own, C.


I am with you, but confused by "This function uses addItem()." Since addItem is 
used to QLayout*, I don't see how this is possible?

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

Re: [Interest] Taking back a widget from a QBoxLayout?

[Jason H]

> Sent: Friday, February 22, 2019 at 2:27 PM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Taking back a widget from a QBoxLayout?
>
> Il 22/02/19 19:04, René J.V. Bertin ha scritto:
> >> I am not 100% sure, it's been a while, but I would assume that the layout 
> >> is not the true parent, combined is.
> > The docs aren't exactly clear on this subject, at least not with the sort 
> > of reading glasses I usually have on when I don't exactly want to be 
> > reading them ;)
> 
> Widgets can only have other widgets as parents.
> 
> When you add a widget to a layout, the layout will reparent that widget 
> to the widget the layout is installed onto.
> 
> > https://doc.qt.io/qt-5/layout.html#tips-for-using-layouts
From that: 
'''
When you use a layout, you do not need to pass a parent when constructing the 
child widgets. The layout will automatically reparent the widgets (using 
QWidget::setParent()) so that they are children of the widget on which the 
layout is installed.

Note: Widgets in a layout are children of the widget on which the layout is 
installed, not of the layout itself. Widgets can only have other widgets as 
parent, not layouts.
'''

However:
'''
void QLayout::addItem(QLayoutItem *item)
Implemented in subclasses to add an item. How it is added is specific to each 
subclass.

This function is not usually called in application code. To add a widget to a 
layout, use the addWidget() function; to add a child layout, use the 
addLayout() function provided by the relevant QLayout subclass.

Note: The ownership of item is transferred to the layout, and it's the layout's 
responsibility to delete it.

void QLayout::addWidget(QWidget *w)
Adds widget w to this layout in a manner specific to the layout. This function 
uses addItem().
'''

So the docs are clear as mud. QLayout mentions "ownership" but the tips mention 
"parent". FWIW, I knew QWidgets parented QWidgets, but I don't know what it 
means by "ownership". Typically, "ownership" is talked about w.r.t. Python or 
QML, where the garbage collection schemes differ. It would be nice to amend the 
docs to clarify this.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Taking back a widget from a QBoxLayout?

[Jason H]

> Sent: Friday, February 22, 2019 at 1:04 PM
> From: "René J.V. Bertin" 
> To: "Jason H" 
> Cc: "interest@qt-project.org Interest" 
> Subject: Re: [Interest] Taking back a widget from a QBoxLayout?
>
> On Friday February 22 2019 17:45:05 Jason H wrote:
> 
> >I am not 100% sure, it's been a while, but I would assume that the layout is 
> >not the true parent, combined is.
> 
> The docs aren't exactly clear on this subject, at least not with the sort of 
> reading glasses I usually have on when I don't exactly want to be reading 
> them ;)
> 
> >The "delete combined" will delete child widgets a and b.
> 
> That much is clear, because it takes ownership of the layout (THAT is clearly 
> documented).
> 
> >You need to unparent them, then delete combined. Layouts allocate pixels and 
> >resize things, they don't own them, AFAIK.
> 
> Setting their parent back to what it was (nullptr) did the trick indeed, 
> regardless of who really owned them.
> 
> I guess I didn't try this yet because I'm never certain if taking ownership 
> is really only done through making yourself a parent.
> 

addItem: Note: The ownership of item is transferred to the layout, and it's the 
layout's responsibility to delete it.
removeItem: Note: The ownership of widget remains the same as when it was added.

So addItem parents it as it's own, then removeItem leaves it. No wonder it was 
crashing. This might be a bug? I don't know why removing it would keep the 
parent (the layout) then your subsequent call to delete deleted the widget and 
it's layout, so the parent was left dangling.  I would have expected that the 
parent be nulled out, rather than keep it referencing the layout it had just 
been added to and removed from. Perhaps a Troll can comment?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Taking back a widget from a QBoxLayout?

[Jason H]

> Sent: Friday, February 22, 2019 at 11:27 AM
> From: "René J.V. Bertin" 
> To: "interest@qt-project.org Interest" 
> Subject: [Interest] Taking back a widget from a QBoxLayout?
>
> Hi,
> 
> Consider
> 
> ```
> SomeWidgetClass *a = maybeReturnSomeWidget();
> SomeOtherQWidgetClass *b = maybeReturnSomeOtherWidget();
> 
> QWidget *combined = new QWidget();
> QVBoxLayout *layout = new QVBoxLayout();
> layout->addWidget(a);
> layout->addWidget(b);
> combined->setLayout(layout);
> if (doWeLikeItCombined) {
>   return combined;
> }
> // get back our widgets
> layout->removeWidget(a);
> layout->removeWidget(b);
> delete combined; // deleteLater()?
> return a ? a : b;
> 
> ```
> 
> The test on the combined widget looks at its size, which apparently I cannot 
> get reliably from a->height(), b->width() and family directly.
> I thus need to take back my widgets a and b from the layout and it seems that 
> what I do currently isn't good enough because the code crashes when after I 
> return something other than the combined widget.
> 
> Is this a catch-22 one can get out of?

I am not 100% sure, it's been a while, but I would assume that the layout is 
not the true parent, combined is. The "delete combined" will delete child 
widgets a and b. You need to unparent them, then delete combined. Layouts 
allocate pixels and resize things, they don't own them, AFAIK.


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

Re: [Interest] Replacement for Qt4 QMatrix4x4?

[Jason H]

> On 22/02/2019 04.08, Paolo Angelelli wrote:
> > You aren't telling us much, except that you need to invert it and multiply 
> > points with it.
> > If QtPositioning-private is an acceptable dependency instead of pulling in 
> > eigen (or others),
> > you could probably get away with the private QDoubleMatrix4x4 that is in 
> > there, basically
> > a double QMatrix4x4.
> 
> No... I'm developing *with* Qt. I'm not developing Qt itself :-).
> 
> Mostly, I was surprised that QGenericMatrix has no method to invert the
> matrix. (Obviously such method would be conditional on square matrices,
> but...)

Well I think if you want such things eigen 
(http://eigen.tuxfamily.org/index.php?title=Main_Page) is what you need. 
However, I would love to see Qt incorporate some basic operations. BUt i'm 
unable to articulate what those are right now. I think it would get it's 
tendrils into QImage though, where I do quite a bit of work (image convolutions)


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

Re: [Interest] About subscription issues

[Jason H]

This is definitely a sa...@qt.io question, but if both companies have the same developers, then I don't see why they would need two licenses?

 

It's an uncommon case that could be considered a loophole, as it's licensed per developer. The question is, is they key (company, person) or (person). If I am a contractor do I need a license for each customer, or do I provide my own?

 

I think there is an implicit limit of qt utility being person limited. So one person, two companies, their time is split between them, so 50% *2=1.

 

 

 

Sent: Thursday, February 21, 2019 at 10:13 AM
From: "Minzhang He" 
To: Interest@qt-project.org
Subject: [Interest] About subscription issues




I have 2 LLC companies in the US. The company is only my own. If my two companies sell my own QT development software in the future, can I use only one of the company subscriptions?

 

Of course, because of the pressure of life, I don’t consider buying now, but if I complete the development, I will definitely buy it now.


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


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

Re: [Interest] Fwd: vs. Flutter

[Jason H]

So there are only three licences:

LGPL

Commercial

Commercial Runtime (Boot2Qt)


 

IANAL, but the dynamic/static linking debate is not even settled, even in court. I would say that the spirit of LGPL and existing precedent is that under LGPL you can't modify Qt without releasing it. If you want to modify Qt and not release it, then commerical is the way to go. GPL parts adhere to the dynamic linking which is regarded as permissible by Linus Torvalds, who I consider a subject matter expert.

 

IANAL, YMMV, WYGIWYS, WYSIWYG, etc.

 

 

Sent: Thursday, February 21, 2019 at 9:01 AM
From: "ich" 
To: interest@qt-project.org, "Sylvain Pointeau" , "Qt Project" 
Subject: Re: [Interest] Fwd: vs. Flutter


Thou shall not use sellers opinion as legal correct advice:)
qt.io tends to hide facts and even post wrong "facts"...
 
Am February 21, 2019 1:49:21 PM UTC schrieb Sylvain Pointeau :


 


On Tue, Feb 19, 2019 at 8:30 PM Sylvain Pointeau  wrote:



Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others.


 

Le mar. 19 févr. 2019 à 20:12, ich  a écrit :


Qt is free, too.





 

I received few personal emails to ask me why am I writing that Qt is not free on mobile.

 

I am sorry but this is the message from the Qt company, please show me one official statement that Qt is free to use on mobile.

I would be really glad and finally use Qt instead of looking for alternatives.

 

Best regards,

Sylvain

 

 




 








--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest



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

Re: [Interest] vs. Flutter

[Jason H]

There's not anything I haven't done on mobile in Qt. The problem is everytime I start an app, I copy the 75% from the previous project and it's janky slap-dash of code. I've got to to this 3x for every app, every time. It's iOS, Android, and OSX. What I have works, it's not Troll quality. It is unforunately commercial code. I don't have hot-reload, but notificatons - push and local were working with Firebase on Android and iOS.

 

Yeah, it's a couple weeks to develop all of that, but we're dozens of programmers re-inventing the wheel time and time again. This is not "code less create more". A few weeks of a couple developers and this would be a completely different situation instead person-years are being wasted.


 

 


Sent: Tuesday, February 19, 2019 at 8:09 PM
From: "Jérôme Godbout" 
To: "Lorne Sturtevant" , "interest@qt-project.org" 
Subject: Re: [Interest] vs. Flutter




I did try a bit V-Play, but I did not like the fact I was stuck at a particular Qt version (it was 5.6 when 5.10 was out, last time I checked). Does the new Felgo allow to be used on other versoin and with up to date Qt Creator? that was a real bummer to be stuck with old version. The project seem to be fine aside from that problems. The price is a hard pill to swallow, with Qt 3D I guess the V-Play was less future proof I guess.

 



From: Interest  On Behalf Of Lorne Sturtevant
Sent: February 19, 2019 7:04 PM
To: interest@qt-project.org
Subject: Re: [Interest] vs. Flutter



 


On 2019-02-19 3:22 p.m., Jason H wrote:






Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/



 



This Neptune3 thing, is that something we can use on the phones?



  





I've been following the discussion and it looks like a lot of features of flutter, such as the live reloading, push notification, etc, already exists in felgo (use to be vplay).  I used vplay for awhile, but it got too expensive so I just redid what I was using from their work myself.   Only took a couple of weeks.  My main point is that Qt can do all of this stuff because the felgo people already did.  It just has to be done by Qt and put into the core.
 

-- 

Lorne Sturtevant

Sum Ergo Cogito

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



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

Re: [Interest] vs. Flutter

[Jason H]

Was just reading the blog and it mentions live reloading: https://blog.qt.io/blog/2019/02/18/scaling-large-ui-development-projects-managing-complexities-reference-ui-neptune-3/

 

This Neptune3 thing, is that something we can use on the phones?

 

Sent: Monday, February 18, 2019 at 3:40 PM
From: "René Hansen" 
To: "Jason H" 
Cc: inter...@lists.qt-project.org
Subject: Re: [Interest] vs. Flutter


I've not come across any myself, and have only built a few small things with it a bit for now.

Initial reactions was that it is *leagues* ahead of Qt with regards to developer experience. You're not locked to an IDE, like with QtCreator, and the ui live updates across device, simulators, emulators etc. when you write changes. No need to build and .apk and wait for a build+deploy.

There's no JS involved. It's Dart all the way. It doesn't even ship with a web runtime afaik.

Achitecturally it's similar to Qt, in that they've build a custom renderer on top of Skia, so the whole scene is basically just OpenGL, which makes it really fast.

Component wise, their UI library offers bother Cupertino and Material design out of the box, and from initial impressions, looks to be closer to the original design guidelines than Qt Quick Controls for. e.g. Material.

I haven't tried it out myself yet, but you should be able to reach into native world by using platform channels:

https://flutter.io/docs/development/platform-integration/platform-channels

It's seems like it's quite a ways worse than with Qt though, so there's at least that.


/René
 


On Mon, 18 Feb 2019 at 14:58 Jason H <jh...@gmx.com> 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)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest





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

Re: [Interest] vs. Flutter

[Jason H]

So I think that after all this chatter we have one really solid concrete finding:

 

Findings

#1:

Qt is based on proven, stable technologies, whereas Flutter is based on Dart, a nacent technology with a very small past and a non-transparent future.* Furthermore, Dart does not seem to be any more adept at the needs of Flutter than any other language.

 

I don't know if the "kids these days" will really be into that, as they are very into learning the "latest and greatest" (aka fads).

 

* "non-transparent future" - while no one knows the future at least C++ has the 3 year release cycle. Qt's future is murky though without a dedicated roadmap. 

 

 

 

Sent: Tuesday, February 19, 2019 at 10:14 PM
From: "Fabio Giovagnini" 
To: fro...@tungware.se
Cc: Qt-interest 
Subject: Re: [Interest] vs. Flutter


My two cents. The main topic is: a new language really has to give  an answer to a real need. In my humble opinion  when we talk about programming language, we cannot think to push artificial needs. The community of developers is not a commumitiy of fashion guys. They are professionals working to make money and innovate the market. The tools are not ideological matter but  real tools to work, produce and make value.
So, chancing for changing, only applying the logic "newer is better" is not always a winning choice.

Best regards.

Fabio

 

 


Il giorno mar 19 feb 2019 21:58 Henry Skoglund <fro...@tungware.se> ha scritto:

Hi, totally agree C/C++ will outlive many of these new languages.
It's also most likely _javascript_ will wane off sooner rather than later
due to WebAssembly steadily improving.

Been working/programming for 43 years now, while I fondly remember
Pascal on CP/M from my youth (before C++ was invented), once I switched
to C++ in the early 90's (Visual C++/MFC), C++ always felt as my "home".

Also you could say that good and stable ecosystems for a language takes
decades to arrive, at least one generation of programmers has to come
and go I think. So the peak of C++ will be in the future :-)

Rgrds Henry

On 2019-02-19 21:13, Christoph Feck wrote:
> On 02/19/19 20:47, Jason H wrote:
>> What I've learned is that it's better to stand on the shoulders of
>> giants than to rewrite the universe from scratch. I dream of a say
>> where we can code things and everyone else regardless of platform can
>> run it. I thought this was going to be .Net CLR, or Java VM, but
>> corporate ownership initiatives derailed them (Much like the "You
>> will" ATT ads of the 90s - we got it, but not from ATT). But C/C++
>> runs all more platforms/processors. Linux has come a long way in terms
>> of bringing all CPUs a usable software ecosystem. And this though
>> rather obtuse is one reason to pick Qt - that it'll support any system
>> that can run a C++ compiler. You don't technically need to use QML,
>> you can keep going with C++.
>
> Once upon a time a mother of two curious boys called me, asking me to
> teach them programming. They have no clue what language to start with,
> so I suggested C as a base, to later learn Python, C++, Java (or C#).
> Then some "smart" student told one of the kids "_javascript_ is da future
> of da Internetz". I stopped teaching them after it was suggested to
> stop the C course and swap it for a _javascript_ course.
>
> C/C++ will be relevant in the future. All other languages will come and
> go (no pun intended).
>
> Whether Qt will be relevant in the future lies in the hands of its
> developers. Don't ruin it.
>
> Christoph Feck

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

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



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

Re: [Interest] vs. Flutter

[Jason H]

In 1992 it really, really was. 

 

The real issue nowadays is they only have one event loop forcing generators/async code.

Though WebWorkers are a thing. 


Sent: Tuesday, February 19, 2019 at 10:03 PM
From: "Sylvain Pointeau" 
To: "Christoph Feck" 
Cc: inter...@lists.qt-project.org
Subject: Re: [Interest] vs. Flutter



I am personally not convinced yet about having a _javascript_ VM. It seems to be a bottleneck.


However I see the advantages it brings, but was it really necessary?

 

Le mar. 19 févr. 2019 à 21:15, Christoph Feck <cf...@kde.org> a écrit :

On 02/19/19 20:47, Jason H wrote:
> What I've learned is that it's better to stand on the shoulders of giants than to rewrite the universe from scratch. I dream of a say where we can code things and everyone else regardless of platform can run it. I thought this was going to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them (Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). But C/C++ runs all more platforms/processors. Linux has come a long way in terms of bringing all CPUs a usable software ecosystem. And this though rather obtuse is one reason to pick Qt - that it'll support any system that can run a C++ compiler. You don't technically need to use QML, you can keep going with C++.

Once upon a time a mother of two curious boys called me, asking me to
teach them programming. They have no clue what language to start with,
so I suggested C as a base, to later learn Python, C++, Java (or C#).
Then some "smart" student told one of the kids "_javascript_ is da future
of da Internetz". I stopped teaching them after it was suggested to
stop the C course and swap it for a _javascript_ course.

C/C++ will be relevant in the future. All other languages will come and
go (no pun intended).

Whether Qt will be relevant in the future lies in the hands of its
developers. Don't ruin it.

Christoph Feck

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


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



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

Re: [Interest] vs. Flutter

[Jason H]

I probably would have gone with Python, and avoid pointers, as many languages 
to their best to obfuscate them. But your C was not a bad decision. It is 
lingua franca. :-)

Just remind them that JS was invented in 10 days back in 1992, and standardized 
by a committee that had no business standardizing it. That said, with 
everything targeting JS, it's not a bad decision either.

I'm relatively [adjective] about the new C++ versions. On one hand C++ looks 
strange. The code to map/filter/transform looks nothing like I'd expect 
(transform): 
Actual:
std::vector x = {1, 2, 3, 4, 5};
std::vector y;
std::transform(x.begin(), x.end(), std::back_inserter(y), [](int elem){ return 
elem * elem; });
Expected:
auto y = std::transform(std::vector {1, 2, 3, 4, 5}, [int elem] { return 
elem*elem });

But the new initializer syntax is a joy. 

SFINAE, etc. It creates pretty unreadable code. It takes me several minutes to 
parse a line of modern C++, which violates several software development 
principles in that it should be easy to understand, optimized for reading, 
OTHER Developers, DRY, DR's 10 times harder statement. I've learned that to 
grok C++, you must first realize that you're not writing a program that does 
something, instead you're telling the compiler how to build the program. "Doing 
what you want" is just a "side effect".

I don't know how long C++ can exist with that mentality. The compiler should 
figure out what I mean. Const should be automatically applied where it can 
based on code paths. It's something I do, it's easy to determine, and having it 
auto applied would be just fine. Or maybe have a linter tell you/upgrade it to 
const. 

Qt is attractive because I "code less and create more". I rely on Qt to 
translate the C++ committee's/stdlib output into something usable by 
developers, not language nerds. (Reminder there's more languages than C++, I've 
got to learn Dart now, apparently)

But the new initializer syntax is a joy, at least.


> Sent: Tuesday, February 19, 2019 at 9:13 PM
> From: "Christoph Feck" 
> To: inter...@lists.qt-project.org
> Subject: Re: [Interest] vs. Flutter
>
> On 02/19/19 20:47, Jason H wrote:
> > What I've learned is that it's better to stand on the shoulders of giants 
> > than to rewrite the universe from scratch. I dream of a say where we can 
> > code things and everyone else regardless of platform can run it. I thought 
> > this was going to be .Net CLR, or Java VM, but corporate ownership 
> > initiatives derailed them (Much like the "You will" ATT ads of the 90s - we 
> > got it, but not from ATT). But C/C++ runs all more platforms/processors. 
> > Linux has come a long way in terms of bringing all CPUs a usable software 
> > ecosystem. And this though rather obtuse is one reason to pick Qt - that 
> > it'll support any system that can run a C++ compiler. You don't technically 
> > need to use QML, you can keep going with C++.
> 
> Once upon a time a mother of two curious boys called me, asking me to 
> teach them programming. They have no clue what language to start with, 
> so I suggested C as a base, to later learn Python, C++, Java (or C#).
> Then some "smart" student told one of the kids "JavaScript is da future
> of da Internetz". I stopped teaching them after it was suggested to
> stop the C course and swap it for a JavaScript course.
> 
> C/C++ will be relevant in the future. All other languages will come and
> go (no pun intended).
> 
> Whether Qt will be relevant in the future lies in the hands of its
> developers. Don't ruin it.
> 
> Christoph Feck
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

Qt creator does it for you, just add whatever APIs you need (Android SDK, NDK) or xCode and select the plaftorm above the big Run button in QtCreator.

Launch the Maintence tool, download Qt for the target platform

AFAIK, it is free on Mobile. However... as I've repeatedly stated that I continually find bugs/parity issues between mobile platforms. Having a support contract really helps in this regard. The diffs are not large, but if you're new to a platform, you might not find it as friendly as you'd like. I routinely hack Obj-C and Java to make things work in Qt that should "just work". But getting clued into these foreign platforms can be frustrating. You've got to know a little "too much" about the target platform - For iOS it's your Application Delegate and Obj-C, on Android it's the Activity and JNI. 

 

But most simple apps are as easy as just changing the build target. When it doesn't work, I file a bug. Example: You can take pictures (Camera.capture()) on iOS without a VideoOutput, but you can't do that in Android so you create an invisible one as a work-around. https://bugreports.qt.io/browse/QTBUG-73237 Or that audioRoles are not implemented on the platform. https://bugreports.qt.io/browse/QTBUG-73316 (iOS)

https://bugreports.qt.io/browse/QTBUG-73119 (FIXED, Android) (iOS has a global autio context, so this is less of an issue there, but Android does not, so it's a bigger issue) but the whole diff for Android was 445 lines which is not much. (and the bulk of those lines is enumerating the various audioRole mapping to/from Android)

 

Sometimes it's just not possible (no iOS API for AmbientLight sensor) 

 

As long as you're not digging too much into the platform Qt *will* *just work*. :-)

 

 

Sent: Tuesday, February 19, 2019 at 8:39 PM
From: "ich" 
To: No recipient address
Cc: interest@qt-project.org
Subject: Re: [Interest] Fwd: vs. Flutter

OK, i've no idea about how to deploy to mobile devices,
but what makes you think its not free?
 
Am February 19, 2019 7:30:23 PM UTC schrieb Sylvain Pointeau :


Qt is free on desktop, but it is not free on mobile, which is a real showstopper for me and many others.


 

Le mar. 19 févr. 2019 à 20:12, ich <a...@golks.de> a écrit :


Qt is free, too.

 
Am February 19, 2019 7:04:03 PM UTC schrieb Sylvain Pointeau <sylvain.point...@gmail.com>:



I cannot get it copied in the email, but the code in the section get started has no "new" but I agree with you that it is not "declarative"


 

The positive points about flutter is that it is free, and intellij (IDEA) is so great.

However, it feels too young, and limited to mobile (some are saying that the desktop is coming, but nothing concrete yet)

 

react native (via react xp) seems to be a better alternative for now.

 

Best regards,

Sylvain

 

 

Le mar. 19 févr. 2019 à 19:43, Jason H <jh...@gmx.com> a écrit :





It's still on the home page: https://flutter.io/ "Fast Development"


I operate on the "read at least the first page" premise. That whatever they think is most important should be found there.

 

But losing new doesn't really change my opinion of if it's declarative or not.

 

Thanks for the update/correction though.

 

 


Sent: Tuesday, February 19, 2019 at 1:34 PM
From: "Sylvain Pointeau" <sylvain.point...@gmail.com>
To: "Qt Project" <interest@qt-project.org>
Subject: [Interest] Fwd: vs. Flutter













the "new" is now removed in dart 2.0 so you example is outdated.


 

 

-- Message transféré -
De : Jason H <jh...@gmx.com>
Date : mar. 19 févr. 2019 à 19:25
Objet : Re: [Interest] vs. Flutter
À : Bernhard B <schluc...@gmail.com>
CC : <inter...@lists.qt-project.org>
 



I'm in your offtopic camp.

Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly.

 

Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page:

Widget build(BuildContext context) {

  return new Scaffold (

     appBar: new AppBar ( title: new Text (widget.title), ),

     body: new Center (

        child: new Text( "Button clicked" ...

             ),

     ),

}


 

Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. 

 

 


Sent: Tuesday, February 19, 2019 at 12:55 PM
From: "Bernhard B" <schluc...@gmail.com>
To: "Bob Hood" <bho...@comcast.net>
Cc: "René Hansen" <ren...@gmail

Re: [Interest] vs. Flutter

[Jason H]

https://hub.packtpub.com/is-dart-programming-dead-already/ claims Dart is not 
Dead, just Mostly Dead and that Flutter will save the day... I don't want to 
learn yet another language to learn a toolkit. I know plenty already. C/C++, 
JS, Python, C#, Java, Obj-C, Perl, BASH, (Visual)BASIC, Lua, Ruby, Scala. (I'm 
not including SQL) I previously wrote that everything compiles to JS, and so 
does Dart, apparently LOL. Now everything is better than Perl, but yet another 
language? Given a list of those 12 languages they rejected them all and and 
declared they needed to make another one? It's got a NIH stench about it. 

What I've learned is that it's better to stand on the shoulders of giants than 
to rewrite the universe from scratch. I dream of a say where we can code things 
and everyone else regardless of platform can run it. I thought this was going 
to be .Net CLR, or Java VM, but corporate ownership initiatives derailed them 
(Much like the "You will" ATT ads of the 90s - we got it, but not from ATT). 
But C/C++ runs all more platforms/processors. Linux has come a long way in 
terms of bringing all CPUs a usable software ecosystem. And this though rather 
obtuse is one reason to pick Qt - that it'll support any system that can run a 
C++ compiler. You don't technically need to use QML, you can keep going with 
C++. 

Oh, looks like they are announcing relaunch for Dart, as of a year ago: 
https://sdtimes.com/webdev/google-announces-reboot-programming-language-dart/
Meanwhile they develop Tensorflow in Python?
Android in Java and now Kotlin
Where's Go[lang]
And unit tests for it all?

It's just too easy to invent a language or framework, and too hard to change an 
existing one. Dunning Kruger effect? Every time you create a new language or 
framework, you divide humanity into those who can benefit from your work and 
those who can't. Those who are using your platform or language against those 
who aren't. I'm not against experimenting, but asking other to devs to use your 
unique stuff should be a much bigger ask. Right now we've got Kotlin infecting 
Android/Java for a slightly different syntax than the languages above, no 
material gain. Meanwhile your veteran languages are getting infected with async 
stuff. 



Qt's Mobile problems are just a backlog of ancient mobile platform concepts not 
yet delivered. After that backlog is resolved the maintenance is rather light, 
as mobile devices aren't still moving. Sure FaceID is new, but it works the 
same as TouchId. But these non-delivered concepts are continual pain points for 
its users. 
 
It's very easy for these new toolkits to wrap platform APIs, but Qt remains the 
only one to successfully* abstract them.

* platform parity issues persist.


> Sent: Tuesday, February 19, 2019 at 6:42 PM
> From: "Bob Hood" 
> To: "René Hansen" , "Jason H" 
> Cc: inter...@lists.qt-project.org
> Subject: Re: [Interest] vs. Flutter
>
> On 2/18/2019 7:40 AM, René Hansen wrote:
> > I've not come across any myself, and have only built a few small things 
> > with 
> > it a bit for now.
> >
> > Initial reactions was that it is *leagues* ahead of Qt with regards to 
> > developer experience. You're not locked to an IDE, like with QtCreator, and 
> > the ui live updates across device, simulators, emulators etc. when you 
> > write 
> > changes. No need to build and .apk and wait for a build+deploy.
> >
> > There's no JS involved. It's Dart all the way. It doesn't even ship with a 
> > web runtime afaik.
> 
> I've been studying it for a while now, and I've decided that it will likely 
> be 
> my mobile development language.  I love Qt to death for desktop, but I've 
> never been able to take to it's declarative approach.  I know others swear by 
> it, but it just never fit my brain waves for some reason.
> 
> I saw somebody in this thread moan about it being yet another language to 
> learn.  Putting aside the fact that a robust developer should know more than 
> one, Dart is quite familiar to anybody who has used a modern scripting 
> language (e.g., Python).
> 
> For me personally, Flutter's "feel" just fits mobile better in my mind than 
> Qt.
> 
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Fwd: vs. Flutter

[Jason H]

It's still on the home page: https://flutter.io/ "Fast Development"


I operate on the "read at least the first page" premise. That whatever they think is most important should be found there.

 

But losing new doesn't really change my opinion of if it's declarative or not.

 

Thanks for the update/correction though.

 

 


Sent: Tuesday, February 19, 2019 at 1:34 PM
From: "Sylvain Pointeau" 
To: "Qt Project" 
Subject: [Interest] Fwd: vs. Flutter



the "new" is now removed in dart 2.0 so you example is outdated.


 

 

-- Message transféré -
De : Jason H <jh...@gmx.com>
Date : mar. 19 févr. 2019 à 19:25
Objet : Re: [Interest] vs. Flutter
À : Bernhard B <schluc...@gmail.com>
CC : <inter...@lists.qt-project.org>
 



I'm in your offtopic camp.

Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly.

 

Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page:

Widget build(BuildContext context) {

  return new Scaffold (

     appBar: new AppBar ( title: new Text (widget.title), ),

     body: new Center (

        child: new Text( "Button clicked" ...

             ),

     ),

}


 

Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. 

 

 


Sent: Tuesday, February 19, 2019 at 12:55 PM
From: "Bernhard B" <schluc...@gmail.com>
To: "Bob Hood" <bho...@comcast.net>
Cc: "René Hansen" <ren...@gmail.com>, "Jason H" <jh...@gmx.com>, inter...@lists.qt-project.org










Subject: Re: [Interest] vs. Flutter



> I've been studying it for a while now, and I've decided that it will likely be
my mobile development language.  I love Qt to death for desktop, but I've
never been able to take to it's declarative approach.  I know others swear by
it, but it just never fit my brain waves for some reason.

 



I guess I am one of those persons, who absolutely LOVE Qt's declarative language.

I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML,

I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like

qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet.




 


Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood <bho...@comcast.net>:

On 2/18/2019 7:40 AM, René Hansen wrote:
> I've not come across any myself, and have only built a few small things with
> it a bit for now.
>
> Initial reactions was that it is *leagues* ahead of Qt with regards to
> developer experience. You're not locked to an IDE, like with QtCreator, and
> the ui live updates across device, simulators, emulators etc. when you write
> changes. No need to build and .apk and wait for a build+deploy.
>
> There's no JS involved. It's Dart all the way. It doesn't even ship with a
> web runtime afaik.

I've been studying it for a while now, and I've decided that it will likely be
my mobile development language.  I love Qt to death for desktop, but I've
never been able to take to it's declarative approach.  I know others swear by
it, but it just never fit my brain waves for some reason.

I saw somebody in this thread moan about it being yet another language to
learn.  Putting aside the fact that a robust developer should know more than
one, Dart is quite familiar to anybody who has used a modern scripting
language (e.g., Python).

For me personally, Flutter's "feel" just fits mobile better in my mind than Qt.

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






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

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



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

Re: [Interest] vs. Flutter

[Jason H]

I'm in your offtopic camp.

Everything is going Declarative. I really hate that web devevlopment requires the use of HTML/CSS/JS (that's just client side) and some Framework of the Month. The _javascript_ kiddies love inventing frameworks for fame and profit rather than picking one and making it better. Fragmentation is rampant. On top of that JS is slow to change, it just becomes a runtime that your flavor-of-the-month framework compiles down to, well until WebAssembly.

 

Rene, I don't understand why you don't declare Flutter Declarative? From the Flutter home page:

Widget build(BuildContext context) {

  return new Scaffold (

     appBar: new AppBar ( title: new Text (widget.title), ),

     body: new Center (

        child: new Text( "Button clicked" ...

             ),

     ),

}


 

Good luck typing 'new' and 'return' a lot. At least QML manages that for you. QML is the sleekest of all the declarative languages. 

 

 


Sent: Tuesday, February 19, 2019 at 12:55 PM
From: "Bernhard B" 
To: "Bob Hood" 
Cc: "René Hansen" , "Jason H" , inter...@lists.qt-project.org
Subject: Re: [Interest] vs. Flutter



> I've been studying it for a while now, and I've decided that it will likely be
my mobile development language.  I love Qt to death for desktop, but I've
never been able to take to it's declarative approach.  I know others swear by
it, but it just never fit my brain waves for some reason.

 



I guess I am one of those persons, who absolutely LOVE Qt's declarative language.

I like QML so much, that I even started looking for QML -> HTML/CSS translators. While I really like QML,

I absolutely hate HTML and CSS (never got used to its quirks). I mean there are some attempts like

qmlcore (https://github.com/pureqml/qmlcore), but I haven't tried those yet.




 


Am Di., 19. Feb. 2019 um 18:47 Uhr schrieb Bob Hood <bho...@comcast.net>:

On 2/18/2019 7:40 AM, René Hansen wrote:
> I've not come across any myself, and have only built a few small things with
> it a bit for now.
>
> Initial reactions was that it is *leagues* ahead of Qt with regards to
> developer experience. You're not locked to an IDE, like with QtCreator, and
> the ui live updates across device, simulators, emulators etc. when you write
> changes. No need to build and .apk and wait for a build+deploy.
>
> There's no JS involved. It's Dart all the way. It doesn't even ship with a
> web runtime afaik.

I've been studying it for a while now, and I've decided that it will likely be
my mobile development language.  I love Qt to death for desktop, but I've
never been able to take to it's declarative approach.  I know others swear by
it, but it just never fit my brain waves for some reason.

I saw somebody in this thread moan about it being yet another language to
learn.  Putting aside the fact that a robust developer should know more than
one, Dart is quite familiar to anybody who has used a modern scripting
language (e.g., Python).

For me personally, Flutter's "feel" just fits mobile better in my mind than Qt.

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




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

Re: [Interest] vs. Flutter

[Jason H]

Yes the V-Play peeps seem to have this nut cracked as well as other mobile 
efforts. But here's the rub: it should just be part of Qt and I shouldn't need 
to go two places. If V-Play (Felgo) can make a business out of these efforts, 
why isn't it the same for Qt proper? I keep rolling my eyes at all the 3D stuff 
going into Qt (which admittedly is *very cool*, but not what I need) but what I 
*need* is mobile to "just work". I don't even get why the Qt stuff is done, 
just use 3D to generate your 2D IVI animations and UI elements.

If all the effort put into 3D was put into mobile, we'd have mobile done a few 
times over by now.

I think Qt should to acquire Felgo to be a 1-stop shop. Also, FWIW, I don't 
know why PySide didn't take up Riverbank's PyQt. So now we have Mobile and 
Python fragmentation in Qt.  

I've never said this before, but I think Qt's days are numbered unless they get 
their ecosystem in order. With Google entering the x-platform marketplace about 
the hopes Qt has is to somehow deliver better than Google, or hope that Flutter 
is fleeting. Google has been a little ADHD with projects, so... maybe?



> Sent: Tuesday, February 19, 2019 at 10:50 AM
> From: "Jereme Givens- Lamothe" 
> To: "interest@qt-project.org" 
> Cc: "Jason H" 
> Subject: Re: [Interest] vs. Flutter
>
> Does something like the (recently rebranded) Felgo address any of your 
> concerns about mobile development w/ Qt? They used to call the product 
> "V-Play", but wanted to market it for use in regular apps (non-games) as 
> well. I haven't used it myself, but they seem to handle QML live-reload and 
> notifications. 
> 
> https://felgo.com/qml-live-code-reload
> https://felgo.com/doc/apps-get-started-for-ios-developers/#how-do-i-set-up-push-notifications
> 
> 
> From: Interest  on behalf of Jason H 
> 
> Sent: Tuesday, February 19, 2019 10:25 AM
> To: "René Hansen"
> Cc: inter...@lists.qt-project.org
> Subject: Re: [Interest] vs. Flutter
>  
> Many thanks for all those who replied.
> 
> > I've not come across any myself, and have only built a few small things 
> > with it a bit for now.
> >
> > Initial reactions was that it is *leagues* ahead of Qt with regards to 
> > developer experience. You're not locked to an IDE, like with QtCreator, and 
> > the ui live updates across device, simulators, emulators etc. when you 
> > write changes. No need to build and .apk and wait for a build+deploy.
> 
> What if there was a way to stand up a QmlEngine, host it on a phone, then 
> start the app and then ship the QML over to it, then when a new version is 
> ready, reset the engine and reload? This doesn't seem like anything that 
> would be really hard to add to Qt/QtCreator?
> 
> > There's no JS involved. It's Dart all the way. It doesn't even ship with a 
> > web runtime afaik.
> >
> > Achitecturally it's similar to Qt, in that they've build a custom renderer 
> > on top of Skia, so the whole scene is basically just OpenGL, which makes it 
> > really fast.
> >
> > Component wise, their UI library offers bother Cupertino and Material 
> > design out of the box, and from initial impressions, looks to be closer to 
> > the original design guidelines than Qt Quick Controls for. e.g. Material.
> 
> This doesn't sound like anything we can't have either?
> 
> > I haven't tried it out myself yet, but you should be able to reach into 
> > native world by using platform channels:
> >
> > https://flutter.io/docs/development/platform-integration/platform-channels
> >
> > It's seems like it's quite a ways worse than with Qt though, so there's at 
> > least that.
> 
> Well, Qt on Mobile is relatively abysmal. There is a much higher lack of 
> parity than anywhere else. The recent Developer Survey gave me some hope 
> though: 10% embedded 20% mobile. This was suggested to being some much needed 
> love to Mobile. I will say that my commercial support seems to trigger the 
> fixing of those issues pretty quickly. So it's not being ignored. One of my 
> chief frustrations with the Qt Project as a whole is lack of a roadmap.
> 
> Things that need attention in 2015 (yeah long overdue)
> * Notifications API (Desktop, Mobile)
> * Multimedia platform parity with each other and desktop.
> * Device support APIs (display brightness, volume, etc)
> 
> All those things still need attention in 2019.
> 
> I don't know how flutter runs on Windows or embedded hardware though. Maybe 
> all you need is ASOP?
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] vs. Flutter

[Jason H]

Many thanks for all those who replied. 

> I've not come across any myself, and have only built a few small things with 
> it a bit for now.
> 
> Initial reactions was that it is *leagues* ahead of Qt with regards to 
> developer experience. You're not locked to an IDE, like with QtCreator, and 
> the ui live updates across device, simulators, emulators etc. when you write 
> changes. No need to build and .apk and wait for a build+deploy.

What if there was a way to stand up a QmlEngine, host it on a phone, then start 
the app and then ship the QML over to it, then when a new version is ready, 
reset the engine and reload? This doesn't seem like anything that would be 
really hard to add to Qt/QtCreator?

> There's no JS involved. It's Dart all the way. It doesn't even ship with a 
> web runtime afaik.
> 
> Achitecturally it's similar to Qt, in that they've build a custom renderer on 
> top of Skia, so the whole scene is basically just OpenGL, which makes it 
> really fast.
> 
> Component wise, their UI library offers bother Cupertino and Material design 
> out of the box, and from initial impressions, looks to be closer to the 
> original design guidelines than Qt Quick Controls for. e.g. Material.

This doesn't sound like anything we can't have either?

> I haven't tried it out myself yet, but you should be able to reach into 
> native world by using platform channels:
> 
> https://flutter.io/docs/development/platform-integration/platform-channels
> 
> It's seems like it's quite a ways worse than with Qt though, so there's at 
> least that.

Well, Qt on Mobile is relatively abysmal. There is a much higher lack of parity 
than anywhere else. The recent Developer Survey gave me some hope though: 10% 
embedded 20% mobile. This was suggested to being some much needed love to 
Mobile. I will say that my commercial support seems to trigger the fixing of 
those issues pretty quickly. So it's not being ignored. One of my chief 
frustrations with the Qt Project as a whole is lack of a roadmap. 

Things that need attention in 2015 (yeah long overdue)
* Notifications API (Desktop, Mobile)
* Multimedia platform parity with each other and desktop. 
* Device support APIs (display brightness, volume, etc)

All those things still need attention in 2019.

I don't know how flutter runs on Windows or embedded hardware though. Maybe all 
you need is ASOP?

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

[Interest] vs. Flutter

[Jason H]

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

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

[Jason H]

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

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

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

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

Re: [Interest] Problems getting Qml camera to work under iOS

[Jason H]

No problems using the cameras in iOS for some time now including 5.12. you 
probably also need to do a usage description for the microphone?  I thought 
this has been separated out to another permission request but if you're 
attempting to record video maybe that's the issue?

> Sent: Sunday, February 10, 2019 at 1:23 PM
> From: "Roman Wüger" 
> To: "'Qt Project MailingList'" 
> Subject: [Interest] Problems getting Qml camera to work under iOS
>
> Hello,
> 
>  
> 
> I use CMake with Qt >= 5.11.1 and have troubles to get my camera working
> under iOS 12.1.
> 
> I set the required key/value (NSCameraUsageDescription) in the Info.plist
> file and link against the required libraries:
> 
> 
> 
> target_link_libraries(${PROJECT_NAME} Qt5::AVFServicePlugin) # imported
> library for libqavfcamera.a
> 
>  
> 
> But when I switch to the page which includes the Qml Camera and VideoOut, I
> get the following error:
> 
> defaultServiceProvider::requestService(): no service found for –
> “org.qt-project.qt.camera”
> 
>  
> 
> I also read the other solved problems, but can’t figure out what the problem
> is, since I link against the required library and set the key in the
> Info.plist file.
> 
>  
> 
> Do I miss something else?
> 
>  
> 
> Thanks in advance
> 
>  
> 
> Kind regards
> 
> Roman
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Bundle multimedia codecs with application

[Jason H]

As someone who was distributing Qt apps with k-lite-codec pack 10 years ago... I think this would be a thing of the past now?

mp4 should be supported everywhere. When you say "QtMultimedia doesn't recognize all of the video formats out of the box", I wonder what backend you/Qt are using?

Anyway, MP4 (h263, 264, 265) is about as ubiqutous as it gets. Check with Android CDD Section 5: https://source.android.com/compatibility/android-cdd.pdf and ios's AVFoundation https://developer.apple.com/documentation/avfoundation/avfiletype?language=objc I think supporting codecs not supported by the platform is asking for trouble. Basically the only commonality is H264. 

 

Supporting any others will be efforts in themselves.

 

 

Sent: Sunday, February 03, 2019 at 3:47 PM
From: "Bernhard B" 
To: interest@qt-project.org
Subject: [Interest] Bundle multimedia codecs with application



Hi all,

 

is it possible to bundle multimedia codecs with a Qt application? I want to use QtMultimedia to play all sort of different video formats. Unfortunately, QtMultimedia doesn't recognize all of the video formats out of the box, which requires me to install a codec pack (e.q K-Lite Codec pack) first.

 

As I am not a big fan of external depenendencies, I would prefer to bundle the necessary codecs with my application. Is that somehow possible?

 

I also looked at other projects like QtAV or vlc-qt (to replace QtMultimedia), but at some point I always ran into playback/API bugs (which I couldn't fix myself) . So I am back at QtMultimedia, which uses a well tested interface that just works. The only thing I am not happy about are the codecs that need to be installed first. Is there a possibility to bundle them with the application?
 

Thanks,

Bernhard

___ 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] NFC issues

[Jason H]

So I have a fre issues with NFC.

1. a tag I wrote, it's just got text on it. I'm using the annotatedurl example 
as a base.
I've removed the filter so I can see every tag. 

The problem is, 50% of the time it does not work, at least right away. I 
present the tag and sometimes the app gets the text. The other times, it goes 
to the default NFC handler. If I then close the default NFC handler, it will 
read the tag. If I wait a while (indeterminate amount of time) it will "just 
work" as it should. Has anyone seen this before? 

The extent of my code change (aside from debug statements) is:

//int result = manager->registerNdefMessageHandler(filter, this, 
SLOT(handleMessage(QNdefMessage,QNearFieldTarget*)));
int result = manager->registerNdefMessageHandler(this,  
SLOT(handleMessage(QNdefMessage,QNearFieldTarget*)));

I think the issue the adapter might not be ready, which brings me to the next 
issue:

2. I'm also having problems connecting to adapterStateChange:
connect(manager, SIGNAL(adapterStateChanged(QNearFieldManager::AdapterState)), 
this, SLOT(handleStateChange(QNearFieldManager::AdapterState)));


pubic slots:
void handleStateChange(QNearFieldManager::AdapterState state);


void AnnotatedUrl::handleStateChange(QNearFieldManager::AdapterState state) {
qDebug() << "*";
qDebug() << Q_FUNC_INFO << state;
qDebug() << "*";
}

I get, depending on the variant of the connect syntax I try:
libannotatedurl.so: QObject::connect: Incompatible sender/receiver arguments
W libannotatedurl.so: 
QNearFieldManager::adapterStateChanged(AdapterState) --> 
AnnotatedUrl::handleStateChange(QNearFieldManager::AdapterState)
(was connect(manager, SIGNAL(adapterStateChanged(AdapterState)), this, 
SLOT(handleStateChange(QNearFieldManager::AdapterState)));)
or 
W libannotatedurl.so: QObject::connect: No such signal 
QNearFieldManager::adapterStateChanged(QNearFieldManager::AdapterState) in 
annotatedurl.cpp:107
(was connect(manager, 
SIGNAL(adapterStateChanged(QNearFieldManager::AdapterState)), this, 
SLOT(handleStateChange(QNearFieldManager::AdapterState)));)
or 
W libannotatedurl.so: QObject::connect: No such slot 
AnnotatedUrl::handleStateChange(AdapterState) in annotatedurl.cpp:107
(was connect(manager, SIGNAL(adapterStateChanged(AdapterState)), this, 
SLOT(handleStateChange(AdapterState)));)

In the .h for it, it is declared as:
/* in class Q_NFC_EXPORT QNearFieldManager : public QObject */
Q_SIGNALS:
void adapterStateChanged(AdapterState state);

What is the proper connection syntax?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Android NFC compile error

[Jason H]

I'm following along with: 
http://doc.qt.io/qt-5/qtnfc-annotatedurl-annotatedurl-cpp.html

However:
In file included from ../my_project/nfctag.cpp:1:
In file included from ../my_project/nfctag.h:4:
In file included from 
../../Qt/5.12.0/android_armv7/include/QtNfc/QNearFieldManager:1:
In file included from 
../../Qt/5.12.0/android_armv7/include/QtNfc/qnearfieldmanager.h:45:
In file included from 
../../Qt/5.12.0/android_armv7/include/QtNfc/QNearFieldTarget:1:
../../Qt/5.12.0/android_armv7/include/QtNfc/qnearfieldtarget.h:60:20: error: 
variable has incomplete type 'class Q_NFC_EXPORT'
class Q_NFC_EXPORT QNearFieldTarget : public QObject
   ^
../../Qt/5.12.0/android_armv7/include/QtNfc/qnearfieldtarget.h:60:7: note: 
forward declaration of 'Q_NFC_EXPORT'
class Q_NFC_EXPORT QNearFieldTarget : public QObject
  ^
../../Qt/5.12.0/android_armv7/include/QtNfc/qnearfieldtarget.h:60:37: error: 
expected ';' after top level declarator
class Q_NFC_EXPORT QNearFieldTarget : public QObject


QtCreator is telling me that Q_NFC_EXPORT is: 
#define Q_NFC_EXPORT Q_DECL_IMPORT

I'm using NDK n18r - clang.
I have added QT += nfc to my Android scope.
I have ran qmake

Has anyone tried this with clang? Does this work?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?

[Jason H]

So I think i got that completely wrong.  I'm more used to using androidextras. 
They have a nice API that cleans up for you. I gotta that's not an option?  
Maybe they JNI stuff should get it's own module separate from Android? 

> Sent: Friday, January 25, 2019 at 9:00 PM
> From: "Jason H" 
> To: "René Hansen" 
> Cc: interest 
> Subject: Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What 
> am I doing wrong here?
>
> 
> 
> I'm not familiar with that, jbteArray, but in attemping your challenge, I saw:
>  
> qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast(foo));
>  
> but saw this in the docs: 
> void SetArrayRegion(JNIEnv *env, ArrayType array, jsize start, 
> jsize len, NativeType *buf);
> 
>  
> is jdata your jni env?
> 
> Sent: Friday, January 25, 2019 at 1:13 PM
> From: "René Hansen" 
> To: interest 
> Subject: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I 
> doing wrong here?
> 
> All I want to do is send some bytes from Qt to Java, but I'm running into an 
> annoying problem, where my jbyteArray gets turned into java.lang.String[] in 
> mid-flight:
>  
> 
> E art     : JNI ERROR (app bug): attempt to pass an instance of 
> java.lang.String[] as argument 1 to int Foo.bar(byte[])
> F art     : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN 
> APPLICATION: bad arguments passed to int Foo.bar(byte[]) (see above for 
> details)
> F art     : art/runtime/java_vm_ext.cc:410]     from void 
> org.qtproject.qt5.android.QtNative.runPendingCppRunnables()
> F art     : art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable
> ...
>  
> Here's a minimal example; just a simple auto test project:
>  
> TestJNI.pro:
>  
> 
> QT += testlib androidextras
> QT -= gui
>  
> CONFIG += qt console warn_on depend_includepath testcase
> CONFIG -= app_bundle
>  
> TEMPLATE = app
>  
> SOURCES +=  tst_test_jni.cpp
>  
> ANDROID_PACKAGE_SOURCE_DIR = $$PWD
>  
> DISTFILES += \
>     src/Foo.java
>  
> tst_test_jni.cpp:
>  
> #include 
> #include 
> #include 
>  
> class test_jni : public QObject
> {
>     Q_OBJECT
>  
> private slots:
>     void test_case1();
> };
>  
> void test_jni::test_case1()
> {
>   QAndroidJniEnvironment qjniEnv;
>   jsize _size = static_cast(5);
>   jbyteArray jdata = qjniEnv->NewByteArray(_size);
>   jint result;
>  
>   if (jdata == nullptr)
>     QFAIL("Failed creating new jbyteArray");
>  
>   if (qjniEnv->GetArrayLength(jdata) != _size)
>   {
>     qjniEnv->DeleteLocalRef(jdata);
>     QFAIL("Failed to allocate entire array through JNI");
>   }
>  
>   // Lorem
>   char foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };
>  
>   qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast *>(foo));
>  
>   QtAndroid::runOnAndroidThread([jdata] {
>     QAndroidJniObject::callStaticMethod(
>           "Foo",
>           "bar",
>           "([B)I",
>           jdata);
>   });
>  
>   QCOMPARE(result, 42);
> }
>  
> QTEST_APPLESS_MAIN(test_jni)
>  
> #include "tst_test_jni.moc"
>  
> Foo.java:
>  
> public class Foo {
>   static int bar(byte baz[]) {
>       return 42;
>   }
> }
>  
> Have I missed something very basic here?
>  
>  
> Best regards,
>  
> René Hansen___ Interest mailing 
> list Interest@qt-project.org 
> https://lists.qt-project.org/listinfo/interest___
>  Interest mailing list Interest@qt-project.org 
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?

[Jason H]

I'm not familiar with that, jbteArray, but in attemping your challenge, I saw:

 

qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast(foo));

 

but saw this in the docs: 

void SetArrayRegion(JNIEnv *env, ArrayType array, jsize start, jsize len, NativeType *buf);


 

is jdata your jni env?


Sent: Friday, January 25, 2019 at 1:13 PM
From: "René Hansen" 
To: interest 
Subject: [Interest] (JNI ERROR) jbytearray -> java.lang.String[] - What am I doing wrong here?


All I want to do is send some bytes from Qt to Java, but I'm running into an annoying problem, where my jbyteArray gets turned into java.lang.String[] in mid-flight:

 


E art     : JNI ERROR (app bug): attempt to pass an instance of java.lang.String[] as argument 1 to int Foo.bar(byte[])

F art     : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: bad arguments passed to int Foo.bar(byte[]) (see above for details)

F art     : art/runtime/java_vm_ext.cc:410]     from void org.qtproject.qt5.android.QtNative.runPendingCppRunnables()

F art     : art/runtime/java_vm_ext.cc:410] "main" prio=5 tid=1 Runnable


...

 

Here's a minimal example; just a simple auto test project:

 

TestJNI.pro:

 


QT += testlib androidextras

QT -= gui

 

CONFIG += qt console warn_on depend_includepath testcase

CONFIG -= app_bundle

 

TEMPLATE = app

 

SOURCES +=  tst_test_jni.cpp

 

ANDROID_PACKAGE_SOURCE_DIR = $$PWD

 

DISTFILES += \

    src/Foo.java

 


tst_test_jni.cpp:
 
#include 

#include 

#include 

 

class test_jni : public QObject

{

    Q_OBJECT

 

private slots:

    void test_case1();

};

 

void test_jni::test_case1()

{

  QAndroidJniEnvironment qjniEnv;

  jsize _size = static_cast(5);

  jbyteArray jdata = qjniEnv->NewByteArray(_size);

  jint result;

 

  if (jdata == nullptr)

    QFAIL("Failed creating new jbyteArray");

 

  if (qjniEnv->GetArrayLength(jdata) != _size)

  {

    qjniEnv->DeleteLocalRef(jdata);

    QFAIL("Failed to allocate entire array through JNI");

  }

 

  // Lorem

  char foo[] = { 0x4c, 0x6f, 0x72 ,0x65, 0x6d };

 

  qjniEnv->SetByteArrayRegion(jdata, 0, _size, reinterpret_cast(foo));

 

  QtAndroid::runOnAndroidThread([jdata] {

    QAndroidJniObject::callStaticMethod(

          "Foo",

          "bar",

          "([B)I",

          jdata);

  });

 

  QCOMPARE(result, 42);

}

 

QTEST_APPLESS_MAIN(test_jni)

 

#include "tst_test_jni.moc"

 

Foo.java:

 
public class Foo {

  static int bar(byte baz[]) {

      return 42;

  }

}


 

Have I missed something very basic here?

 

 

Best regards,

 

René Hansen


___ 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