QGraphicsItem - clipping all child mouse events that are outside of parent

[ivan.cukic]

Well, technically, it is not outside of the widget - it is inside the child widget, but outside of the parent.

You can see what I mean in the attachment.

So, the events occur in the not visible (clipped by parent) parts of the child widget. (it is represented by the mouse pointer hovering the clipped part of the 3rd child widget in the mockup)

As the documentation states, it *is* the correct behaviour, but it is illogical when the children are clipped to parent.

Unfortunately it can't be done by checking whether parent and child are hovered since parent thinks it is hovered when one of the children are.

[aamer4yu]

Two questions -

1) Why cant u increase parent to include all the children in it ?

2)

Unfortunately it can't be done by checking whether parent and child are hovered since parent thinks it is hovered when one of the children are.

why so ? if u override the hoverevent in child item and check if that point lies in the parent or not, u can ignore it ?
if(parent()->contains()->mapToParent(event->pos())....
hope u get the idea

[ivan.cukic]

1) Why cant u increase parent to include all the children in it ?

Well, as I said, I want to implement a scroll-pane like widget - it is meant not to show all items - it has to have a fixed size and to provide mechanism for scrolling items in it (scroll bars etc.)

why so ? if u override the hoverevent in child item and check if that point lies in the parent

I know what you mean, but the scroll pane should be general enough to hold any subclass of QGrItem, so I can not override children's methods.

[OnlyWhisky]

Have you any success with hover events? I'm implementing scroll areas as QGraphicsItems too. Is your code public?

[ivan.cukic]

Well, I haven't done anything yet. Had a couple things to do before that. The possibilities as I see them are:
- override the hover events in children (as suggested by aamer4yu) which I don't like for mentioned reasons
- use a QGraphicsView as a widget on canvas - inside another QGraphicsView. I don't like this approach since it could potentially introduce presently unforeseen problems, and breaks the MVC in a sense
- do nothing and don't care. And leave the filtering to children if they want to be filtered. This approach is possibly the best since it could incorporate the first two in it.

As for the code, it is in http://websvn.kde.org/trunk/KDE/kdep...lets/lancelot/ but as I said, currently there is no code for this. The current implementation for the list views uses a fancy-looking dirty hack of resizing items on the edges so that they fit into the view.

[wysota]

I just scanned through this thread so what I suggest may have already been tried by you and if that is the case, sorry for the fuzz. Have you tried using scene event filters? You could filter all events in the container item and check whether the target item is inside or outside your shape or bounding rect and based on that discard the event (return true) or let it reach the child (return false).

[ivan.cukic]

@wysota
The idea is ok, but there is a small problem:
1. If we use the mouse move event to detect /hovers/ and /leaves/ it has a bigger performance impact than it should (on every move, we should check whether it is in or out)
2. If we don't do it that way but only filter the hover/leave events, then we get a bug when we hover the clipped part of the QGrItem, and move the mouse to the non-clipped part since we will not receive another event for that.

[wysota]

At least you get proper behaviour for items that are completely disjoint from their parent. For others you might try some heuristics or hybrid approaches.