4b48ee6...
by
Tor Lillqvist <email address hidden>
tdf#128468: Tweak the ruler tick and tab stop positions to be just right
Gosh that was painful. But now they seem to be correct.
Some other clarifications and improvements. Also start trying to
handle touch device dragging in the tab stop area, but that handler
doesn't get invoked yet, and anyway any code to actually move the
nearest tab stop is missing.
Change-Id: I187bca84da70f03f5dcf032b997e43b5e54d7879
Reviewed-on: https://gerrit.libreoffice.org/84574
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
5e6976f...
by
Tor Lillqvist <email address hidden>
tdf#128468: Draw the tab stops
Draw only the user-edited/able ones. Draw all four kinds (left, right,
center, and decimal) the same for now, as a small triangle pointing
up. (Drawn using a CSS trick to get a triangle.) The tab stop
positions aren't actually editable yet, nor is there a way to add a
new tab stop or delete one. Later.
The code uses a CSS custom property, yay, to avoid duplication of a
magic value for the half-width of the triangle.
Change-Id: I862b09091bad03ad63425cc6e6759f3f13174579
Reviewed-on: https://gerrit.libreoffice.org/84474
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
da9ca77...
by
Tor Lillqvist <email address hidden>
tdf#128468: Get rid of a bunch of pointless variables
No reason to make the code even harder to understand by using
variables that don't vary but hold a constant value. Especially when
the variable names don't match their constant value.
4e42bae...
by
Tor Lillqvist <email address hidden>
tdf#128468: Make the margin handles in the ruler work better in the iOS app
There is too much state that isn't necessarily in sync. Get rid of
some of the coupling.
Instead of turning on the catching of touchstart events in the
_changeInteractions function, which does not work if you tap the
make-editable button before the document has been loaded completely,
start catching them right away after creation, but in the handler, the
_initiateDrag function, ignore the event if the "map" is not yet
marked as editable.
Change-Id: Ief7a98e9b6ffa4db9d41f558d1081687032c4bcc
Reviewed-on: https://gerrit.libreoffice.org/84235
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
36a6c6f...
by
Tor Lillqvist <email address hidden>
Add (commented-out) debug message
Change-Id: I718899a7071093a63898c73bfc42144140e6fba3
Reviewed-on: https://gerrit.libreoffice.org/84234
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
67793ef...
by
Tor Lillqvist <email address hidden>
Improve ruler behaviour when panning by dragging on a touch device
Fire the 'scrolloffset' event also in
L.Control.Scroll._onUpdateScrollOffset(), which gets called when
panning a text document on a touch device.
There are still glitches in updating the ruler when one uses a pinch
gesture to zoom the document. But usually after a short moment the
ruler snaps into correct state.
Change-Id: Ic8dd5139ff49f6fe7961096552f1c7e6cf35356c
Reviewed-on: https://gerrit.libreoffice.org/83996
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
caf37fb...
by
Tor Lillqvist <email address hidden>
Make dragging the margin handles in the ruler work better in the iOS app
Several changes:
On iOS, use touch events instead of mouse ones. One difference between
touch and mouse events is that the touchend event naturally does not
carry any position information (as the finger has been lifted from the
screen). So we need to keep track of where the last touchmove event
happened separately in _lastPosition.
Letting go of a margin handle after dragging it did not actually move
the coresponding margin in the document. The fix for this was to catch
the touchend event for the this._rFace element instead of for the
this._map element.
Once a margin had been moved, it could not be moved another time. The
reason for this was that because the document initially is readonly,
the this.options.interactive was set to false (see the
L.control.ruler() call in loleaflet/src/map/Map.js) and never changed
after that. This caused _updateBreakPoints() to pass {perm:'readonly'}
in the call to this._changeInteractions(). The fix was to set
this.options.interactive to true when turning on the interaction.
In theory this same problem probably would happen also in web-based
Online on "mobile" (i.e. phones), but we don't show the ruler there at
all, so the sitaution where a document would be initially read-only
and the ruler would show up doesn't happen.
Change-Id: I0393704d02a2989b4ea3358dc4bee17e48c16ae6
Reviewed-on: https://gerrit.libreoffice.org/83807
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
8f14c41...
by
Tor Lillqvist <email address hidden>
Avoid the ugly gap between the toolbar and ruler in the iOS app
This is one of those "try different changes until you come up with
something that seems to have the desired effect" type of commits. If
somebody actually understands what is going on and knows the right way
to fix the problem, feel free.
0868d19...
by
Tor Lillqvist <email address hidden>
Make the ruler show up in the iOS app on iPad
Sadly there is a gap between the toolbar and the ruler on iPad (but
not when running web-based Online from the same sources). Need to
figure out what is going on there.
b60ccd6...
by
Tor Lillqvist <email address hidden>
tdf#125755: Fix some URI encoding issues
Now the iOS app is able to open a document called A#B?C\D&E❤️F🇨🇭G%AAHÖ.doc.
That is, with ‘#’, ‘?’, and ‘&’ that can mess things up when parsing URIs,
non-ASCII and even non-BMP characters, and an actual percent
character in the file name. Is that a complete enough test case? Will see.
Change-Id: I7fc53eaf8188f633d442d14a7f42814553169c71
Reviewed-on: https://gerrit.libreoffice.org/83395
Reviewed-by: Tor Lillqvist <email address hidden>
Tested-by: Tor Lillqvist <email address hidden>
