I need a way for a QGraphicsRectItem to draw on top of its children. I have a item that contains several children items. At a specific height I need to draw a line over the child items.
Is there a way to implement a drawForeground in a QGraphicsItems similar to the drawForeground in QGraphicsScene?
If at all possible I would prefer to not have to draw the line for each child item.
I'm not entirely sure what you are trying to do but I suspect you will encounter a great deal of grief trying to fight the framework by trying to make a part of the parent draw over its child items. Perhaps you can add a top level child that is over the other child items covering a limited area, and renders the same content as the parent and includes the special overlay lines you want?
It might also suit your purpose to draw right over the scene from the graphics view.
Related
I am looking for a way to draw a node on top of the neighbouring ones in a HBox. Default behaviour means it is drawn on top of the previous one, but that also means the next one is drawn on top of it. For other containers, one could use the Node.toFront(), but changing the position of the node in the list containing a HBox's children also changes the actual position in the HBox, which is unwanted behaviour in my case. I appreciate any help, thank you.
EDIT:
The overlapping occurs when applying a DropShadow effect on an Ellipse and wrapping them in a StackPane along with a Text. It looks like the effect has a weird interaction with the HBox, as it works as intended without it. After adding the effect, it allocates more horizontal space for the ellipse, but not enough to cover the margins of the effect. Also, when clicking anywhere in the whole right half of the black rectangle, the mouse click is dispatched to the stackPane event handler, not to the rectangle's.
This happens
In VBox and HBox, the Node.toFront() and Node.toBack() functions will change the layout, so they are not usable. If you are using JavaFX 9+,you can use the viewOrder commands to change the rendering order of the Node in its Parent:
Node.getViewOrder()
Node.setViewOrder()
The default value of viewOrder is 0, so setting it to -1 will render it above all others. You can customize this to get specific orders. It also has a CSS property -fx-view-order.
I am creating a Qt application where I need to display contents in an overlay box(Please refer to the attached image). The box needs to slide up from behind the bottom dock when a button is pressed and slide down by toggling the button. I tried with a QWidget but couldn't achieve what I wanted. Also I don't know how to list the elements in the overlay box. The elements are dynamic or changing.
The widgets stacking order is defined by their order in the QObject hierarchy tree. The first element is the bottom, and every next is on top of the previous. Children are on top of their parents, in widgets confined within their bounds, in QML free.
If you want that sliding element to appear on top of everything else, just put its parent on top of everything else.
After all it is on top of the bottom control bar, which is on top of the playlist, so you have it all worked out for you.
The same applies if you decide to do the wiser thing and use QML instead of QWidget. Animation and states are much easier there. Not to mention more specific designs.
I'm working on a simple widget system, and I'm implementing some containers right now.
Here's the situation I find myself in:
I have a Widget base class, a Container class, which is a widget that can contain other widgets, and several widget sub classes like Button.
I have two types of container: Container itself, which positions children absolutely, and Box, which will stack widgets next to each other, either horizontally or vertically.
Each widget draws itself at x=0, y=0. Therefore, containers need to add an offset to the drawing context before the widgets are told to draw themselves.
Each widget does its own hit testing based on its x/y position.
So far, it works fine. But it falls apart now that I'm implementing Box: What I do is that I overwrite the drawfunction inherited from Container to draw them all in next to each other, instead of based on their x/y position. Quite simple.
But event handling is totally off now, as the widget's x/y position has become meaningless.
I think I have two options:
Have the widget do hit testing at position x=0, y=0, like drawing. Then recalculate the mouse position to match that in Container.
Make each layout set x/y for its children, and make children draw themselves at their x/y position again. No more offsets for the drawing context
The first one is a bit ugly, I think. The second one is pretty complicated to implement, since I need to react to position changes in widgets.
How to other widget systems like Qt, Gtk and wxWidgets generally tackle this? I've looked at the source of some of these, but can't quite figure that out, it's too sophisticated. I don't have any resizing or packing issues to consider.
You are trying to implement your own layout system. You should expect it to be difficult.
I would advise against the first method. The x,y coordinates of a widget are not only used by the widgets themselves, but by anyone outside of the container who wants to do something with the widget.
The second solution is what I've chosen to implement custom widgets made of several smaller widgets and it's not that hard to put together if you don't want too many features.
Just get the widgets when they are added to your container, set their position to the current free spot, and move on to the next.
I've got QListWidget as a child inside QPlainTextEdit for purposes of completion suggestions.
Suggestion list is displayed under cursor and when line is almost full, part of list widget is cropped by the border of text edit. Is there any possibility to force child widget show out of parent widget region?
An idea I have, is to make the text and list edit elements "siblings", i. e. add them to the same parent. But this would require my event handling mechanism (as I suppose parent-child relation between those two elements).
I think there must be a way to achieve this, as I studied Katepart component and there is KateCompletionWidget (displays suggestions) that is direct child of KateView and when I run it (e. g. Kate text editor), the list is shown across text edit border.
There's no way for a child to paint outside of a parent's QWidget rect, unfortunately. Your sibling approach is a popular solution to this problem. Another approach is for the child to notify the parent of what it wants to draw, but this can be a bit more advanced because you have to re-implement paint events.
Today I found a possibly viable way -- it's based on setWindowFlags(Qt::ToolTip) method of QListWidget element. There's, however, some slight change in positioning and event handling.
I have a component which draws a grid of things and I want a small highlight square to follow the mouse around highlighting the square that the mouse is currently over.
The whole grid is basically just one big sprite (it's a very large grid and this was faster than using pre-existing components) and the highlight square is another sprite which I'm trying to move around according to the mouse position.
So, what I have is a MouseEvent.MOUSE_MOVE handler attached to the grid sprite and this tries to determine where the mouse is and what square it's over so that it can move the highlight square to the right place. I was using localX/localY for this, but as soon as I move the highlight sprite under the mouse, these become local to the highlight and not the grid!
I was toying with stageX/Y as well, but these seemed to become pretty useless when the stage is scrolled or your component is hiding in nested display containers.
Basically, i think, you want to check the the grid components mouseX and mouseY property which will give you the mouse coordinates relative to that component. Then a little bit of maths should be able to give you what grid element you are over.
Assuming your highlight sprite is a sibling to the grid and they are both children of the main application, and you've drawn child sprites (squares) within the grid: You could add event listeners to each of the grid's square sprites. On rollover, highlight the square. Then you probably won't need to perform any translation of grid or mouse coordinates using grid.localToGlobal(new Point(targetSquare.x, targetSquare.y)) or highlightSquare.globalToLocal(grid_point).