qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello,

On 11.07.2012 21:29, Pascual Lucero wrote:
> 
> 
> Thanks a lot for your answers! I will start to test the
> qtbrowserplugin :)
> 
> 1) Before doing that, during the night I realize some things about
> the problematic vertical toolbars (which might help, at least
> temporarily):
> 
> - The "Current page" button has the problem that includes the box
> with the page, but also outside is indicated the total number of
> pages (something like "1" of 7) and when put this vertically it
> creates a problem. I tried in the settings file to eliminate the
> "numberofPages" and still behaves bad, because the current page
> button alone is not centered.

Sadly, tool bars do not do any fancy layout like centering themselves.

> Perhaps, instead of "1" of 7, it could be something like "1"/7
> without spaces to make the button much smaller. Clearly, these
> toolbars are better vertically given that qpdfview allows this
> possibility.

Try out trunk revision 416, I replaced the "currentPage" and
"numberOfPages" widget by one "currentPage" spin box with a suffix,
i.e. the page will be displayed as "1/N". The rest of the
functionality of that control should be the same. (Well, one could now
even do without the prev/next page buttons but they are still a bigger
click target.)

(I suppose Andi will be happy about this as well since he advocated
that solution for a while. :-))

> - The View toolbar looks bad vertically basically because it is
> too wide. Why? Because the form for "Scale Factor" includes as
> parameters "Page width" and "Page Size". My experience using tons
> of PDF viewers says thar these two parameters are actually not
> necessary. For example, what SumatraPDF makes (they also
> deliberated about making the toolbars smaller) and also Google
> Chrome is to include buttons for these actions (Fit to Page, Fit to
> width, Continuous) and these solves the problem, because now the
> scale factor only includes numbers, hence with would be smaller.
> Perhaps these buttons individually already exist, but I didn't 
> found them.

These two options in the scale factor combo box are necessary since
there is no well-defined scale factor in the fit-to-x modes as the
scale factor is different for different pages (if their size is not
uniform). But there are buttons for those actions. Listed in the (yet
incomplete) online help: fitToPageWidth, fitToPageSize,
continuousMode, twoPagesMode.

So I would say that if one really wants to use vertical tool bars, he
should disable the scale factor combo box and just use those buttons
instead. (Without a report on the scale factor, but hey, we don't
report the rotation either.)

> In other words, I don't think it is necessary right now (thinking
> in your time) to implement yet a fancy solution for the vertical
> toolbars, just to make the problematic buttons smaller and centered
> and include a few new buttons for basic actions (and these buttons
> could be included vertically in the default look in the browser
> plugin).
> 
> 2) I agree that the best way to change the .conf file is simply
> have just one and include parameters for the browser plugin.
> 
> 3) I was experimenting with mozplugger and I realize something 
> interesting and I don't know if this situations happens in your
> idea: Initially, I had included the following in the mozpluggerrc
> file:
> 
> repeat noisy needs_xembed swallow(qpdfview) fill: qpdfview "$file"
> 
> And I realized that if I use different tabs with opened PDF files,
> it would open a new instance of qpdfview, hence consuming more
> memory. So, I thought: What happens if I change this to:
> 
> repeat noisy needs_xembed swallow(qpdfview) fill: qpdfview
> --unique "$file"
> 
> I realize something awesome happened: Everytime I opened a new pdf
> file in a new browser tab, it would just create a new tab in
> qpdfview (only showed in the browser tab where the first PDF file
> was opened). Perhaps this is not the way some users want, but
> actually in my case I really like it!! And it consumes less memory,
> because it does not create a new instance of the program. So I
> thought that maybe this could be let as an option to the user (a
> box to check if they want "unique" more or not) ... so the user, if
> he/she wants, could take advantage of the fact we have a tabbed PDF
> viewer.  Of course, in case of using tabs, the default could be
> with the tabs showed vertically (because of what we commented 
> before that in browsers, horizontal space is available and we try
> to save as much vertical space as possible).

It's funny but I don't think that a browser plug-in is supposed to
behave like that. :-) I think browser plug-ins are supposed to embed
into the displayed pages with a minimum of chrome for their own
interface. (If you really want a separate interface, just let your
browser open PDF files using "qpdfview --unique" which will give you
exactly the same results as it will just open a temporary file in a
new tab.)

> 4) You mentioned at the beginning that the fact open with a PDF
> plugin saves files in a temporary folder and described it as "not
> elegant" but simple, actually this is the normal setting, because
> usually the reason lots of people use a pdf plugin is because they
> want to see the file before downloading it.

Well, if you saved it in a temporary file, you obviously have
downloaded it beforehand. Maybe not somewhere specific but into that
temporary file. So again, I don't see the difference to just letting
your browser open PDF files by default.

Best regards, Adam.

> 
> These are my current settings in qpdfview used with mozplugger, it
> could give you also more ideas ... look at the second image with
> tabs.
> 
> Image 1: 
> http://imageshack.us/photo/my-images/18/201207111423161366x768s.png/
>
>  Image 2: 
> http://imageshack.us/photo/my-images/225/201207111423401366x768s.png/
>
> 
> 
> Thanks again for your attention. !!!!
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

iQEcBAEBAgAGBQJP/ed+AAoJEPSSjE3STU34Ku4IAIaNXHWM7RwA+VqviFYYI0CT
ivBXPrL8Wycggd6OCFyU3Yp6KdzulPQhxGwtcdKszHXa1D2NSdnsulrGWfHWl/bj
l3WsVqV5PQSHZaoyEicKm823gfGUPsidKMU21wsfArRxRAN9Semq355rVgyz3jlh
IdIc6lPsohQB/GcpNXv+i2p2NJb43UtggS0LF4rpHteg8qoaIUFLFIOHzQyIFen3
QuSksT2YzhatXCfQoswxWtM+JUIQE/KsmjZfv12mcsrrwF6xrVLduEctE4+YAYuU
DlHLnxLzMBs78i5wkXOlPaceT3OARQkTH/S4ncIAFBYH7GOwMs71Az7/O/HMcLQ=
=0wAQ
-----END PGP SIGNATURE-----