Features to save vertical space (tab management and shortcuts)

Hello Pascual,

Nice to hear that you like most of the program. Concerning the points you raised:

ad 1: Current trunk has a setting called 'tab bar as needed' which will hide the tab bar if there are less than two tabs. Because this hides the close button, it is disabled by default. Also AFAIK there is nothing to prevent you from using multiple instances of qpdfview. The only thing this will conflict with is the 'restore tabs' functionality which will be applied to all instances.

ad 2: I actually forgot about those. They are available in trunk now. (Using F6 to F7.)

ad 3: In trunk, there is a new entry called 'jump to page' which can also be reached by pressing 'Ctrl+J'. This will open a simple dialog where you enter the desired page.

ad 4: This is intended behaviour as whether a dock is displayed or not is handled as a property of the window not the document.

Best regards, Adam.

P.S.: I don't how you run the program, but to test this (which would be very much appreciated) you should use the dailydeb PPA on Ubuntu, the development version from AUR on Arch or compile the current revision from trunk yourself. (A helpful user also posted an ebuild to create a package from trunk for Gentoo on the mailing list.) There will probably also be a 0.3beta3 release for wider testing of these additions.

Hello,

Thanks for the answers.

With respect to (1), I don't know if you can choose between "allowing multiple instances" and "opening new file in a new time"; it would be more consistent. For example, if qpdfview is my default PDF viewer, in the file manager I double click and the file is opened. So, if I choose some sort of "allowing multiple instances" option, I know there are no tabs and each file opens individually. If the "allowing multiple instances" is not enabled, I know beforehand that the file would open in a new tab if there are more files opened. Right know, if you want, for example to use tabs all the time, you can only open from the file menu in the program; otherwise it would create a new instance of the program. And certainly, open from the file manager once you see the files is easier than open them with the file menu.

With respect to (2) and (3), thanks!!!! That is really important

With respect to (4), it would be nice still if the properties option is located in the "File" menu, easier to access, like most programs. Right now, it looks too cumbersome that in order to see the metadata, you have go to to "View -> Dock (which is in the inferior part of that menu) -> Meta-information", for something you should be able to see right away.

With respect to the way I run the program, I installed it from the Ubuntu PPA:

sudo apt-add-repository ppa:adamreichold/qpdfview-dailydeb
sudo apt-get update
sudo apt-get install qpdfview

But currently, the available version in that PPA is 0.3beta1. I don't know how to install the latest version, in case this is not the latest. Any help here is appreciated.

Best regards,

Pascual

First, concerning the build you run: If you employ the dailydeb repository, then you should always (with a little time lag) run the latest version from trunk. (Even though this is not recommended for general usage.) The version displayed in the about dialog is just not updated automatically. What counts is the build number in the version of the Debian package. So you should get those changes through the usual updates rather soon.

ad 4: The choice for a dock instead of a dialog comes again from the tabs. This way you can compare the meta-information of several open tabs more easily. As for accessing that dock faster: You can always use the keyboard shortcut F7 or the context menu of the main window, i.e. right-click somewhere empty in the toolbar. Putting access to that dock somewhere else like the file menu seems rather confusing to me.

ad 1: I think you can already have that functionality if you want to by using the '--unique' command-line option documented to a degree in the online help and extensively in the manual page (run 'man qpdfview' in a terminal). So if you instruct your file manager to open PDF files with 'qpdfview --unique' instead of 'qpdfview', all documents should open in a single window as tabs.

If you are unsure how to achieve this: One possibility which should work for several desktop environments: Copy '/usr/share/applications/qpdfview.desktop' to '~/.local/share/applications/qpdfview.desktop' and change the line 'Exec=qpdfview %f' to 'Exec=qpdfview --unique %f'.

By the way, you can check the status of the daily builds at "https://code.launchpad.net/~adamreichold/+recipe/qpdfview-dailydeb".

Hello!

