Package Details: qpdfview-bzr 2017-1

Git Clone URL: https://aur.archlinux.org/qpdfview-bzr.git (read-only)
Package Base: qpdfview-bzr
Description: A tabbed PDF viewer using the poppler library. (development version)
Upstream URL: https://launchpad.net/qpdfview
Licenses: GPL2
Conflicts: qpdfview
Submitter: adamreichold
Maintainer: adamreichold
Last Packager: adamreichold
Votes: 6
Popularity: 0.000117
First Submitted: 2012-02-07 20:39
Last Updated: 2016-11-02 11:36

Dependencies (12)

Required by (0)

Sources (1)

Latest Comments

adamreichold commented on 2016-11-03 12:18

@sleeping Please do not flag VCS packages as out-of-date due to an upstream update as makepkg will always fetch the latest trunk revision and update the package version during build.

adamreichold commented on 2016-11-02 11:24

@pmattern I do agree about the hooks and will update both packages as soon as I find the time to do so. (Of course, patches welcome in any case.)

Concerning the debug symbols, I concur with @lahwaacz that this should be enabled by each user as necessary. Of course, I would be happy to find a back trace of these recurring crashes in the project's bug tracker on Launchpad.

lahwaacz commented on 2016-10-29 09:50

Enabling debugging symbols in packages is the user's responsibility, just like fetching the latest version of VCS packages whenever necessary. Both tasks are actually equally easy, see https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces

In any case, it doesn't make sense to enforce these as defaults in the "upstream" PKGBUILD just because you're having some problems...

pmattern commented on 2016-10-29 09:24

It would make sense to replace the install script with pacman hooks. You'd just have to drop the script and add gtk-update-icon-cache as runtime dependency. This would allow for ditching dependency hicolor-icon-theme which would be pulled by gtk-update-icon-cache.
Same goes for package qpdfview.

Also, I wonder whether it wouldn't make sense to enable debugging.
Right now both stack traces and backtrace tend to be useless one-liners when qpdfview crashes and dumps core. This is a pitty when it comes to chasing down crashes which happen sporadically but cannot be reproduced easily (like one involving opening several PDF files in parallel by clicking links in Firefox I'm seeing since a while here).
Given that one main purpose of VCS packages is testing debug symbols should actually always be enabled in these packages, IMHO, as the advantages outweigh disadvantages like higher resource usage or performance penalty in this case.

b52 commented on 2016-10-23 13:49

@adamreichold The screenshot was taken while tiling was disabled. If I however enable tiling in combination with device pixels, I get an even weirder output as shown in https://paste.xinu.at/z105oj/.

Note that the quality of the rendered output is very bad without the device pixels option.

adamreichold commented on 2016-10-21 05:13

@b52 The screenshot looks like only the first tile composing the page is rendered (or if the others are rendered they are at least not displayed). Could you please check if things work correctly if tiling is disabled via the Graphics tab of the Settings dialog? If so, please file a bug on Launchpad that tiling and non-unit device pixel ratios are incompatible. Thanks!

b52 commented on 2016-10-19 20:59

Using the "device pixel option" results in weird behavior on my laptopt, as can be seen in this screenshot https://paste.xinu.at/pE1B/
Note, that it's a high dpi display.

adamreichold commented on 2016-05-06 12:31

@gothmog123 The problem is that the Fitz plug-in is broken in the current trunk revision since the outline and properties interface was changed without the Fitz plug-in being adjusted yet. Also the package dependencies are probably wrong since the headers and libraries seem to have moved to the libmupdf package. Not sure when I will find the time to fix this, patches welcome in any case...

gothmog123 commented on 2016-05-06 03:24

mupdf version doesn't compile - anyone know anything?

adamreichold commented on 2015-03-22 00:26

Hello again,

the problem with the tab navigation in the properties dock should be fixed in the latest trunk revision.

Making all docks visible definitely has no effect on the issue, but it can tell you whether your main window is using tabbed docks and has a tab bar child holding the focus even though it may be invisible. At least this is what I can reproduce during debugging: The focus being on the invisible tab bar child of the main window used by tabbed docks. In any case, the problem remains that Qt's QMainWindow controls that widget instead of qpdfview itself...

Best regards, Adam.

All comments