Connect to terminal native window - repost
-
The terminal app is started by Qt. Qt by itself does no keep track of terminal. My comment on highlighting the terminal window text "inside " Qt app is NOT Qt doing - hence if I start the terminal without "into" command option I can still highlight the text in the terminal "floating "window. I do not know why... or what process is highlighting the terminal window text IF Qt is no longer in the picture. That is the essence of this - how to keep Qt and external application communication going. Starting an external process / application without being able to communicate with it is useless ( to me ). It all runs under operating system and there should be a way to accomplish this. And if the answer is YES ( in runs under OS ) and IT IS NOT C problem I'll give up.
I suspect that what's going on is that when you highlight some text in your terminal window, its getting copied to a clipboard in the GUI. Or perhaps its not getting copied and you need to tell the terminal app to copy the text - usually, but not guaranteed to be, CTL-C. Otherwise, you might need to look into the GUI API for accessing contents of the clipboard. Note that many XTerm emulators seem to have 2 independent clipboards. There's one that you get when you merely highlight the text, and which you can then usually paste with middle-button on the mouse. There's also the Cut/Paste (CTL-C/CTL-V) clipboard. The two sometimes seem to be synchronized, but not always. In general, I think you should prefer the Cut/Paste method, as that seems to copy text to the GUI's idea of the clipboard, and is usually what you get back when you Paste. This is all a bit hand-wavy, because it seems like there's no hard and fast rules about what gets copied where during a highlight and/or a Copy/Paste.
Keep Calm and Carry On
-
I suspect that what's going on is that when you highlight some text in your terminal window, its getting copied to a clipboard in the GUI. Or perhaps its not getting copied and you need to tell the terminal app to copy the text - usually, but not guaranteed to be, CTL-C. Otherwise, you might need to look into the GUI API for accessing contents of the clipboard. Note that many XTerm emulators seem to have 2 independent clipboards. There's one that you get when you merely highlight the text, and which you can then usually paste with middle-button on the mouse. There's also the Cut/Paste (CTL-C/CTL-V) clipboard. The two sometimes seem to be synchronized, but not always. In general, I think you should prefer the Cut/Paste method, as that seems to copy text to the GUI's idea of the clipboard, and is usually what you get back when you Paste. This is all a bit hand-wavy, because it seems like there's no hard and fast rules about what gets copied where during a highlight and/or a Copy/Paste.
Keep Calm and Carry On
I am currently looking into this hack xterm has "log file " option and I am already redirecting the xterm output to a temp text file. Unfortunately they both include control characters, but I already have a function to extract only the humanly readable text. The hack would include adding another GUI level I currently have a single subwindow , I would add a new top layer "TAB" object and create "raw " xterm output tab -same as today "native window" extracted text tab - QT accessible plus my usual TRACE tab Little convoluted but that looks as the best solution so far Then I can "copy and paste " from one subwindow (tab) to another as my task initially called for.
-
The terminal app is started by Qt. Qt by itself does no keep track of terminal. My comment on highlighting the terminal window text "inside " Qt app is NOT Qt doing - hence if I start the terminal without "into" command option I can still highlight the text in the terminal "floating "window. I do not know why... or what process is highlighting the terminal window text IF Qt is no longer in the picture. That is the essence of this - how to keep Qt and external application communication going. Starting an external process / application without being able to communicate with it is useless ( to me ). It all runs under operating system and there should be a way to accomplish this. And if the answer is YES ( in runs under OS ) and IT IS NOT C problem I'll give up.
When you highlight text in a terminal it can usually then be copied by some keystrokes or menu option. That is fairly standard throughout Windows, MacOS and Linux. You can then paste it into another running application (e.g. the QT process that launched the terminal), but as far as I am aware you still need to do it manually. If you want direct connection between a calling and called process, then the called process needs to be a console type application. You can then connect the
stdoutof the called process tostdinof the caller, so the caller can read what the called process writes. The QProcess documentation explains how to do it. -
When you highlight text in a terminal it can usually then be copied by some keystrokes or menu option. That is fairly standard throughout Windows, MacOS and Linux. You can then paste it into another running application (e.g. the QT process that launched the terminal), but as far as I am aware you still need to do it manually. If you want direct connection between a calling and called process, then the called process needs to be a console type application. You can then connect the
stdoutof the called process tostdinof the caller, so the caller can read what the called process writes. The QProcess documentation explains how to do it.Thanks for the post. So far I am unable to copy from xterm , but I am working on that. As you said CTRL C is pretty standard and it should work. I will check the QProcess to see how to implement the console - in QT. There is something like that in xterm options, but I am not sure. That may lead to the solution.
-
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.