Skip to content
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

Merged
merged 1 commit into from Jan 17, 2017
Merged

Conversation

palinek
Copy link
Contributor

@palinek palinek commented Jan 10, 2017

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.


  1. With this we don't need to do anything special in particular plugins.
  2. At first look it seemed to me as a bad idea to observe all the children (and its children ..) objects/widgets, but a simple check with callgrind is showing zero time spent in the Plugin::eventFilter()
  3. We probably can't extend this logic to remove the 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

@tsujan
Copy link
Member

tsujan commented Jan 10, 2017

@palinek
This is better than my solution in that it's centralized (as you wanted at #388 (comment)). I didn't have time to improve #388 but if I did, I'd do something like this.

The logic is the same as in #388, so it should work. I'll test it as soon as I have time.

@tsujan
Copy link
Member

tsujan commented Jan 10, 2017

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?

@palinek
Copy link
Contributor Author

palinek commented Jan 10, 2017

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.

@tsujan
Copy link
Member

tsujan commented Jan 10, 2017

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.
@palinek palinek merged commit 02dc846 into master Jan 17, 2017
@palinek palinek deleted the hide_on_dragleave2 branch January 17, 2017 08:51
@tsujan
Copy link
Member

tsujan commented Jan 17, 2017

Sorry that I couldn't test it in time but it's good to see this merged!

@palinek
Copy link
Contributor Author

palinek commented Jan 17, 2017

Sorry that I couldn't test it in time

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 😄

@tsujan
Copy link
Member

tsujan commented Jan 17, 2017

Seems like we're all busy and don't have so much time for LXQt

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 ;)

@agaida agaida added this to Done in Pull Requests Mar 30, 2018
@agaida agaida added this to Old in PRs Nov 5, 2018
@agaida agaida added this to Old Archive in Pull Requests Mar 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
PRs
  
Changelog
Pull Requests
  
Old Archive (fucked up)
Development

Successfully merging this pull request may close these issues.

None yet

2 participants