I am trying to understand if it is possible to include a PyQt5 widget inside my Qt-C++ application.
There is a lot of information about wrapping C++ class into python and using it from the python side, however, my question is the opposite.
I tried boost-python, pythonqt, and some other resources, but none of them give a clear answer whether it is possible or not. Mostly they allow to call python scripts and, in case of pythonqt, as I could understand, connect signals and slots, but not to attach one object to another.
Explanation: I have a widget in PyQt5 inherited from QWidget and I need to use it in my QMainWindow in C++.
Is it possible to achieve this? And if so, how can I do it?
Related
I don't do a lot of Qt programming so this may sound like a silly question, but what happened to QListViewItem in qt4?
I have this application I wrote some time ago in qt3. I changed that to qt4 using the aptly name "qt3toqt4" program (all this on a Fedora platform).
Internally it seems to change a lot of classes from QClass to Q3Class (probably to provide some sort of backwards compatibility) and then compile it with qt4. I had some problems with it today (to do with reading stdout from a QProcess, but that aside) and I decided to simply rewrite the application in qt4.
Now for the problem - I use a QListView and to this I add loads of QListViewItems in a tree like structure. Something like this:
But that doesn't seem to be available anymore in qt4. And I can't find any examples that provide this behaviour either. Is there a way to do this in qt4? To maybe make it more complicated - I used my own QListViewItems (derived from QListViewItem) ...
The widget you are looking for in Qt 4 is QListWidget and its item class QListWidgetItem. It pretty much corresponds to the QListView widget in Qt 3 with a classic item-based interface for adding and removing items. You can subclass QListWidgetItem just as you subclassed QListViewItem in Qt 3.
Just to complete this question. It is QTreeWidget and QTreeWidgetItem that implement this behaviour in qt4.
In general, is the order in which I add my widgets into each other, the same order I access them back?
Example:
If I have a bunch of QPushButton in a QHBoxLayout, and this layout in a Window::ui,
can I access those button by simply ui->button_name? or Do I must do ui->layout->itemAt(idx)?
EDIT: My question aims to find an easy way to access elements that are deep into the hierarchy, like a label in a frame, inside a layout, inside a frame, inside the window etc...
PS: Also, I would really appreciate any documentations about good practices of GUI architecture!
Use ui->object_name you don;t need to worry about the layout!
It's possible to redesign the layout, eg. for different platforms, without changing any of the C++ code.
There are a couple of good books on Qt and the sample code is very good.
C++ GUI Programming with Qt 4
Advanced Qt Programming
Im just pondering best practice with an application I'm developing. Its a simple one window application using qt creator. It's just going to start a QProcess and show the output in a QTextEdit box. To do this there needs to be a bit of processing between the output of the QProcess and the QTextEdit but i dont know where i should do this, should i create a new class to do that or add member functions and extra signals and slots to my main window? I dont want mainwindow to become bloated and hard to read but equally i dont want to have more source files than really I need.
Any thoughts?
The main window class can very easily get bloated with all kinds of functionality. I've dealt with that myself, so it's a very real trouble.
Really, though, this is not so much of QT question as it is an object-oriented design question. The key is that your output window does not need to be a part of QMainWindow, so it probably shouldn't be. Make the display a widget, and insert it onto the main window. That is much more flexible, as if you ever need to move that output pane for any reason, it won't be coupled to a specific part of the program.
The logic that feeds data into that output pane should also get its own class, separating the responsibility for displaying the output from the responsibility for acquiring the output.
For reference on the concepts behind my suggestion, see the Single Responsibility Principle and the separation of concerns.
Also - you may wish to have a read at this link to model view delegate information which is how I tend to develop in Qt. Like the person above says - this is more a question of good OO design.
I am new to Qt Creator 4. When I create a new project it gives me the option to choose a base class:
QWidget
QMainWindow
QDialog
I am confused which to choose. What difference does it make?
Does it also effect the code?
Kindly explain in simple words.
QDialog is specifically designed for dialog or "pop-up" windows. These are dialogs generated from your main application, useful for things like Open/Save dialogs or informational messages.
QMainWindow is a specific widget that has things like a menu bar, tool bar and status bar built-in. This class is useful for the main application window to fit around your main UI.
QWidget is the base of every GUI element, so it's a catch-all. It's less specific than the other two classes, but in exchange it's more flexible.
You should choose the one that best fits what you are creating. Obviously the way you write the code will be effected, as they are different classes, but all are still QWidgets.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to enhance Qt's QPrintPreviewWidget by allowing it to display page numbers (in the footer somewhere). Unfortunately, I can't quite figure out how to go about it without hacking up Qt's source. I see a great spot for this additional code (in qpaintengine_preview.cpp, in newPage() method) but that means I'm going to have to recompile the whole of Qt (I got a binary build from Trolltech). Furthermore, if I decide to run an app that uses this functionality on someone else's box, I'm going to have to recompile there as well (say if it's a different arch).
Are there any other cleaner ways?
Thanks
Is the newPage() method virtual? If so, you could subclass and use that in you own applications, which would be a bit easier.
The second option would be to statically link your executable with the modified Qt libraries. You need to be aware of licensing concerns to do this. This way, every place you put the app will have your modified functionality. (You would still need to recompile for different architectures.)
Finally, you could get the latest sources from http://qt.gitorious.org/, modify them in the way you desire, and submit a patch back to the trolls. If you do this, you'll probably have to keep the old behavior the default, and add an option to enable the new behavior. They may or may not accept the patch. And if they do accept the patch, you may not be able to rely on other people's computers getting that version for quite some time, if ever.
Read the source code.
In this case, read QPrintPreviewDialog source code to see how it does it. This standard dialog has navigation buttons and a current page display, so it kind of does what you want (that is, if I really understood what you want to accomplish). The methods you're looking for are the following (src/gui/dialogs/qprintpreviewdialog.cpp):
void QPrintPreviewDialogPrivate::_q_previewChanged()
void QPrintPreviewDialogPrivate::_q_navigate(QAction* action)
void QPrintPreviewDialogPrivate::updateNavActions()
Basically, _q_previewChanged() is connected to QPrintPreviewWidget::previewChanged() signal. When it is emitted, the page number is updated with information acquired from QPrintPreviewWidget::currentPage() and QPrintPreviewWidget::pageCount().
As for extending the behavior of QPrintPreviewWidget you can try two approaches, both of them do not require a tailored version of Qt:
Extend QPrintPreviewWidget
In the constructor, access the layout() (it is a QVBoxLayout that is used interanally), add the footer widget, connect the previewChanged() signal to a slot that updates the page number and be done. The problem with this approach is that it counts on the layout to be present and be a QVBoxLayout. Since this is somehow private, it can break with newer versions.
Create a new class extending QWidget or QFrame
If you don't require your widget to be a QPrintPreviewWidget, just create a new QWidget derived class and add the print preview widget and the footer to a layout, connects slots etc. Use your derived widget instead of QPrintPreviewWidget.
Now, if you want to modify the behavior of the widget on already deployed binaries, things get uglier. I cannot help in this case.
If you have a library and this library has same symbols linker at runtime is looking for - to get the code for the print preview - then you can inject your own code to replace the real implementation. Method is called dll injection.
Check http://en.wikipedia.org/wiki/DLL_injection for more info