If not, open did not succeed and the callers (for example open document
X in page A) would like to know so they don't have to do the "change to
part A" part.
BUGS: 429924
Previously if it was a remote url that had # and a . after the # we
assumed the url had no fragment and everything was filename.
We don't do that anymore, what we do now is try to open the url as
parsed, i.e. before the # is the filename after is the fragment, and if
that fails we try to open everything as filename and nothing as
fragment.
Unfortunately given how kpart internals handle opening local vs remote
urls we need to do this in two places.
Also we have to remove the test that checked that the url was mangled at
the shell level because we don't do that anymore. Unfortunately can't
add a test for the new codepage since it would involve starting an http
server ^_^
Filenames:
source2e.pdf
foo#bar.pdf
What works:
* okular http://localhost/source2e.pdf#subsection.68.3
* okular file:///srv/http/source2e.pdf#subsection.68.3
* okular source2e.pdf#subsection.68.3 (in the /srv/http folder)
* okular source2e.pdf#2
* okular http://localhost/foo#bar.pdf
* okular file:///srv/http/foo#bar.pdf
* okular foo#bar.pdf (in the /srv/http folder)
What doesn't work:
* okular http://localhost/foo#bar.pdf#2
I think it's a fair limitation that if you want to open a file that contains # in the name and also use a # page marker you need to use the encoded url like okular http://localhost/foo%23bar.pdf#2
after all things like firefox will totally fail opening http://localhost/foo#bar.pdf and will just work if you give the encoded url
BUGS: 426976
In fba90677fc we introduced a "if we're
told this is a text file let's check the mime of the content only since
text files never fail to open".
This extends it to anything that inherits from text now, so if you
rename a PDF file to bla.php it still tries to open as a pdf first and
if that files as a php file
QScrollerPrivate::setDpiFromWidget() before Qt 5.14 crashes
when the target widget does not intersect a physical screen,
because QDesktopWidget returns screen index `-1` in this case,
which leads to an out-of-range read from QApplication::screens(),
which leads to a segfault when reading from an invalid QScreen* pointer.
This adds a workaround that checks for the `-1` situation,
and then tries to resize PageView temporarily to intersect at least some screen.
BUG: 425188
FIXED-IN: 20.12
When making a flick using the mouse or the touchscreen and then slowly
dragging the pages in the same direction with the flick, it unintentionally
reenters the flicking state after a mouse button release and it's quite
annoying. The commit reduces the maximum time before the next flick.
Steps to reproduce:
1) Flick in direction A.
2) While the view is coasting, decide that you want to stop close to the current position.
3) Grab the view (still coasting), and drag it slowly in direction A.
4) When you reached the desired point, stop your movement, and release the view.
5) QScroller interprets this release as “accelerating flick”,
and makes the view coast faster in direction A.
Upstream bug is QTBUG-88249; QScroller ignores MinimumVelocity for accelerating flicks.
Source files are no longer separated by UI and non-UI and similar,
but only by their build target.
* ui/ -> part/
* Move all source files from conf/ to part/
* Keep config skeleton definitions in conf/, needed for the mobile target too
* Move editdrawingtooldialogtest.h from conf/autotests/ to autotests/
* ui/data/icons/ -> icons/
* Move /part.cpp, /part.rc and similar files to part/
* Adapt include paths in source files
* Adapt CMakeLists.txt files (in / and in subdirectories)
* Adapt /Messages.sh
A lot of this code has been commented out for over
a decade and adds no value to the project.
It is only annoying when you look over it ;).
Same for the KNS2 support which was commented out.
Also some of the debug statements didn't even build
anymore, because the properties got removed/refactored.
f9841b0f8a and e0f45add55
They break the windows build, which shows there's something defenitely
fishy going on with the current code, but oh well, someone with more
time needs to figure out a proper solution
It was causing problems (Windows build fails) now that we enabled -Wweak-vtables (and
probably before didn't work that much before, guessing that's why we had that if (doc)
in openFile)
This is the simplest solution, invokeMethod is not great but we already
use it, so it's not too terrible
The openDocument function was unused so remove it.
The other two solutions are:
* Make KDocumentViewer be part of okularcore and then link the
okularcore to the okular binary, not nice
* Make another dynamic library that just contains the KDocumentViewer
class, but i'd rather not add yet another library we have to install
and take care of
Read https://stackoverflow.com/a/23749273/11956287 for a full
explanation, but basically this is important for headers like the
interfaces/ and kdocumentviewer.h that are supposed to be used by third
partyies where it may happen that wrong things happen because the whole
class is inline in a header
For the classes that are defined in the .cpp or are not installed
headers this would not be necessary but it's not so hard to add a few
default defined destructors, so do that :)
The condition was incorrect; we were ignoring history when not in the
middle of scrolling when we wanted to do the reverse.
BUG: 414701
FIXED-IN: 20.12
apt-get uses several fsync() calls on each package it installs, and that's
very slow, especially on non-SSD. eatmydata turns fsync into no-op, which
makes package installation much faster (it can cause corruption if there's
power loss or similar, but that doesn't matter in CI where we throw away
the whole container anyway).
Currently the build_ubuntu_20_04 job in GitLab CI takes 8-9 minutes to
install dependencies. Using eatmydata it went down to 2 minutes.
And by that it means giving the focus to the pageview which is most of
the fimes what we want. One could argue that if i had the focus on the
searchbar we should restore the focus there, but that makes not much
sense to me, since each tab is it's own world, at most one could say,
let's remember where the focus was in that tab the last time it was
focused and restore it there, but it seems a bit convoluted.
To be able of setting the focus to the pageview from the shell we need
to set up some focus proxies, so that part->widget (which is the sidebar)
ends up giving the focus to the pageview, which is what makes sense if
someone says "you part, set yourself the focus"
BUGS: 428257