Enter event mouse position

[bunjee]

Hey there,

I'm using a custom QListView.
When I'm opening a widget above the view and closing it I get:

- An enter event in the view.
- No mouse move event.

Is there a way to get the current mouse position in an enterEvent ?

Thanks.

[wysota]

You'll only get mouse move events if the mouse button is pressed. If you want to receive mouse move events for a widget without pressing the button, enable mouse tracking for the widget (the viewport in case of the list view).

[bunjee]

Yeah I did that:

viewport()->setAttribute(Qt::WA_Hover, true);
	viewport()->setMouseTracking(true);

viewport()->setAttribute(Qt::WA_Hover, true);
	viewport()->setMouseTracking(true);

To copy to clipboard, switch view to plain text mode 

I get mouse event in every situation, except when:

- I create a widget on top of the QListView.
- I close it.
- I do get an enter event on my QListView but no mouseMoveEvent.
- When I do move the cursor I do get my mouseMoveEvent.

So I need to move the mouse to finally get a mouse event on my QListView.

Thus my question, can I grab the cursor position in the EnterEvent ?

[wysota]

You can always call QCursor::pos().

[bunjee]

My interface is heavily based on enter / leave event.

When I have a widget on top of another and closing it I don't get the "expected" enter event on the underneath widget.

Do you have an idea for a generic implementation of real enter / leave event, because from my point of view, entering or leaving shouldn't only concern widget's boundaries.

[wysota]

My interface is heavily based on enter / leave event.

That's not a good design.

When I have a widget on top of another and closing it I don't get the "expected" enter event on the underneath widget.

You won't receive it, because there is no situation that the cursor is "outside" and moves to become "inside" the widget and only this situation can be called "entering".

Do you have an idea for a generic implementation of real enter / leave event, because from my point of view, entering or leaving shouldn't only concern widget's boundaries.

I suggest not to rely on enter/leave events or at least not as the only means to detect interesting situations.

[bunjee]

That's not a good design.

It's just that every single of my widget has an highlighted behaviour. That makes sense to me.

You won't receive it, because there is no situation that the cursor is "outside" and moves to become "inside" the widget and only this situation can be called "entering".

I think that's odd there is no built in solution for that matter.

I suggest not to rely on enter/leave events or at least not as the only means to detect interesting situations.

I'm not only relying on enter/leave events. It's just I think it's a design flaw when the cursor is on an interactive item and nothing tells the user it actually is.

And I have that issue both with widgets and items.

Qt items are just not made to be highlighted.

[wysota]

It's just that every single of my widget has an highlighted behaviour. That makes sense to me.

You don't need enter/leave events for that. Other events and the WA_Hover attribute are good things to try.

I think that's odd there is no built in solution for that matter.

What do you mean "built in solution"? There is no problem here. It's just you understand the word "enter" differently than other people. If you look closely, you'll see that tooltips have the same behaviour as you are experiencing - that's perfectly normal.

I'm not only relying on enter/leave events. It's just I think it's a design flaw when the cursor is on an interactive item and nothing tells the user it actually is.

That's not true. You are trying to use events that tell you about moves to inform the environment about the state. If you want the state, ask about the state. QWidget::underMouse() and QWidget::isUnderMouse() are perfect candidates for the job.

Qt items are just not made to be highlighted.

Strange... I have no problems with highlighting items using only the delegate's paint method and seems that Qt styles have no problems in highlighting widgets...

If it's just about painting, use WA_Hover and do the painting in the paint event based on the state of the widget.

[bunjee]

You're right,
Let me rephrase this:

"Qt items are not meant to have highlighted behaviours"

Don't get me wrong,
On the styling approach, highlight works fine.
When you do get serious about implementing a full highlighting behaviour like this:

- My cursor "goes into" the widget
- Severals menus and widgets appears at given positions.
- My cursor "goes out of" the widget.
- Everything is cleaned up and goes back to normal.

Aside from styling, when you look at every single widget in Qt, they don't have highlighted specific behaviours.

Say for example my cursor is in a listview of items:
- The cursor is inside the widget, so I do get my interface options and buttons.
- Now I click the close button.
- The items gets deleted and widgets deletedLater().
- Since my widget is deleted in the list another pops under my mouse cursor.
- Since the entered event is never called, when do I call my create widget function ?
- The solutions for that matter is: force Qt to scan for "mouse under" item at every deletion.

Now if highlighted behaviour beyond graphical appearance are bad design for you I understand you don't care, but in my case it's annoying.

[wysota]

I didn't say they are bad design, I said basing them on enter/leave events is bad design. Tooltips work exactly as your "highlight" techniques and they are not updated/changed when some other item "pops up" under them without the mouse being moved. But I think this unexpected behaviour is fine, if you want to interact with anything, you will have to move the mouse eventually and then appropriate events will be triggered.