← Back to team overview

qpdfview team mailing list archive

Re: About the buttons (part 2)

 

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

Ok, I did notice that one can disable those little spin box buttons,
so now the current page widget in the edit tool bar should really have
its minimum horizontal size. (While still not being able to rotate...)

On 12.07.2012 07:37, Adam Reichold wrote:
> Hello,
> 
> On 11.07.2012 22:56, Pascual Lucero wrote:
> 
>> Hello again, sorry ...
> 
> No need to be sorry. Discussing and hopefully fixing problems is
> what this mailing list is about, isn't it?
> 
>> With respect to my previous message on the buttons, I just
>> checked more carefully the source and I realize there are some
>> extra buttons, so this answered when I talked about adding extra 
>> buttons:
> 
>> The latest image of a PDF file using qpdfview and more buttons:
> 
>> http://imageshack.us/photo/my-images/843/201207111540061366x768s.png/
>
>> 
> 
> 
>> (Certainly, buttons like "refresh" are not relevant in a web 
>> browser).
> 
>> - Button missing:  Search!!!  That is an important one. It is 
>> missing in qpdfview and in a browser it could be important,
>> because the command Ctrl+F is the same as search in the web
>> browser.  On the other hand, using mozplugger, search using
>> qpdfview (after going to the main menu) doesn't work ... the text
>> field for entering the search doesn't work and when I try to
>> write, it starts writing in the address bar.
> 
> That was forgotten. We already had it in 0.3.1 and it forgot to add
> it to the list of available tool bar actions. Trivially fixed.
> 
> Search not working is probably still the same keyboard focus issue 
> that plagues Qt within mozplugger. This will only be resolved by
> doing a dedicated plug-in that applies the
> QApplication::setActiveWindow hack.
> 
> (BTW, it isn't a problem if the browser and a plug-in have common 
> keyboard shortcuts as if the plug-in has the keyboard focus, e.g.
> by clicking on it, all keyboard shortcuts will work as expected. It
> is really a bug in the interplay of Qt and mozplugger that prevents
> any keyboard events from reaching a Qt application running inside a
> browser.)
> 
>> - Button that I want to remove (in the screenshot): Scale
>> Factor. With only zoomIn, zoomOut and the fit to Page, etc ... it
>> is enough. In a browser you don't enter too specific zoom
>> numbers. If I remove it, the toolbars finally look with the
>> appropiate width.
> 
>> (See the following screenshot: 
>> http://imageshack.us/photo/my-images/809/201207111550451366x768s.png/
>>
>> 
)
> 
>> Why I didn't remove it in the first image. Because there is a
>> bug in qpdfview with respect to removing "scaleFactor" from the
>> view Bar. Do you see carefully the image in the top left corner?
>> (just above the "thumbnails"). It generates some space like
>> trying to put a button in that sector of the page. This also
>> happens opening the program directly without the browser.
> 
> That's definitely a bug and one that is probably present in
> versions 0.3 and 0.3.1 as well. Should be fixed in trunk revision
> 417.
> 
> Best regards, Adam.
> 
>> That's it, enough report for today. Thanks a lot for your 
>> attention.
> 
> 
> 
> 
> 
> 
> 
> 

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

iQEcBAEBAgAGBQJP/swaAAoJEPSSjE3STU34IMgIAL1nG66K0q0IrRE/eLuxS4QJ
3Y0vHiX2O5LyDlqvDiFiQ3QDkVE3XD5prUJNhnyAx/u3bJLDLluvgMfyuH7MGHi1
eYvc1sHWNA1MMemN/R41JwTKvvCu0vdTd1KsOZKsruXEyRS7xHAKqx8nenXfl3Do
6oOMEdZohcamiuubmTukr4hRUhvuuX69C8yMbL3+EkxIiJSC0NpE21lysQzm1pqK
b3YN9fG6HPJbT8M5OlE+m6IwL80sIFh/63r6E9QKMOLaMJEmnbPXvZkB0oZmyC16
A9E+S12R4ILfXoYKIGeZec+gy9+JIGX5nSKSacwKjLkWgFdohS66AXVntWpZpOw=
=Heop
-----END PGP SIGNATURE-----


References