Connect to terminal native window - repost
-
Forgive me to be so bold - but I just cannot believe that in versatile forum like this there is nobody who can at lest give me some idea how to resolve this. It seems to be a problem that everybody wants SINGLE system problem - that seldom works in real life. As the title suggest - I need to connect Qt generated object / window to Linux "terminal" (operating system ) native window. I can highlight ( Using Qt) the text in the native window (!) but Qt gives me no indication it did that. PLEASE - NO PASSING THE BUCK TO QT FORUM - THEY HAVE NO IDEA HOW TO PROCEED - IT IS NOT Qt ISSUE IN THEIR ASSESSMENT -HENCE out OF THEIR narrow minded LEAGUE. ps i WILL REMOVE THIS , AND MY SIMILAR POSTS, IF i DO NOT GET REASONABLE REPLY , JUST TO SAVE SPACE HERE. Edited / addendum I am still looking for somebody who is willing to help me instead of just posting text. If it bothers you that my post is not specifically C/C++ code , please ignore it . If it bothers you that my post is too complex , please ignore it also. If it bothers you that my post is poorly written - read how to post / answer questions. Is short - write something helpful and constructive. I am asking for real help to SOLVE this. The main issue is - QProcess runs external "terminal" application - I have tried several with same results - such external application builds / create "window" , which is by C code attached to object created by QtCreator. Window created by Qt displays data retrieved from the external app ( terminal) , I am interested in text only so far. Such data ( text ) can be highlighted by using mouse - as any QT created text, However, this highlighted text is NOT DETECTED by QT - because of what ? And that is the main (IMHO) question which is so far not answered... How does terminal created window "connect" to Qt ? - that is the question. Original post This simple command , entered in Linux "terminal" application results in expected output from "Bluetoothctl" . qterminal -e bluetoothctl When this command is implemented in C++ code , an new "native window" is displayed above current application windows. Similar code can be implemented in C++ for "xterm" or other terminal emulation. My question is - how do I acccess this "native window " in my C++ application ? I can move the "native window" into desired position using winId() but cannot access any data displayed in the native window. Thanks for reply. I am actuall
I have no idea what you are trying to achieve, but is this even close: Creating a Child Process with Redirected Input and Output - Win32 apps | Microsoft Learn[^]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I have no idea what you are trying to achieve, but is this even close: Creating a Child Process with Redirected Input and Output - Win32 apps | Microsoft Learn[^]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
Yes, I am trying to communicate with external application - started by currently running application, I did look at the link code and honestly at this point I am looking at the QT QProcess and do not want to start another code analysis. However it looks as both QT and you code are using stdin/stdout which seems to be a solution to my issue. Many thanks for your post, appreciate any help.
-
Yes, I am trying to communicate with external application - started by currently running application, I did look at the link code and honestly at this point I am looking at the QT QProcess and do not want to start another code analysis. However it looks as both QT and you code are using stdin/stdout which seems to be a solution to my issue. Many thanks for your post, appreciate any help.
More I get into this the more confused I am . The Qt QProcess starts external application... Per Qt QProcess doc
Processes have two predefined output channels: The standard output channel (stdout) supplies regular console output, and the standard error channel (stderr) usually supplies the errors that are printed by the process. These channels represent two separate streams of data. You can toggle between them by calling setReadChannel(). QProcess emits readyRead() when data is available on the current read channel. It also emits readyReadStandardOutput() when new standard output data is available, and when new standard error data is available, readyReadStandardError() is emitted. Instead of calling read(), readLine(), or getChar(), you can explicitly read all data from either of the two channels by calling readAllStandardOutput() or readAllStandardError().
I am decoding the above as QProcess can communicate with the started external application using standard stdio/stdout. Now the application started is "xterm" which executes "bluetoothctl". I am redirecting the result of the "bluetoothctl" output to temporary file... I have "xterm" itself optioned for logging and have the log file - it has SAME contents and format as my temporary "bluetoothctl" file . I have added "connect " to my code to capture any of this "printing" , but the SIGNAL ( as described in the doc snippet ) never arrives - hence neither xterm logging process nor bluetoothctl temp file are stdin/stdout. My question - what processes / prints the xterm log and the bluetoothctl file? Obviously these (prints) are not standard stdin/stdout. I realize this is no longer C code issue, actually it never was pure C code issue , but still getting no help from QT forum. PS xterm has "-C" - console option , but using it did not resolve the issue.
-
More I get into this the more confused I am . The Qt QProcess starts external application... Per Qt QProcess doc
Processes have two predefined output channels: The standard output channel (stdout) supplies regular console output, and the standard error channel (stderr) usually supplies the errors that are printed by the process. These channels represent two separate streams of data. You can toggle between them by calling setReadChannel(). QProcess emits readyRead() when data is available on the current read channel. It also emits readyReadStandardOutput() when new standard output data is available, and when new standard error data is available, readyReadStandardError() is emitted. Instead of calling read(), readLine(), or getChar(), you can explicitly read all data from either of the two channels by calling readAllStandardOutput() or readAllStandardError().
I am decoding the above as QProcess can communicate with the started external application using standard stdio/stdout. Now the application started is "xterm" which executes "bluetoothctl". I am redirecting the result of the "bluetoothctl" output to temporary file... I have "xterm" itself optioned for logging and have the log file - it has SAME contents and format as my temporary "bluetoothctl" file . I have added "connect " to my code to capture any of this "printing" , but the SIGNAL ( as described in the doc snippet ) never arrives - hence neither xterm logging process nor bluetoothctl temp file are stdin/stdout. My question - what processes / prints the xterm log and the bluetoothctl file? Obviously these (prints) are not standard stdin/stdout. I realize this is no longer C code issue, actually it never was pure C code issue , but still getting no help from QT forum. PS xterm has "-C" - console option , but using it did not resolve the issue.
-
Do you need to wrap bluetoothctl in an xterm for some reason, can you not just call QProcess with bluetoothctl as the program to execute?
Keep Calm and Carry On
I have changed the QProcess - now it starts bluetoothctl directly and it generates what appears to be stdout SIGNAL to run readFromStdout() function. That is very encouraging, however, I have no idea how to actually read whatever initialized this SIGNAL. When I run debug I get ton of data , but have no clue what I am looking for. The attached code attempt to read it is not working. I am assuming the "stdout" is in some kind of buffer... And to read it - should I be using "stdin"?
int CCC_MdiChild::readFromStdout()
{
#ifdef TRACE_MDI_XTERM
qDebug()<< "TRACE_MDI_XTERM " < -
I have changed the QProcess - now it starts bluetoothctl directly and it generates what appears to be stdout SIGNAL to run readFromStdout() function. That is very encouraging, however, I have no idea how to actually read whatever initialized this SIGNAL. When I run debug I get ton of data , but have no clue what I am looking for. The attached code attempt to read it is not working. I am assuming the "stdout" is in some kind of buffer... And to read it - should I be using "stdin"?
int CCC_MdiChild::readFromStdout()
{
#ifdef TRACE_MDI_XTERM
qDebug()<< "TRACE_MDI_XTERM " <I gave you a suggestion about this a few days ago at Re: Connect to terminal native window - repost - C / C++ / MFC Discussion Boards[^]. The two processes connect via a pipe, such that the stdout of the called process is connected to stdin of the caller. This is something that has existed in Windows and Linux for years.
-
I gave you a suggestion about this a few days ago at Re: Connect to terminal native window - repost - C / C++ / MFC Discussion Boards[^]. The two processes connect via a pipe, such that the stdout of the called process is connected to stdin of the caller. This is something that has existed in Windows and Linux for years.
I need to fully digest how it all connect. I follow your suggestion and others so do not get so huffy. Actually to most important suggestion was to run "bluetoothctl" direct. As far as I can tell now - the QProcess executed the "xterm" with option to execute bluetoothctl. However - I was not getting SIGNAL. BUT if set the QProcess to run "bluetoothctl" , thus bypassing the "xterm" I do get the expected SIGNAL. So the full "pipe" from "xterm" to "bluetoothctl" is not there... the required SIGNAL is missing, the question remains - WHY?
-
I need to fully digest how it all connect. I follow your suggestion and others so do not get so huffy. Actually to most important suggestion was to run "bluetoothctl" direct. As far as I can tell now - the QProcess executed the "xterm" with option to execute bluetoothctl. However - I was not getting SIGNAL. BUT if set the QProcess to run "bluetoothctl" , thus bypassing the "xterm" I do get the expected SIGNAL. So the full "pipe" from "xterm" to "bluetoothctl" is not there... the required SIGNAL is missing, the question remains - WHY?
Member 14968771 wrote:
do not get so huffy.
There's only one person here who gets huffy. The main problem with your question is that it is far from clear exactly what you are trying to do, or why you are using QT. If you merely want to capture the output of some command, then running it in xterm is not a good choice. But since the reason for xterm was not clear I did not originally question it. However, I did point out that connecting processes via stdin, stdout is something that has been around since the early days of Linux/Windows, and is actually fully supported by QProcess.
-
Member 14968771 wrote:
do not get so huffy.
There's only one person here who gets huffy. The main problem with your question is that it is far from clear exactly what you are trying to do, or why you are using QT. If you merely want to capture the output of some command, then running it in xterm is not a good choice. But since the reason for xterm was not clear I did not originally question it. However, I did point out that connecting processes via stdin, stdout is something that has been around since the early days of Linux/Windows, and is actually fully supported by QProcess.
The main problem with your reply - to paraphrase it - is you are avoiding to provide a solution. It is not a question what I am trying to do and why I am using Qt. It has been established that QProcess can detect change in stdout
, you have pointed that out yourself and it helped immensely ,
- what IS not RESOLVED is WHY the combination of "xterm" executing "bluetoothctl" does NOT set stdout, when each command used individually sets the stdout data. If you cannot contribute to the solution to this , remaining issue, do not waste your time asking why I am using Qt.
-
The main problem with your reply - to paraphrase it - is you are avoiding to provide a solution. It is not a question what I am trying to do and why I am using Qt. It has been established that QProcess can detect change in stdout
, you have pointed that out yourself and it helped immensely ,
- what IS not RESOLVED is WHY the combination of "xterm" executing "bluetoothctl" does NOT set stdout, when each command used individually sets the stdout data. If you cannot contribute to the solution to this , remaining issue, do not waste your time asking why I am using Qt.