single menu checkbox action enlarges or normalizes (shrinks) embedded pdf-viewer

[octaeder]

This PR addresses following two mutually exclusive menu actions:

As you can see, my personal settings use two shortcuts for enlarging and shrinking the embedded viewer added in the Shortcut config:

But this has the disadvantages that you waste one shortcut and your hand needs to switch between two positions on the keybord for toggling the size of the viewer. If we agree that the pdf-viewer has a normal size which can be enlarged (maximized to the left), a checkbox should be enough to do the job:

As long as there is no embedded pdf-viewer the action is not enabled. So txs needs to know if there is an embedded viewer. This brings me to the next point.

The PR also fixes small issues. Under specific conditions enabling and disabling the action(s) or switching between enlarged and normal size of the viewer works not correctly. The reason for this is the not so well known fact that it is possible creating first a windowed pdf-viewer and then the embedded one. This means that there are two viewers. To do so one needs some changes to the Build Meta and User Commands. In this case an internal PDFDocument list holds two pdf-viewer items. But the code may fail if it relies on the assumption that the embedded viewer (if available) is the first one in the list. It is necessary to search through the list.

[sunderme]

I don't see the checkbox as beneficial.
It would be beneficial if you can directly jump form no viewer to enlarge/small viewer.

[octaeder]

What you describe is basically already possible. After closing the enlarged viewer it will reopen enlarged/shrinked as it was before (for ex. by pressing F7). I think this is ok. I want to see the embedded viewer all the time. So I need to toggle quite often. In this context you argued that the user can learn the shortcuts easier if both can be seen in the menu. With this solution you need to learn only one shortcut (and you have one left for other things). To be honest, using two menu actions for one toggle function is a design flaw, isn't it? If I had been aware of this last time, I would have changed it then. Indeed, this PR is not as beneficial as introducing texpresso, but it has the benefits described. I'm sorry that I'm dicussing again.

[sunderme]

you are talking minor cosmetics again.

[octaeder]

The small issues mentioned at the end of the description of this PR will now be implemented in #3994

[sunderme]

okay, we can close this ?