Thanks for you answer, I still think the --unique option is something that could as a choice in the settings; or at least, it is easier to configure for most users (in my case, I have no problems editing qpdfview.desktop, as I got used to do this in other programs). However, these are some options that you shouldn't be forced to read the help just to realize they exist :)

On the other hand, in todays update in the PPA, the interface elements we have discussed here on tabs and shortcuts are added and I can see them in the program. Now I can say officially that this is my default PDF viewer, it has everything an more that epdfview has, with better design and rendering. An it looks better than evince already. I hope we can see this viewer in the main repository of Ubuntu and other linux distros in the near future (and of course, it looks like there could be a Windows version in the future) :) :)

On the other hand, these are some new observations about the program:

- I really like how you can see, for example, the outline bar and the thumbnails bar at the same time, looks beautiful and the "North, West, etc" to see the where the tab bar is going to be located is fantastic.

- BUT: I think that you shouldn't need to double click in a thumbnail (in the thumbnals bar) to see the new page; usually pdf programs like adobe only requires to click once, it looks faster to change pages that way. In my case, I thought it was not working because I am used (like most users) to click just once and it was not changing the page, until I realize I needed to double-click.

- I don't know if this is the expected behavior, but, lets suppose you open a file and see the thumbnails bar and you close the program. Of course, the setting of viewing the thumbnails bar is remembered for the next opened files, which is perfect. But if you open the program, without opening any files yet, there should not be "thumbnails bar" as it currently happens; it should only appear when there are opened files.

- I think currently in the toolbars, the items in categories "File, View, Edit" are not quite correct yet. I conjecture that you are going to add more options to those menus, so you keep the three categories, knowing that there are more options coming. Because changing page, for example, doesn't look like something that belongs to a "Edit" category.

- I have observed that the program always loads very fast, but on the other hand, it consumes more RAM than Evince, for example. Is this due to the use of qt4 libraries? Or there are still some things that can be optimized in this aspect independent of the use of qt?

Thanks, thanks a lot!

The point of using a command-line option instead of a setting is the added flexibility as you can have both behaviour at the same time. The assumption that users read documentation might be flawed, but is made nevertheless to allow for that flexibility.

The question of single-clicking or double-clicking on thumbnails was discussed on the mailing list: It is not possible to combine single-clicking and drag-to-pan. Since double-clicking allows for both interactions, it was chosen that way even though it is a bit more cumbersome.

Again the visibility of the docks (outline, meta-information, thumbnails) is a property of the window and not of the document. So it is not really 'remembered for the next file' but rather it is completely independent of whether there actually is a tab present or not. So in summary: This is intended behaviour.

Concerning the distribution of functionality: It have no great plans to add a lot of menu entries. What is displayed in the tool bars can be configured as described in the online help. Where to put each function is somewhat arbitrary anyway, but "Edit" currently reads like "Navigate", i.e. editing what, i.e. which page, is displayed in contrast to "View" determining how it is displayed. Of course this is somewhat fuzzy, but I do not see a pressing need to change it.

I can not tell you what exactly determines whether evince or qpdfview use more memory but this is a tricky questions that depends on a lot of variables. However, a large portion of the memory usage of qpdfview is determined by the page cache, i.e. pre-rendered images of the pages which a stored in memory for later (re)usage. How large the page cache for each tab is allowed to grow can be configured in the settings. You can try decreasing this if you feel qpdfview consumes too much memory.

I think the same remark on using the mailing list for ongoing discussions applies here as well.

By the way, there is a Windows version: You just need to compile the program on Windows. It runs fine but I do not plan to distribute Windows binaries if that is what you mean. Maybe if there is someone who is willing to maintain the Windows binaries like Benjamin Eltzner who currently maintains the Debian packages. (Which AFAIK just landed in unstable.)

If you are interested in building qpdfview on Windows, I could post an howto to the mailing list.

Initial question has been answered, further discussion of proposed features can take place on the mailing list.