I'm looking to create a cross-platform readline/linenoise type command line interface for an application in Qt. I'd rather not reinvent the wheel if possible. The terminal in which the user is operating should be able to receive commands via a command prompt. This will be done in Qt, thus my question is: is there a Qt-esque way of doing this via signals and slots such that when a user enters a line into the terminal a slot can be called?
I understand that this can be fairly simply done using a QThread and running a blocking process to signal on a line being read. This question is specifically geared towards using built-in Qt functionality.
While attempting to discern a viable answer to this, I realized that my question was improperly phrased. I was looking for what could be termed a Terminal Emulator. There are several existing solutions to this, including QTermWidget. However, it appears that there does not yet exist a non-UI based terminal emulator for Qt. That is, in order to use these one must have an active UI instance of Qt, not merely employing a Qt Command Line application.
Going the route of using a simple Qt Command Line, it is not as simple as connecting something like a QTextStream and observing the output of the command line. As with most command line programs, native, low-level processing must occur in order to assess things like the arrow keys. Unfortunately QKeyPressEvent and the like require the UI to be running.
Related
I am writing an application in Qt which gets executed by a launcher app. How can I detect whether the Qt application was launched by the user or the launcher. Is command line parameters the only way or is there a better way?
Both the Qt app and launcher are written by me.
Lots of ways. A command line parameter could be easily sniffed (by Process Explorer, e.g.), if that's a concern. But a named mutex or some other interprocess handle that can be inherited by the child app would be more difficult to spoof.
I am a beginner is C++. I am trying to find, is it possible to run my program in both in QT window and Linux based. When the user logins into my system, the user can select GUI or terminal mode to run the system.
Thus, I would like to know is it possible to do it. If possible how can I proceed on? What command should I use to switch from a QT window to a terminal?
Do I need to create a separate set of project for both individually or using the same set of classes?
All Linux programs (unless explicitly disabled) print out text to a terminal. If you run the program in a graphical environment you will probably not run it from a console, therefore you won't see the output, but it will be still there.
If you want your program to be usable from a console, just test whether you could create the main window and if not, fallback to simple text output.
Note that the binary will still require the X server and Qt libraries to be installed.
You can construct your application with or without the GUI enabled through the QApplication constructor. Consult the example in Qt's documentation:
http://qt-project.org/doc/qt-4.8/qapplication.html#QApplication-2
Though, it should be noted that everything in Let_Me_Be's response is correct. In fact, the Qt example does exactly what he's suggesting. Please take the time to understand his answer before you plunge into coding.
I have 2 programs. Console and QT. Console program should make some data , and qt program should than show this data. But this should be separate programs, and i do not know how can i tell QT program to do somthing from my Console. Two programs are local and Qt program is always running (so that i can not just run it every time), and Console is only lunched when needed. So the question is - how can i execute somthing in Qt after console program finishes?
P.S. The console program makes a file that Qt program can read and than display.
I'm using windows.
Int Qt, you can start the console process with QProcess. That class has a finished signal, which you can connect to a slot in your application object. Then, when the console process finishes, the finished signal fires, and your slot function is called. At that point you can read the output file.
This is more efficient than a QFileSystemWatcher because you're directly watching the relevant event (console program finishes).
You might consider using something like QFileSystemWatcher to poll for changes in a particular directory, then have your console program write the file there. That way the Qt program would get a notification when the contents of the directory change.
Interprocess Communication (IPC) is the solution you're looking for.
The MSDN documentation is available here, containing more details about implementing this in your application, as well as code samples.
This technique is called "Screen scraping". You are doing this by connecting console app's stdout to Qt apps input.
Look at http://doc.qt.nokia.com/latest/qprocess.html
Take a look at QSharedMemory: http://doc.qt.nokia.com/4.7-snapshot/qsharedmemory.html. It allows inter-thread and inter-process communication.
A very nice and short example on how to use QSharedMemory is here: http://doc.trolltech.com/main-snapshot/ipc-sharedmemory.html
I'm looking to add an element to my wxWidgets GUI that behaves like a terminal emulator. Not in terms of a shell which executes commands, but just the input-output setup of an application running in a terminal.
Basically, the requirements are:
Streaming input/output: When you enter a character, it is added to an input stream, and when something is piped to the terminal, it prints out immediately.
No editing: Once you type in a character, it's permanently there, since it's probably been consumed by the application running in the terminal.
Some sort of scrolling (even if it just shows a few lines or something).
It would be nice if there is something that already does this, but suggestions on how to implement this with already existing controls such as wxTextCtrl would also be welcome.
I know this is a couple weeks late, but hopefully it's still useful. I've got a project called Chameleon that uses a wxWidgets-based VT100 terminal widget, which was itself based off of a project called taTelnet. The Chameleon source is available from my website (download page here). Not sure if it's exactly what you're looking for, but it might give you some ideas. Feel free to let me know if you have any questions about it.
wxWidgets supports redirecting STDOUT to a wxTextCtrl via wxStreamToTextRedirector. As for input, you could override the OnChar event in a wxTextCtrl-derived class to handle this.
Greetings overflowers.
I am trying to add a GUI to to an existing project. More specifically to a plugin that is loaded as a .so file (or when compiled on win32 a .dll)
The project has its own threading implementation already to deal with portability. I know that Qt has its own cross platform threading model but it would be preferable to stay within this existing threading model.
My question to the Qt veterans out there [I have only just started reading the docs] is: Would it be possible to embed a GUI using Qt in to a plugin as described above? The plugin already is a command line interface and I would like to have the GUI optional, even if its compiled in. Since those standard functions get called by the main program, the GUI (which I assume will live in another thread) will have to be accessible or able to have methods called on it so that the CLI thread can coexist and the standard functions can work with any permutation of the two interfaces.
edit 1:
after playing with the code a bit I am able to launch a simple GUI from the plugin. The plugin already is the CLI and has functions that are called from the main program. I simply created a new thread on initialization of the plugin and launched the blocking GUI from there:
QApplication app(NULL, NULL);
window = new zGui;
window->show();
app.exec();
The question here is: Is it possible to communicate with the GUI or rather access GUI elements from the CLI thread?
edit 2: some results
Alright, so far starting the blocking GUI in a separate thread has worked with no problems. I am able to access widgets in the GUI from the main plugin thread as well. I understand that this practice is discouraged as not only per the answers I've received so far but also the Qt libs are spitting out some warning about unsafe access by another thread.
As of now I have only been working in a linux environment, perhaps real issues will be presented on other systems. I have seen only one glitch that I can not say for sure is related:
Upon changing the the max and min values of a progress bar widget, the progress bar appears blank. I was able to apply a simple fix to this by the following
//here is me setting the values
window->progressBar->setMaximum(character.maxHP);
window->progressBar_2->setMaximum(character.maxMP);
window->progressBar->setValue(character.curHP);
window->progressBar_2->setValue(character.curMP);
//and here is the fix
window->progressBar->setVisible(false);
window->progressBar->setVisible(true);
window->progressBar_2->setVisible(false);
window->progressBar_2->setVisible(true);
I suppose my final question is 'What specifically are the situations where accessing a Qt GUI from an other thread is unsafe and why?'
You can use a Qt GUI from a dll or so that is called from a non-Qt application, but it cannot be from a secondary thread, it has to run in the main thread. And the application event loop is started via a blocking method that returns when the GUI is closed out, so if you needed to have logic running in your app that is independent of the GUI, then that logic would need to be running in a secondary thread.
If you felt ambitious, you could modify the QCoreApplication and QEventLoop classes in such a way that you can manage the event loop from your calling application, and it probably wouldn't be all that difficult. But as far as I know there's no way to do it with Qt out of the box.
Consideing to Gerald answer, might I suggest that its better to keep the CLI (your app) separate from your apps GUI (ergo, a separate app).
Make your GUI app use the cli in the background. its easily done by using QProcess.
cheers!