Matchstic / Xen-HTML

Unified and simplified HTML rendering
GNU General Public License v2.0
110 stars 15 forks source link

Homescreen background widgets not responsive #284

Closed spmdgit closed 4 years ago

spmdgit commented 4 years ago

Describe the bug HS Widgets in Background are notably less responsive than when the same widgets are placed in the Foreground. Toggle for "Allow Touch on Background" is switched on.

To Reproduce Steps to reproduce the behavior:

  1. Enable toggle for Allow Touch on Background
  2. Place interactive widget on HS in BG (e.g. MusicWidgetForAll or AeroCalendar)
  3. Attempt to interact (scrolling, pressing buttons, etc) with said widget
  4. Compare responsiveness to the same widget placed on the HS in the FG

Expected behavior I would expect the same level of interactivity and responsiveness whether widget is placed in BG or FG, but scrolling is inconsistent and sometimes results in triggering spotlight search rather than scrolling the widget. Button presses take many attempts if they register at all. FG performance is essentially flawless. Due to this disparity in responsiveness, I can't use BG widgets which would be present on each page of springboard and resort to placing widgets in FG only on first page of SB.

Screenshots If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

Additional context I use the above mentioned widgets but any interactive widgets would presumably have the same issue. If trying this out with AeroCalendar, will still need to use XenInfo as new api as of this writing (2.0~beta3.1) does not yet support calendar events unless I am mistaken.

Matchstic commented 4 years ago

Unfortunately, I cannot do anything here to improve the situation.

To allow touch on background, I do some pretty crazy hacks to forward touches below icons. This by nature cannot handle cases where eg the user accidentally opens spotlight.

As a result, widgets that rely purely on tap gestures etc see zero difference in responsiveness, but swipe-based gestures do not work well.

On 9 Jun 2020, at 13:53, spmdgit notifications@github.com wrote:

 Describe the bug HS Widgets in Background are notably less responsive than when the same widgets are placed in the Foreground. Toggle for "Allow Touch on Background" is switched on.

To Reproduce Steps to reproduce the behavior:

Enable toggle for Allow Touch on Background Place interactive widget on HS in BG (e.g. MusicWidgetForAll or AeroCalendar) Attempt to interact (scrolling, pressing buttons, etc) with said widget Compare responsiveness to the same widget placed on the HS in the FG Expected behavior I would expect the same level of interactivity and responsiveness whether widget is placed in BG or FG, but scrolling is inconsistent and sometimes results in triggering spotlight search rather than scrolling the widget. Button presses take many attempts if they register at all. FG performance is essentially flawless. Due to this disparity in responsiveness, I can't use BG widgets which would be present on each page of springboard and resort to placing widgets in FG only on first page of SB.

Screenshots If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

Device: iPhone 6+ OS: iOS 12.4.2 Xen version 2.0~beta3.1 Additional context I use the above mentioned widgets but any interactive widgets would presumably have the same issue. If trying this out with AeroCalendar, will still need to use XenInfo as new api as of this writing (2.0~beta3.1) does not yet support calendar events unless I am mistaken.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

spmdgit commented 4 years ago

Thank you for the explanation and the hard work you've put into the tweak. Makes sense about the issue with swiping widgets, but I still experience issues with tap-based BG widgets as well (e.g. MusicWidgetForAll). They are noticeably less responsive than their FG counterparts.