[Interest] Installer Framework: dynamically adding to list widget

[Kevin Wang]

Hello all,

I am resuming work on my installer, and there is a page I would like to 
add: a listing of all a user's network interfaces, that a user can 
choose from to complete our custom installation script.


I have written a script to detect and parse what network interfaces a 
computer has. I have a .ui file that contains a QListWidget. The form is 
included in the project and displays in the installer properly.


I would like to:

1. Execute a script (installer.execute(...) ) to find and retrieve the 
list of network interfaces


2. At runtime, use that list and append to the QListWidget


I have tried to use

   component.userInterface("NetworkInterfacePage").listWidget.insertItem(
   " network interface 1");

But that results in a runtime error:

 TypeError: Property 'insertItem' of object QListWidget(0x3634c30,
   "listWidget") is not a function


Any ideas what I am doing wrong? Any other ideas/methods to accomplish 
what I want to accomplish?


I find that the IFW documentation is lacking, especially as someone that 
only uses the Qt C++ widgets framework.



Many thanks,

Kevin Wang

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

Re: [Interest] Help with QSslSocket race condition?

[Thiago Macieira]

On Tuesday, 23 October 2018 11:43:24 PDT Israel Brewster wrote:
> I am using QSslSockets with a QTcpServer to create a simple client/server
> program (is there a higher level API I could use instead?). I have
> subclassed QTcpServer to create my server side sockets as QSslSockets and
> call startServerEncryption(), but otherwise it is just a standard
> QTcpServer.

Hello Israel

> bool EZPCore::waitForResponseReady(QSslSocket *socket,int msec){
> if(!socket || !socket->isValid() || !socket->isEncrypted() ||
> socket->state()!=QAbstractSocket::ConnectedState) return false; //there is
> something wrong with the socket, no point in waiting.
> 
> if(socket->bytesAvailable()>0)
> return true;//success! Bytes are available!
> 
> QEventLoop wait;  //don't block other operations while waiting
> QTimer waitTimeout; //only wait a set length of time.
> waitTimeout.setSingleShot(true);
> 
> connect(&waitTimeout,&QTimer::timeout,[&wait]{wait.exit(-1);});
> connect(socket,&QAbstractSocket::disconnected,[&wait]{wait.exit(-2);});
> //catch if the socket closes while waiting.

This is too late.

> connect(socket,&QAbstractSocket::readyRead,[&wait]{wait.exit();}); //zero
> exit
> 
> waitTimeout.start(msec);
> int result=wait.exec();
> waitTimeout.stop(); //stop the timer if it is still running (probably
> unneeded?)
> 
> if(result<0)
> return false; //not connected or timeout
> 
> //should only get here if result is 0, indicating readyRead signal
> received.
> 
> //if we have bytes available, then return success (0), even if
> //we had a timeout
> if(socket->bytesAvailable()>0) // UNLESS I don't call "deleteLater()" on disconnect??? 
> return true;
> return false; //no bytes available
> }

>From what I can see, the socket got disconnected by the remote end, with new 
data. So BOTH the readyRead() and disconnected() signals got emitted. Both as 
well as bytesWritten() are handled by the same loop, so any one of the three 
or all three can be emitted by an iteration of the event looop. However, 
there's only one QEventLoop exit code and readyRead() happened first.

> - When I come into this function, I check for
> QAbstractSocket::ConnectedState on the socket, and return immediately if
> not connected, which should mean that the socket is still connected when
> this function starts. 

Right.

> - I connect the "disconnected" signal of this
> function up to exit the event loop with a non-zero status should the socket
> disconnect during the event loop (entirely possible, of course) 

Only if it disconnected without receiving any data in the same loop.

> - The
> function returns immediately if the event loop exits with a non-zero
> status, and the only way for the event loop to exit with a zero status is
> for readyRead to be emitted.
> 
> As such, the only way for the crashing line of code to be executed should be
> for a) the socket to be in a connected state (otherwise the function
> wouldn't run), b) disconnected signal to NOT to be emitted during the event
> loop (so still connected), 

Incorrect. It must have been emitted.

> and c) the readyRead signal to be emitted.
> However, the crashing would indicate that the socket *is* being deleted
> during the event loop, which indicates that the socket is disconnecting.
> And yet I still get a readyRead signal?

Correct, you do.

> Incidentally, If I connect the destroyed signal to the event loop exit, I
> *do* catch that. So I can see the socket being destroyed, but not being
> disconnected. 

It is being disconnected, you're just not seeing the events in the right order 
due to nesting.

> So obviously I have an architecture issue here: the socket is
> closing and being destroyed while I am still trying to read from it. How
> can I fix this?

Remove this waitForResponseReady() function entirely and all uses of 
QEventLoop.

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



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

Re: [Interest] Help with QSslSocket race condition?

[Israel Brewster]

On Oct 23, 2018, at 1:27 PM, Henry Skoglund 
mailto:fro...@tungware.se>> wrote:

