New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panel: Hide correctly upon the DragLeave #390
Conversation
@palinek The logic is the same as in #388, so it should work. I'll test it as soon as I have time. |
I'm a little busy now but I think that watching sub-widgets isn't needed because DragLeave is sent only when the widget accepts drops and that's the case only for some plugins, not their children. Am I missing something? |
We can't assume that, e.g. in the taskbar-plugin -> each tool button (presenting the window) accept drops. |
All right! |
The DragLeave event is not delivered to the parent widget while DND and the cursor leaves the parent and child (which also observes drag events) simulatenously. The panel needs to know about the DragLeave event (to correctly hide) even if there is no spare space between the child plugin and the panel edge. So we're observing the DragLeave events for all the plugins and its children widgets.
4d75a9d
to
02dc846
Compare
Sorry that I couldn't test it in time but it's good to see this merged! |
It's OK. Seems like we're all busy and don't have so much time for LXQt.... so I'm merging my PRs when there's nobody available to test/review. As we have a "stable" release we can use our "bleeding edge" users for testing 😄 |
I was busy with this, Kvantum and my house's burst water pipes (which aren't repaired yet 😞) but I always try to give priority to LXQt. LXQt should be developed at all costs, even with burst water pipes ;) |
The DragLeave event is not delivered to the parent widget while DND and
the cursor leaves the parent and child (which also observes drag
events) simulatenously.
The panel needs to know about the DragLeave event (to correctly hide)
even if there is no spare space between the child plugin and the panel
edge.
So we're observing the DragLeave events for all the plugins and its
children widgets.
callgrind
is showing zero time spent in thePlugin::eventFilter()
willShowWindow()
logic, because in case of standalone windows they mostly aren't children of plugins/panel.@tsujan can you, please, have a look on this and optionally summarize the pros/cons by confronting it with your solution in #388