qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Pascual,

I'll try to discuss both your messages, so here we go:

On 11.07.2012 06:45, Pascual Lucero wrote:
> 
> Sorry, I would like to mention just another thing: As the guys
> from Google Chrome have realized in their internal plugin, the only
> keyboard shorcuts and buttons that are very important to exist and
> work are: Move Page (Previous, Next), The Zoom buttons and the
> "Save as" command. Of course, in the plugin of qpdfview as it
> looks, even more things could be possible (for example, we could
> open a local file as a new tab in the same browser window!!, given
> that qpdfview allows tabs), which is really nice!

I think, making keyboard shortcuts accessible shouldn't be a problem.
I actually did not plan on making tabs available in the plug-in as it
is supposed to blend into the browser's interface more or less. And it
should only operate on the file that is actually embedded in the HTML
file as it is just an interface to display a document not a separate
program. (And a tabbed PDF inside a tabbed browser seems a bit over
the top.)

So in summary, my plan would be to design a separate plug-in-specific
user interface that is basically distinct from the qpdfview main window.

> In my pictures, if the problems with the toolbars in vertical mode
> are solved (how they look), if all these buttons are enabled in the
> default .conf in the plugin, then the problem is solved in a 50%
> (we see easily buttons to perform these basic actions). The only
> thing missing is to make sure the keyboard shortcuts for these
> basic functions will work.

Yes, the problem with vertical tool bars and those widgets is
well-known and I think that there is no easy solution. (I searched
around a bit and rotating general Qt widgets does not seem to be a
simple maneuver.) So maybe one should think about how to solve this
differently or utilize third party components like those from the Qxt
project.

> Thanks for your attention ... :)
> 
> (If this can be done, I will post qpdfview propaganda in the sites
> I use to visit, hehe ... could you imagine? A tabbed lightweight
> PDF viewer in Linux that includes its own PDF plugin that works
> correctly in all main browsers in Linux -Chrome/Chromium, Firefox
> and Opera-) !!!
> 
> 
> 
> On Tue, Jul 10, 2012 at 11:08 PM, Pascual Lucero
> <pascualucero@xxxxxxxxx <mailto:pascualucero@xxxxxxxxx>> wrote:
> 
> 
> Hello,
> 
> 
> As I am not a programmer :(  (I would like to learn someday), 
> unfortunately I cannot contribute writing code; however I am
> trying to do my best as a tester and making some suggestions.
> 
> 1) I would like to ask first how to test the qtbrowserplugin ...
> it is the first time I heard about this concept, so my knowledge
> is almost null. Where should I put the qtbrowserplugin folder? Does
> it need a different compilation? It is possible to include it in
> the tar.gz and the .deb package of qpdfview (in other words, build
> the plugin at the same time as the program?)

QtBrowserPlugin is a software component that implements Netscape's
plug-in API, i.e. NPAPI, and exposes that functionality in a
Qt-specific way. It is used then by the programmer to implement a
plug-in using Qt functionality. So if you fetch the code from
"lp:~adamreichold/qpdfview/plugin" it already includes a copy of the
(BSD-licensed) QtBrowserPlugin component and you don't really need to
care.

What you do need to set up is a copy of the current source code from
trunk, i.e. "lp:qpdfview", set "TRUNK_PATH" in "qpdfview-plugin.pri"
in the plugin source directory to point to the trunk source directory.
Then you build it as usual with qmake and make which should generate a
"libqpdfview-plugin.so" which is the plug-in that can be copied or
linked in e.g. "~/.mozilla/plugins".

I am not sure how to ship this if it achieves a usable state.
Currently, the built library "libqpdfview-plugin.so" is completely
self-contained (if poppler and Qt are installed obviously) which seems
favourable to me.

> 2) I have tried to test mozplugger in different browsers and with 
> different programs (from gv, to evince, to okular, to qpdfview and 
> xpdf) and these are my conclusions that might improve a pdf
> plugin:
> 
> - First, a great problem in all cases is related to keyboard 
> shortcuts. Specially change pages is problematic. Of course, in 
> Mozilla things work better than other browsers; in Opera, keyboard 
> shortcuts don't work.

With the plug-in from "lp:~adamreichold/qpdfview/plugin" this should
work correctly. At least it does for me. Of course, only after
clicking inside the plug-in so it gets the keyboard focus.

