I'm trying to create a GUI for sudoku (for improving my QT5 skills). I have decided to use for these purposes a QTableView. Up until that point there is no problem.
Now i want to draw grids to make 3x3 fields more visible. Is there any ideas, how i can do that?
I would really recommend not using a QTableView for this, it's potentially solvable by using delegates (which are mostly for data presentation) but it would be very tricky. The best solution would be for you to build a custom widget by subclassing QWidget, building the paintEvent functionality and putting a data model in place. I know that building a custom widget certainly sounds more difficult, but it's actually quite simple.
Here's some good resources to get started with:
http://www.informit.com/articles/article.aspx?p=1405227
http://zetcode.com/gui/qt4/customwidget/
http://qt.developpez.com/doc/4.7/designer-customwidgetplugin/
http://qt.developpez.com/tutoriels/braindeadbzh/customwindow/
After that the QPainter class reference will be very useful to implement your drawing commands.
Related
What is the best method/pattern of using Qt's graphics view and model view framework together?
It seems like Qt should have somehow linked these two things together but did not. Could a QGraphicsItem just hold onto a QModelIndex and that would be enough? It sounds like bad solution.
Previously I assumed it would be better just to have some std::vector's of data, include this in a scene and display some of it in a QTreeView. This made undo/redo and syncing data quite difficult and so I'm trying to learn from my mistakes this time round!
I can't seem to find any definitive answer on this.
I'm not sure if this is still relevant but since I am currently investigating the same question i thought I will post a brief comment on what i found so far:
The ModelView framework is not as it is applicable to the QGraphicsView and QGraphicsScene framework. If you want to have your QGraphicsview and QGraphicsScene behave in the MV sense you'd have to subclass QAbstractItem and wrap it around a QGraphicsscene which is the QGraphicsView's model. If you don't need to visualize your model in different views I would not recommend in forcing a MV structure. Here is a discussion about this very topic:
https://www.qtcentre.org/threads/11763-GraphicsView-ModelView-Integration
I have tried to search on the internet and here as well, without success though. I am using Qt 4.8.2 and design my app in the Designer, then I write code in VS2010. I would like to show a chart on the application window, e.g. like http://www.infocaptor.com/user_help/help_img/dashboard_line_chart_screen.png , based on some data that are created by the app.
In the Widget Box of the Designer, I can't find any widget related to drawing. So I tried creating a QTextEdit and drawing on that using QPainter. However, this does not work. I can draw on the whole appwindow, but not just on the text edit. So the question is: what widget can be added onto the app window in the designer and that is going to allow me to draw on it using QPainter?
I'm eluded as the documentation says specifically that QPainter can draw on any QWidget which a QTextEdit is...
Any help is much appreciated,
Daniel
The function of "drawing" is tooo complex/unspecific to be included as a specialized widget. You'll have to create it yourself and implement the desired drawing functions.
Here is an example which you can learn from, the scribblearea class could be pretty much what you are looking for. In that case you can copy it to your project and use in in the Qt-Designer by promoting a widget to this class.
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
I need an appropriate rendering engine to render a 3D model into Qt, and use Qt then as an event handler to this model. Thank you.
As for the rendering engine, you can go several directions, but I'll mention two. Qt comes with an OpenGL widget. You could make use of this by either:
writing your own rendering code to render your model using OpenGL
or
making use of a rendering engine/framework which has it's own Qt Widget (possibly derived from Qt's OpenGl widget). I know OpenSceneGraph has Qt integration available. And I seem to remember Ogre does as well. This just to mention two options. Just Google for Qt and your favorite engine and you'll most likely find something suitable. And if not, it is usually not that difficult to write your own integration if you feel like it.
Whichever option is more suitable for you depends on the exact specification of what you're trying to achieve. You probably know that better than we do.
As for the event handling, you might want to be a bit more specific as to what you mean.
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.