Through listeners click/tap we get a FrameClickEvent with the coordinates x and y within the frame window.
This is used internally to define tap/click zones:
const oneQuarter = ((this._cframes.length === 2 ? this._cframes[0]!.window.innerWidth + this._cframes[1]!.window.innerWidth : this._cframes[0]!.window.innerWidth) * window.devicePixelRatio) / 4;
// open UI if middle screen is clicked/tapped
if (edata.x >= oneQuarter && edata.x <= oneQuarter * 3) this.listeners.miscPointer(1);
if (edata.x < oneQuarter) this.goLeft(false, () => { }); // Go left if left quarter clicked
else if (edata.x > oneQuarter * 3) this.goRight(false, () => { }); // Go right if right quarter clicked
So it properly maps the event data coordinated to the frame window, which will become impossible to do for external consumers of the app as we privatise _cframes. I tried for a couple of hours as I was migrating peripherals anyway, and currently we do not have enough exposed to reimplement something like this in a trivial and quick manner.
This is a seemingly simple fix: make click/tap zones configurable and call it a day.
I’d argue this would not resolve the root issue though: we do not have anything to resolve these coordinates in the actual spreader.
And It is already an issue in our own internal logic to be fair, as a single page on the left/right will have its tap zones relative to its own window, but pages in a spread are relative to the sum of the two frame windows, which is kinda weird if we think about it – tap on the left for the first page is a middle tap in spreads for instance, and the tap zone on the right is half the one of spreads as well. Of course that also leads to the rabbit hole of click/tap happening in a virtual “blank” page in the spreader…
So we are missing something. I am not sure what right now, but it is makes things more difficult than it should be.
On a related note we are also hitting an issue with targetFrameSrc and resolving it against the readingOrder.items, as host apps are not supposed to call the FramePoolManager to get the Map. Maybe there is something to do here as well because I added a ready-to-use Locator to BasicTextSelection in #209 for this same exact reason. This would at least allow checking which reading order item it is in the viewport.
Through
listenersclick/tap we get aFrameClickEventwith the coordinatesxandywithin the frame window.This is used internally to define tap/click zones:
So it properly maps the event data coordinated to the frame window, which will become impossible to do for external consumers of the app as we privatise
_cframes. I tried for a couple of hours as I was migrating peripherals anyway, and currently we do not have enough exposed to reimplement something like this in a trivial and quick manner.This is a seemingly simple fix: make click/tap zones configurable and call it a day.
I’d argue this would not resolve the root issue though: we do not have anything to resolve these coordinates in the actual spreader.
And It is already an issue in our own internal logic to be fair, as a single page on the left/right will have its tap zones relative to its own window, but pages in a spread are relative to the sum of the two frame windows, which is kinda weird if we think about it – tap on the left for the first page is a middle tap in spreads for instance, and the tap zone on the right is half the one of spreads as well. Of course that also leads to the rabbit hole of click/tap happening in a virtual “blank” page in the spreader…
So we are missing something. I am not sure what right now, but it is makes things more difficult than it should be.
On a related note we are also hitting an issue with
targetFrameSrcand resolving it against thereadingOrder.items, as host apps are not supposed to call theFramePoolManagerto get theMap. Maybe there is something to do here as well because I added a ready-to-useLocatortoBasicTextSelectionin #209 for this same exact reason. This would at least allow checking which reading order item it is in theviewport.