QProcess running "xterm" - how to read / write directly to "xterm"

Anonymous_Banned275

Thanks for all the comments. I was not aware of -info option - it looks promising.
I would like to stress - I an trying to resolve TWO issues - communicating with "bluetootctl" and embedding any terminal application in QTabWidget.
I have the communication part under control...

To embed "terminal" in QTabWidget it has to be widget.

The example referenced does exactly that - creates a widget based dialog - that should work...

What got me going wrong direction - at one point the "window" created by QProcess had a default icons and title of my entire application - that tells me it has to be something compatible with widget or QT object - but I was unable to find what it is and how it fits n my application hierarchy.... so I called it "top floating window ". ( I think QProcess doc may have something about the actual GUI it builds ...)

JonB

@AnneRanch
Honestly, QProcess does not build any GUI. It knows nothing about widgets, windows or anything UI. It just runs an external program.

You can either embed a visual terminal and then your code cannot interact with a spawned bluetoothctl program, or you can send/receive i/o to/from it via stdin/out and no visual terminal, but not both. So long as you keep the embedded terminal and the communicating with bluetoothctl as separate things that is OK.

Anonymous_Banned275

This is embarrassing, but I am stomped - again.
I have solved the embedded issue - with simple dialog etc.

I have been using QTABWidget and never had this issue - switching tabs does not stop showing the previous tab
Apparently I am missing a step ....especially when the tab contains a dialog. (Why ?)

I found this "slot" on_tabWidget_26_tabCloseRequested(int index) but cannot find anything on how and why to use it .
I really do not want to "close" tab anyway- just switch to another one.

                        switch(index)
            {
            case 0:
            {

                Form_TERM_Dialog *FTD = new Form_TERM_Dialog();
                FTD->show();

            break;
            }
             case 1:
            {
                Form_TERM_Dialog *FTD = new Form_TERM_Dialog();
                       FTD->show();

            break;
            }
             case 2:
            {
                Form_TERM_Dialog *FTD = new Form_TERM_Dialog();
                       FTD->show();

            break;
            }
            }

JonB

@AnneRanch
QDialogs --- assuming that is what your Form_TERM_Dialog is --- cannot/should not be shown in tabs. From the docs:

A dialog window is a top-level window mostly used for short-term tasks and brief communications with the user.

So I don't know what you have meant by "the tab contains a dialog". If you mean the code you show is executed on changing tab, then it creates and shows a quite separate dialog window. Switching to another tab would not in any way close or affect any dialog created from code on switching to a tab previously.

This might be what you mean by "switching tabs does not stop showing the previous tab" --- it won't affect showing a previously opened dialog.

If --- and I don't whether it is --- your goal is to be able to close these previously opened dialogs from code (as opposed to the user clicking its close box) you will need to store your Form_TERM_Dialog *FTD somewhere else than in a local variable, so that you can access it at a later time.

Anonymous_Banned275

@JonB I hope I can clear or restate what is happening

My primary user interface is QTabWidget - lets leave the details out of the discussion.
To add QProcess into the tab - it has to be a widget - hence dialog .
That part works but the link between tab and its dialog is not clear.
That is not why I added the dialog .
It still looks as an "dependent ", but real dialog and top floating
So - the tab code can create / build the dialog BUT it is NOT part of the QTabWidget - since switching tabs DOES not affect that.

It is relatively irrelevant what to call this setup - it does not do the task indeed.
Back to the drawing board....

PS I am going back to the "pop-up" dialog - already forgot the name ....

JonB

@AnneRanch said in QProcess running "xterm" - how to read / write directly to "xterm":

To add QProcess into the tab - it has to be a widget - hence dialog .

A QTabWidget accepts QWidgets as the "pages". The example I referred you to for an embedded terminal, for instance, uses a QWidget. A QDialog is not suitable for a tab widget page, as already pointed out it is designed to be a top-level widget, not a child in a tab widget.

From what I can see of the code you showed you are not adding a widget or dialog to the tab widget. You are opening an unrelated, separate dialog each time.

Anonymous_Banned275

Partial success , but still not home free...
I have made a major mistake NOT specificity the "parent " of the test widget.
After correcting that I can see the test label ( from test widget) in proper "page" and I switch the tabs / pages - no problem.

I assumed that the QProcess should also use the passed parent.
That does not have expected result - being able to close the page and open another one.
In other words - attaching the QProcess (display) to same parent instantiate the QProcess but cannot be closed /
switched as part of the TAB widget fynction .

On top of that - I am having a real difficult time to debug / step thru the code - it seems that GDB does not handle code with "time dependency" well.

If I am on right track establishing "parent" hierarchy (?) I am back to my "floating window " theory - I cannot prove the QProcess "parent " using GDB.

Edit
I have added simple debug message

void MainWindow::SubWindow(int index) index 10
parent QWidget(0x561010725df0, name="tab_148")
processTERMINAL->waitForStarted() OK
""
""

Anonymous_Banned275

Some "news" - not sure if good or bad
As far as switching tabs / pages
After adding "page as parent " I can open the new page AND the old one moves into background - way below the main MDI window. ( I am not really sure if it is because the parent addition ... did not observed that before...)
So it is back to "windows " hierarchy - from being on top - it is now "on bottom of the totem pole " .
So - if it can be moved by whatever unknown process - I should be able to delete it ...

Anonymous_Banned275

..for time being - I am cheating
I just maximize the main window and do not care how many copies of xtrem are hiding behind it .
TEMPORARY HACKED

Anonymous_Banned275

More success...
After adding -info to xterm options the xterm is now actual part of QTabWidget and tabs gets switched properly.
If the first page xterm has +hold option it works fine , however every other page has to have -hold . If +hold is also optioned
the page just flashes...

However -the xterm never gets terminated , its GUI just no longer shows... - something to work on

Interestingly and somewhat expected - the QProcess "window / frame " no longer shows either - perhaps another option ??

I would like to express my appreciation to all who helped with this messy task.

After all this I realized I want to have multiple "xterm" - with different options - visible ...
I think "MDI" is next.
Thanks