This is a follow-up question of Making an editable flowchart in Qt/C++.
I want to add a QGraphicsItem to a QGraphicsGridLayout in a way that the item takes up its own spot in the grid and then automatically centers in its 'cell'.
I am using QGraphicsView and QGraphicsScene, and drag-and-drop to any location works, but it's looking messy, and could prove to be problematic in future development.
What do I have to do so the item snaps to the grid and centers in its cell?
PS: I have taken a look at http://qt-project.org/doc/qt-4.8/graphicsview-basicgraphicslayouts.html as an example but this didn't help me to solve my problem.
Also, it'd be ideal to have this layout and its data be savable to a text file, etc. I'm assuming a 2D array would be the best way to do this. Should I somehow make the QGraphicsGridLayout based on that array, or is there a better solution?
Related
I'm writing a messenger, and there is a message feed there. As you all know message feeds usually look like lists and go from bottom to top, the keep the scrolling positions anchored to the bottom when a new element is added, they grow upwards when resized and all kinds of fancy behavior like that.
So, I wanted to use QListView to make the feed, I have a model written elsewhere, it's absolutely under my control. But it doesn't seem like QListView supports this mode. There is a trick of how to do it with QML, but I don't have QML used anywhere else in my project and I'm not sure of how to interact with it, like how to set there my model, how to listen for signals or if it's going to behave well in my QGridLayout where I want it to place.
I can't believe no one ever faced the same situation. I'm trying to find the most standard solution, involving as little of my rookie code as possible, keeping in mind that Qt guys are much more experienced in layouting elements in list view and handling all corner cases. If I'm correct my options are
Use QML for the feed
Try to rotate QListView with QGraphicScene tricks
Reimplement QListView
Which of those you think is a better solution? Or, may be, someone knows some better way to do it?
This question already has answers here:
Use the same widget in two different layouts in Qt
(3 answers)
Closed 6 years ago.
I have a QMainWindow with a large number of graphs (I am using QCustomPlot for those). As a result, each graph is inevitably rather small in size. All the graphs in this page are drawn on the 1st page of a QStackedWidget.
To provide a clearer view for each graph (one at a time), I want to show a larger view of a graph when the user clicks on one.
A potential solution is to have a 2nd page on the QStackedWidget in which the larger graph can be shown. The question is how do I go about assigning the selected graph to the 2nd page of a QStackedWidget?
Alternatively, is there a better way to enlarge a specific QWidget so that it occupies the mainwindow from end to end?
How can I let the 2nd page of the QStackedWidget update its contents directly from the selected graph?
Is there an example I could see to understand what I should do?
In addition to the linked question, at this point you may be focusing on premature micro-optimizations. The smaller graph will be rendered on a much lower resolution, so it wouldn't look too good if you blow it up.
If it was your own custom widget with some complex drawing, you could easily draw onto a pixmap, then draw the big pixmap onto the big graph, and downscale it for the small graph. But then again, you'd be doing a whole lot of extra drawing for all those small graphs on the odd chance they get to the center position. You can optimize that, but will increase complexity.
It would still be possible to do it for QCustomPlot, but it won't be that easy, and I doubt the effort to do it will see worthy returns. So just create an extra big graph when you need it and don't worry about performance before you run into problems with it. The difference will be negligible, as graphs aren't too complex to draw. You won't be updating one graph from another, you will simply be using the same data set in two graphs.
I am trying to implement a TreeView where the item texts have a colored background and a frame. I do not want to put the frame around the whole item, but only around the text. Please have a look at this mock-up:
https://www.dropbox.com/s/irl8hedyxy520yy/screenshot.jpg
(a) looks like what I would like to achieve.
I understand that I have at least the following options:
(a) Replace the items of qtreeview with qLabel widgets.This is possible, but I believe that creating a widget for each and every item is a bad idea. I read somewhere else that an item delegate should be used in this case, and only the visible items should be widgets. That is going to be complicated.
(b) Use a stylesheet.It seems very simple and elegant, but I do not manage to frame only the text, and not the item which fills the whole column (see screenshot)
(c) Use a qStyledItemDelegate and paint the boxes and texts as I wish.Certainly possible, but requires a lot of code and complexity.
What would be the most elegant way to solve this?
I am using ruby, qtbindings, and Qt4.8, but my question is about Qt in general, not about the implementation with ruby.
Thanks for any help,
Bogl
I'm making my own UI from scratch using OpenGL that is why I'm asking this and please don't make any discouragement as this is just a hobby project.
Currently, I'm stuck implementing how this scrollbars really work. In my current implementation, the content scrolls at the wrong step value as well as the thumb, meaning, I set the value manually like 1px step for each of them.
The structure of my scrollbar implementation is describe as follows:
I draw scrollbars i.e the main rectangle where the 3 button lies.
Those 3 buttons are, thumb, buttonBack and buttonNext.
All of them do the basic logic of scrollbars i.e when I click each one of them, they moved. But the whole part(scrollbar) don't know how to scroll contents
So what I did is: I make another object and I call it scrollarea
It has two scrollbars, vertical and horizontal scrollbar.
I made a function called scrollToX and scrollToY which
does what I named to them.
But the step values I set to them are
manually set up.
I try to google some scrollbar, scrollarea, scrollview or whatever you call to that scrollable rectangle thing, but all I see are implementation and I cannot find any guides how to build your own. I have no choice but to look at their implementation. I try my best to comprehend what they did but their implementation of how their whole UI structure is very different to mine, and I cannot find anything useful there.
So I ask again here if anybody can explain me well how to make a properly functional scrollbar.
Most specific things I'm really concerned of are:
How do I determine the thumb step value?
How do I determine the content step value?
All of these depend on your content -
Is it just an image ? If so, you only need to change the offset depending on the size of the image.
Is it a list of values like in Windows explorer ? Then you need to create a data structure first that contains all of it, and shows the content that fits within the window as it scrolls.
OpenGL does not fit into this discussion.
I am building an editor using C++/Qt which has a click-and-drag feel to it. The behavour is similar to schematic editors (Eagle, KiCAD, etc), Microsoft Visio, or other programs where you drag objects from a toolbar into a central editing area.
My problem is that when the user clicks inside the custom widget I want to be able to select the instance of the box-like object and manipulate it. There will also be lines connecting the boxes together. However, I can't decide on an efficient method for selecting those objects.
I have two main thoughts on how to do the programming for this: The first is that the widget which is drawing the entire editor would simply encapsulate every one of the instances of the box. The other is to have each instance of the box (which is in my Model) carry with it an instance of a QWidget which would handle rendering the box (which would be in my View...but it would end up being strongly attached to the model). As for the lines connecting them, since they don't have a square bounding boxes they will have to be rendered by the containing widget.
So here is the summary of how I see this being done:
The editor widget turns into a container which holds the widgets and the widgets process their own click events. The potential issues here are that I don't know how to make the custom widget turn into a layout which lets click-and-drag functionality.
The editor widget takes care of all the rendering and processes the mouse clicks (the easier way in that I don't have to worry about layout...its just selecting the instances efficiently that I don't know what would be best).
So, now that there is a bit of background, for the 2nd method I plan on having each box-like instance having a bounding rectangle and the lines being represented by 3-4 pixel wide bounding rectangle segments (they are at 90 degree angles). I could iterate through every single box and line, but that seems really inefficient.
The big question: Is there some sort of data structure I can hold rectangles in and link them to widgets (or anything else for that matter) and then give it two coordinates (such as mouse coordinates) and have it spit me out the bounding box or linked object that those coordinates are inside of?
It sounds like your real question is about finding a good way to implement your editor, not the specifics of rectangle intersection performance.
You may be interested in Qt's "Diagram Scene" example project, which demonstrates the QGraphicsScene API. It sounds like a good fit for the scenario you describe. (The full source for the example ships with Qt.)
The best part is that you still don't have to implement hit testing yourself, because the API already provides what you are looking for (e.g., QGraphicsScene::itemAt()).
It's worth noting that internally, QGraphicsScene uses a simple iterative method to perform hit tests. As others have pointed out, this isn't going to be a serious bottleneck unless your scenes have a lot of individual items.