> - Second, a small problem is that in order to open the files, in 
> Evince and Qpdfview, the way the program look when embedded in the 
> browser depends on the user settings for the respective programs. 
> However, this shouldn't be the right way. Why? Because in
> browsers, usually windows are maximized, so vertical space is
> important (and then usually, the default way to view the PDF is the
> "Fit to Page" way; on the other hand, horizontal space is
> available, so by default, bookmarks, thumbnails and toolbars can be
> set to the left, and be visible without problem. And using the
> settings to save as much vertical space as possible.

Yes, the plug-in interface's settings should be distinct from the main
window settings and definitely will be. It is just the internal
settings of the document view component (caching, spacing,
decorations, etc.) that should be picked up from the main
configuration file.

> In other words, the right way to configure it could be to set a 
> separate .conf file for the plugin, different from the .conf file 
> for the default program (other settings for memory could be set 
> differently also; in other words, it is highly convenient to 
> separate both).

It also think the best way is to use the same configuration file and
have an extra "plugIn" section in addition to the "mainWindow" and
"documentView" sections. I.e. interface specific-settings are distinct.

> Look at the following screenshots, showing an idea on how a PDF 
> could look like using a browser plugin:
> 
> Image 1: 
> http://imageshack.us/photo/my-images/860/201207102250311366x768s.png/
>
>  Image 2: 
> http://imageshack.us/photo/my-images/4/201207102251041366x768s.png/
>
>  Of course, the ideal would be the first image, but with the 
> toolbars' width corrected as in image 2. This also shows a problem 
> with qpdfview: The edit and view toolbars are not correctly set
> for vertical use.

Well, as I said. One will have to employ some clever trick for a
useful vertical tool bar for the plug-in or employ third-party
components that properly support rotation of widgets.

> That's all. Hopefully my comments could be useful as an
> improvement of the program and the plugin (as mentioned in the last
> paragraph, improving a plugin could actually help to improve how
> the program and the toolbars looks).
> 
> And I will be grateful for indications on how to use the plugin,
> or better if this could be integrated into the development builds
> like other PDF programs (which include the plugins in the install
> package).

Well, currently I would stay at shipping it separately as long its
quality is pre-pre-alpha. But you can alreay test it (without any
interface whatsoever :-\) and maybe this helps doing so:

1. you are in some folder to screw around...

2. fetch the trunk and plugin source code:
# bzr branch lp:qpdfview trunk
# bzr branch lp:~adamreichold/qpdfview/plugin plugin

3. now you should edit "./plugin/qpdfview-plugin.pri" to correctly set
the "TRUNK_PATH" variable, but by default it is "../trunk" which
should be correct in this case

4. build the plug-in (having Qt and poppler development files
installed on the system):
# cd plugin
# qmake
# make

5. link the plugin so firefox finds it after restart (of course,
adjust the plug-in directory, so your browser actually finds it):
# ln -s ~/.mozilla/plugins/libqpdfview-plugin.so libqpdfview-plugin.so

6. restart your browser and test the plug-in on an embedded PDF file

7. find someone with the spare time to implement a simple and
space-preserving interface on top of the document view component... ;-)

Best regards, Adam.

> 
> Thanks for your attention. Have a good night!
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP/bDeAAoJEPSSjE3STU346p0H/0th5smzCWVrVLU790Wv4wi4
PBjT9OTbMZMBwciHxJ2WVkF76JR1Hs05H9bK419wUEKEdU41bsfuoujg0CbGm5RI
S5j0SKWEM/8k8XKJ3vdHrRNiuZiCj/lqqCgFXkjiZv7UK8e0ZJd4zAfiOSQsQDxf
Ih43ePR/bp4uEz0xHm5QTRNa9fbByhhe7l5DXUjBafpzh6o2MYJNDlhxUOHGwqrQ
a71jMgHFPJDAvwSvRxzIi3hejKB58EOVeDW8vhY4eWC9oNNtD9lk8pdXgRBVMyA+
fNBZdcuHDrH6yxoU5ZbJVa/vs7N+ud47A11sI0Dh56s4kcMHpsAld+zaaroRQB4=
=gY06
-----END PGP SIGNATURE-----