On 23/10/2018 20.43, Israel Brewster wrote:
I am using QSslSockets with a QTcpServer to create a simple client/server 
program (is there a higher level API I could use instead?). I have subclassed 
QTcpServer to create my server side sockets as QSslSockets and call 
startServerEncryption(), but otherwise it is just a standard QTcpServer.
When a socket first connects to the server, I make the following connection:
connect(clientConnection, SIGNAL(disconnected()), clientConnection, 
SLOT(deleteLater()));
where clientConnection is the QSslSocket created by the QTcpServer. Later, when 
using the socket (again on the server), I have the following function to wait 
for data from the client:
 
/// \brief EZPCore::waitForResponseReady
/// \param socket
/// \param msec
/// \return true=data available, false=timeout/error
///
/// Documentation for QAbstractSocket "waitForReadyRead" says
/// "This function may fail randomly on Windows. Consider using the event loop 
and the readyRead()
/// signal if your software will run on Windows."
/// so that's what this function does.
bool EZPCore::waitForResponseReady(QSslSocket *socket,int msec){
 if(!socket || !socket->isValid() || !socket->isEncrypted() || 
socket->state()!=QAbstractSocket::ConnectedState)
 return false; //there is something wrong with the socket, no point in 
waiting.
if(socket->bytesAvailable()>0)
return true;//success! Bytes are available!
QEventLoop wait;  //don't block other operations while waiting
QTimer waitTimeout; //only wait a set length of time.
waitTimeout.setSingleShot(true);
connect(&waitTimeout,&QTimer::timeout,[&wait]{wait.exit(-1);});
 connect(socket,&QAbstractSocket::disconnected,[&wait]{wait.exit(-2);}); 
//catch if the socket closes while waiting.
 connect(socket,&QAbstractSocket::readyRead,[&wait]{wait.exit();}); //zero 
exit
waitTimeout.start(msec);
int result=wait.exec();
 waitTimeout.stop(); //stop the timer if it is still running (probably 
unneeded?)
if(result<0)
return false; //not connected or timeout
//should only get here if result is 0, indicating readyRead signal received.
//if we have bytes available, then return success (0), even if
//we had a timeout
if(socket->bytesAvailable()>0) //

Re: [Interest] Help with QSslSocket race condition?

[Henry Skoglund]

On 23/10/2018 20.43, Israel Brewster wrote:
I am using QSslSockets with a QTcpServer to create a simple 
client/server program (is there a higher level API I could use 
instead?). I have subclassed QTcpServer to create my server side sockets 
as QSslSockets and call startServerEncryption(), but otherwise it is 
just a standard QTcpServer.


When a socket first connects to the server, I make the following connection:

connect(clientConnection, SIGNAL(disconnected()), 
clientConnection, SLOT(deleteLater()));


