Loading

Paste #pkgysfluo

  1. <Company> so
  2. <Company> whenever any widget changes position or size
  3. <Company> we need to fake a motion event
  4. <Company> does that seem about right?
  5. <Company> or a widget is added or removed - but i think that causes a resize
  6. <garnacho> sounds about right, crossing events due to hierarchy changes are also a possibility
  7. <garnacho> those cases usually have deviceid==sourceid in x11, and gtk went along with it
  8. <garnacho> (as in, not originated from a hw device)
  9. <Company> i thought fake motion event, because that will take care of everything
  10. <Company> the one tricky thing is how well we need to track if we need to fake a motion event - after all, widget-factory would potentially generate one every frame, but the only thing moving is the pulsing progressbar
  11. <garnacho> right
  12. <garnacho> I guess that should just be strictly needed if some widget in the chain actually got a different allocation
  13. <Company> that was my initial thought, but that's wrong
  14. <Company> because a different widget might move on top of the hovered widget
  15. <garnacho> true
  16. <Company> and also, the hovered widget might move (or be moved due to a parent moving), so it might need a motion event, even though the hovered widget itself didn't change
  17. <Company> and what makes this worst is that pick() doesn't tell us the coordinate inside the widget that we picked
  18. <Company> so we can't compare if the coordinate actually changed
  19. <garnacho> I think gtk_pointer_focus_repick_target() should already take care of that, it keeps toplevel coords around. A super generic check might be "any widget that changed allocation happens to contain that point"
  20. <garnacho> hmm, or does it
  21. <garnacho> right, not enough
  22. <Company> do we have an issue about that problem?
  23. <garnacho> I don't think we do
  24. <Company> i'll file one