Implement native scrolling on iOS (PR #25827)
RobertRoeb
- Supports SetTargetWindow() used by e.g. wxDataViewCtrl
- Need to enforce single pixel steps because that is what finger scrolling does
- Draws before window is visible (I assume for off-screen drawing into buffer)
- Added localDeviceOrigin like in GTK+, since the native scroll window moves windows up and this needs to be corrected in wxWidgets when e.g. reporting mouse event coordintes, update region and child window positions
- Supports native scrolling physics beyond limits, then bounces back (like standard on iOS)
- Enforce single pixel steps in wxHtmlWindow
- Supports wxDataViewCtrl with no changes in its code
You can view, comment on, or merge this pull request online at:
https://github.com/wxWidgets/wxWidgets/pull/25827
Commit Summary
- 6f31e4c Implement native scrolling on iOS
File Changes
(8 files)
- M include/wx/osx/core/private.h (10)
- M include/wx/osx/iphone/private.h (15)
- M include/wx/osx/window.h (9)
- M src/generic/scrlwing.cpp (21)
- M src/html/htmlwin.cpp (7)
- M src/osx/carbon/dcclient.cpp (10)
- M src/osx/iphone/window.mm (140)
- M src/osx/window_osx.cpp (46)
Patch Links:
- https://github.com/wxWidgets/wxWidgets/pull/25827.patch
- https://github.com/wxWidgets/wxWidgets/pull/25827.diff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@vadz commented on this pull request.
Unfortunately I'm not competent enough to review this, @csomor could you please look at this?
FWIW I'm a bit horrified by the hacks in common code, I would hope we could somehow hide this in wxOSX implementation instead of requiring #ifdefs in any code using scrolling rate (IIUC).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)I'm a bit horrified by the hacks in common code
These "hacks" are there to enforce that when scrolling with fingers, there are only single pixel scroll steps and this is done when setting the scrollbars. Nobody's finger uses steps of 20pixels.
There is one other #ifdef referríng to scroll physics. The current code block scrolling outside of the requested range, but on iOS, the standard is to allow overscrolling and then to bounce back. The code does this perfectly.
Unfortunately, there is one case needed to support SetTargetWindow(). I don't think it is possible get this away, but I will look at this again.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25827)These "hacks" are there to enforce that when scrolling with fingers, there are only single pixel scroll steps and this is done when setting the scrollbars. Nobody's finger uses steps of 20pixels.
If you say so — this doesn't seem at all obvious to me because I definitely never want to scroll in steps of 1px, whichever scrolling method is used. But I mostly would hope that we could add some GetEffectiveScrollRate() or whatever function and use it without having to write #ifdefs.
There is one other #ifdef referríng to scroll physics. The current code block scrolling outside of the requested range, but on iOS, the standard is to allow overscrolling and then to bounce back.
Again, I would hope this could be something wxScrolled could take into account internally...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)Again, I would hope this could be something
wxScrolledcould take into account internally...
It would be easy to add a wxScrolled::AllowScrollingBeyondRange( bool allow= true );
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25827)Again, I would hope this could be something
wxScrolledcould take into account internally...It would be easy to add a wxScrolled::AllowScrollingBeyondRange( bool allow= true );
Why couldn't it be built-in? I.e. allow under iOS (and Android...) but not elsewhere?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)this doesn't seem at all obvious to me
I tried a different approach first: keep the scroll steps at e.g. 10px and allow finger scrolling
with 1x. The problem is that the wxScrollWinEvent will report the new position in steps to the
window and that determines how much PrepareDC() changes drawing. So your finger would
slowly move pixel by pixel over the screen, but drawing would jump by 10px. Even worse, the
native scrolling widget will first scroll slowly, and then the drawing code will make it jump back.
because I definitely never want to scroll in steps of 1px
I believe that on your phone, you always do and always want to scroll in steps of 1px. I mean,
1px precision. You surely expect the content on screen to move with your finger, don't you?
BTW, the same applies to finger scrolling on touch screens of laptops. I am not quite sure
how we handle that, actually. If the mouse wheel is used, I understand it is expected to
scroll by a step (of e.g. 10px) for each mouse wheel movement. But does wxWidgets react
to finger scrolling at all? So basically the wxPanGestureEvent. In my opinion, wxScrolled
should react to wxPanGestureEvent by default - but it currently does not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)Again, I would hope this could be something
wxScrolledcould take into account internally...
It would be easy to add a wxScrolled::AllowScrollingBeyondRange( bool allow= true );
Why couldn't it be built-in? I.e. allow under iOS (and Android...) but not elsewhere?
Now I am confused. This scroll physics is default on iOS, but not Android. that is why I put
it into #ifdef OSXIPHONE so it is built-in in my PR. However, that is what you asked
to change initially. Let me know which way is preferred.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25827)You wrote:
There is one other #ifdef referríng to scroll physics.
I'd like to avoid having ifdefs by just handling this in wxiOS itself.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)But does wxWidgets react to finger scrolling at all? So basically the wxPanGestureEvent
New idea: on iOS, UIScrollView captures the gesture events and then translates that into a
new (scroll) position (actually in both x and y directions at once). So maybe we need a
wxEVT_SCROLLWIN_PAN event with GetPixelX() and GetPixelY() (and GetPosX() and
GetPosY() which would be the pixels positions divided by the scroll steps). On iOS, the
code would generate that directly, on other platforms, we might choose to catch the
wxPanGestureEvent and translate that into wxEVT_SCROLLWIN_PAN in a second step.
In wxScrollHelperBase::HandleOnScroll(wxScrollWinEvent& event) we could process the
wxEVT_SCROLLWIN_PAN and translate that into a two-directional scroll event with single
pixel precision and we adapt OnPrepareDC() as well as CalcScrolledPosition() and
CalcUnscrolledPosition() to add the small single-pixel offset. I have no computer with
a touch screen - maybe I can simulate wxPanGestureEvent somehow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
@RobertRoeb pushed 1 commit.
- b112a81 Added wxScrollWinPanEvent
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
RobertRoeb
RobertRoeb left a comment (wxWidgets/wxWidgets#25827)This seems to work. I added a new wxScrollWinPanEvent that is handled by wxScrolled. Based on that, it should be simple to add wxPanGestureEvent support to wxScrolled and there are almost no #ifdefs anymore. I will document if approved.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.