where clientConnection is the QSslSocket created by the QTcpServer. 
Later, when using the socket (again on the server), I have the following 
function to wait for data from the client:


  
/// \brief EZPCore::waitForResponseReady
/// \param socket
/// \param msec
/// \return true=data available, false=timeout/error
///
/// Documentation for QAbstractSocket "waitForReadyRead" says
/// "This function may fail randomly on Windows. Consider using the event loop 
and the readyRead()
/// signal if your software will run on Windows."
/// so that's what this function does.
bool EZPCore::waitForResponseReady(QSslSocket *socket,int msec){
   
   if(!socket || !socket->isValid() || !socket->isEncrypted() || socket->state()!=QAbstractSocket::ConnectedState)
   
   return false; //there is something wrong with the socket, no point in waiting.


     if(socket->bytesAvailable()>0)
         return true;//success! Bytes are available!

     QEventLoop wait;  //don't block other operations while waiting
     QTimer waitTimeout; //only wait a set length of time.
     waitTimeout.setSingleShot(true);

     connect(&waitTimeout,&QTimer::timeout,[&wait]{wait.exit(-1);});
   
   connect(socket,&QAbstractSocket::disconnected,[&wait]{wait.exit(-2);}); //catch if the socket closes while waiting.
   
   connect(socket,&QAbstractSocket::readyRead,[&wait]{wait.exit();}); //zero exit


     waitTimeout.start(msec);
     int result=wait.exec();
   
   waitTimeout.stop(); //stop the timer if it is still running (probably unneeded?)


     if(result<0)
         return false; //not connected or timeout

     //should only get here if result is 0, indicating readyRead signal 
received.


     //if we have bytes available, then return success (0), even if
     //we had a timeout
     if(socket->bytesAvailable()>0) //

[Interest] Help with QSslSocket race condition?

[Israel Brewster]

I am using QSslSockets with a QTcpServer to create a simple client/server 
program (is there a higher level API I could use instead?). I have subclassed 
QTcpServer to create my server side sockets as QSslSockets and call 
startServerEncryption(), but otherwise it is just a standard QTcpServer.

When a socket first connects to the server, I make the following connection:

connect(clientConnection, SIGNAL(disconnected()), clientConnection, 
SLOT(deleteLater()));

where clientConnection is the QSslSocket created by the QTcpServer. Later, when 
using the socket (again on the server), I have the following function to wait 
for data from the client:

 
/// \brief EZPCore::waitForResponseReady
/// \param socket
/// \param msec
/// \return true=data available, false=timeout/error
///
/// Documentation for QAbstractSocket "waitForReadyRead" says
/// "This function may fail randomly on Windows. Consider using the event loop 
and the readyRead()
/// signal if your software will run on Windows."
/// so that's what this function does.
bool EZPCore::waitForResponseReady(QSslSocket *socket,int msec){
if(!socket || !socket->isValid() || !socket->isEncrypted() || 
socket->state()!=QAbstractSocket::ConnectedState)
return false; //there is something wrong with the socket, no point in 
waiting.

if(socket->bytesAvailable()>0)
return true;//success! Bytes are available!

QEventLoop wait;  //don't block other operations while waiting
QTimer waitTimeout; //only wait a set length of time.
waitTimeout.setSingleShot(true);

connect(&waitTimeout,&QTimer::timeout,[&wait]{wait.exit(-1);});
connect(socket,&QAbstractSocket::disconnected,[&wait]{wait.exit(-2);}); 
//catch if the socket closes while waiting.
connect(socket,&QAbstractSocket::readyRead,[&wait]{wait.exit();}); //zero 
exit

waitTimeout.start(msec);
int result=wait.exec();
waitTimeout.stop(); //stop the timer if it is still running (probably 
unneeded?)

if(result<0)
return false; //not connected or timeout

//should only get here if result is 0, indicating readyRead signal received.

//if we have bytes available, then return success (0), even if
//we had a timeout
if(socket->bytesAvailable()>0) //

Re: [Interest] Bug Reports

[Dan Allen]

Thanks Mitch.

Appreciate the feedback.

Regards,

Dan.

On 23/10/2018 10:42, Mitch Curtis wrote:

-Original Message-
From: Interest  On
Behalf Of Dan Allen
Sent: Monday, 22 October 2018 9:37 PM
To: Qt Project 
Subject: [Interest] Bug Reports

Hi All,

I'm frustrated by what has happened on the last bug report
  I posted yesterday.

Why would this get closed in this way so quickly? Could there not have been
a comment just saying "Did you make an error with the test case?" before
closing it? And then give me 24 hours to respond perhaps?

I'm trying to help improve Qt. I don't see how closing the bug for this reason
in that time is doing the same.

Hi Dan.

I apologised for this earlier [1] in case you missed it.

I took it to be a simple case of user error, which is not uncommon as Allan 
mentioned. I take all the blame for not putting more though into it and hope 
that this doesn't deter you from submitting bug reports in the future.

Please also keep in mind that a bug report being closed is not a final 
decision, and that we are prone to user errors too. :) It's nothing personal.

That being said, the issue with leaving a comment and not changing the state of 
the report is that the request for more info is sometimes not provided and both 
parties forget about the bug report, adding to an already massive backlog of 
reports. Not to say that closing it was the correct course of action here, but 
just trying to give some background as to why we close reports that appear to 
be invalid.


Regards,

Dan.


[1] 
https://bugreports.qt.io/browse/QTBUG-71296?focusedCommentId=428146&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-428146


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

Re: [Interest] Bug Reports

[Mitch Curtis]

> -Original Message-
> From: Interest  On
> Behalf Of Dan Allen
> Sent: Monday, 22 October 2018 9:37 PM
> To: Qt Project 
> Subject: [Interest] Bug Reports
> 
> Hi All,
> 
> I'm frustrated by what has happened on the last bug report
>   I posted yesterday.
> 
> Why would this get closed in this way so quickly? Could there not have been
> a comment just saying "Did you make an error with the test case?" before
> closing it? And then give me 24 hours to respond perhaps?
> 
> I'm trying to help improve Qt. I don't see how closing the bug for this reason
> in that time is doing the same.

Hi Dan.

I apologised for this earlier [1] in case you missed it.

I took it to be a simple case of user error, which is not uncommon as Allan 
mentioned. I take all the blame for not putting more though into it and hope 
that this doesn't deter you from submitting bug reports in the future.

Please also keep in mind that a bug report being closed is not a final 
decision, and that we are prone to user errors too. :) It's nothing personal.

That being said, the issue with leaving a comment and not changing the state of 
the report is that the request for more info is sometimes not provided and both 
parties forget about the bug report, adding to an already massive backlog of 
reports. Not to say that closing it was the correct course of action here, but 
just trying to give some background as to why we close reports that appear to 
be invalid.

> Regards,
> 
> Dan.
> 

[1] 
https://bugreports.qt.io/browse/QTBUG-71296?focusedCommentId=428146&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-428146
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest