internal viewer - scroll position after the window is refreshed

TXS - Help
2013-09-22
2014-08-09
  • Eduardo Werley

    Eduardo Werley - 2013-09-22

    Hi guys.
    I've got a small question about the scrolling behavior of the embedded viewer.
    I'm using TeXstudio 2.6.2 (SVN 4110), on Ubuntu 12.04 -64bits.

    Is there a way to force the embedded viewer to remain in a fixed scroll position, after a file is rebuilt?
    The problem is that whenever a file is rebuilt, the internal viewer is refreshed, but the scrooll jumps to a different position than the previous.

    I'm starting on TXS, and found it spectacular, comparing to TexMaker.
    But in Texmaker, when a file is modified and the embbed viewer is called again, the window viewer remains at the previous position.

    Thanks in advance.

     
  • Tim Hoffmann

    Tim Hoffmann - 2013-09-22

    Currently, the viewer is always jumps to the cursor position after rebuilding. Usually this is what you want to look at.

    So far, there is now way to alter this behavior. We could change this in the future. But I have to point out that 'same position' is a bit tricky because you have two different PDFs before and after recompilation. In general, there is no way to map positions between these two documents. Remaining on the same page number would be possible, and without looking at it I presume this is what Texmaker is doing. Is remaining on the same page number (and relative position on that page) what you were looking for?

     
  • Eduardo Werley

    Eduardo Werley - 2013-09-22

    Yes,Tim, that is exactly the point.

    Imagine the following situation. You start to work in a tex file, by writing a new paragraph. Then you build the first time, and the internal viewer is then opened, with the scroll at the top. No problem, you adjust the scroll to focus on the paragraph you've just written. Then, suppose you edit the same paragraph again, just adding a few words at the end. I would expect that, when the file is rebuild, the viewer remains focusing on the same paragraph (or maybe in the same relative position). The viewer scroll position should only be altered if the content I'm editing falls outside the viewer window.

    That's another point to consider. I think the viewer behaviour is also inconsistent when the option "scrolling follow cursor" is active. Wouldn't be better if the relative position of the current paragraph in focus on editor could be mapped exactly to the viewer? I mean, if a page has 5 paragraphs on the pdf, and If paragraph 3 is almost at the top of the editor, shouldn't the pdf be scrolled accordingly?
    I observed that, in some cases, the current text being edited is mapped to the very bottom of the viewer.

    Anyway, thanks for your prompt response.
    Cheers

     
    • Tim Hoffmann

      Tim Hoffmann - 2013-09-24

      Then you build the first time, and the internal viewer is then opened, with the scroll at the top.

      Use Build & View instead of Build. Then the viewer opens directly at the cursor position.

      That's another point to consider. I think the viewer behaviour is also inconsistent when the option "scrolling follow cursor" is active. Wouldn't be better if the relative position of the current paragraph in focus on editor could be mapped exactly to the viewer? I mean, if a page has 5 paragraphs on the pdf, and If paragraph 3 is almost at the top of the editor, shouldn't the pdf be scrolled accordingly?
      I observed that, in some cases, the current text being edited is mapped to the very bottom of the viewer.

      In general, exact mapping is not possible. A paragraph may extend over a (multi-)page or column break. Currently there is no guarantee of the fine-positioning. It's only ensured that the text is visible. You may file a feature request at https://sourceforge.net/p/texstudio/feature-requests/, but, personally, I don't consider this a high priority.

       
  • Eduardo Werley

    Eduardo Werley - 2013-09-24

    Any chances to add advanced options for viewer scroll controling?

     
  • Tim Hoffmann

    Tim Hoffmann - 2013-09-24

    Still not sure, what options would really be useful. Your example above can basically be solved by Build & View. As for the rigid 'stay on page', is it really necessary when Build & View is available? Also, we currently don't have a logic for 'reopen'. There is no memory in the viewer on past states. We'd have to make significant changes to the viewer. So far I don't see much benefit compared to the work required.

     
    • Eduardo Werley

      Eduardo Werley - 2013-09-24

      The option Build & View in fact opens the file and highlights the current cursor position, which is fantastic. My concern is why the page has to be, additionally, scrolled up to a fixed position every time the file is rebuilt? Couldn't it remain in the previous relative position (in the cases where the cursor position, or the current paragraph, has not being altered)?

      I've filled a feature request about it.
      Thanks for your attention.

       
  • Tim Hoffmann

    Tim Hoffmann - 2013-09-29

    or post the patch here (attachment).

     
  • Eduardo Werley

    Eduardo Werley - 2013-11-22

    Sorry for the late reply. I was very busy with my thesis.

    The patch is attached.

    Desired effects: When the user rebuilds a file (by Build & View), the logic tests if the viewer needs to be scrolled based on the current page being edited. The viewer is only scrolled if a page falls outside the viewer limits.

    Cheers.

     
    Last edit: Eduardo Werley 2013-11-24
  • Eduardo Werley

    Eduardo Werley - 2013-11-22

    PS: Patch is for TXS 2.6.6

     
    • ugh_bough

      ugh_bough - 2013-11-27

      Hi, i downloaded 2.6.6., applied the patch and compiled. For me there is no difference to the original behavior :(

      If that makes a difference, i've tried when zoomed in close and when pages are visible from left to right border completely.
      TXS still jumps either to beginning or end of page.

       
      • Eduardo Werley

        Eduardo Werley - 2013-11-30

        HI, I'll check it again.
        Regards.

         
  • Tim Hoffmann

    Tim Hoffmann - 2013-11-24

    Thanks for the patch. Will look into it soon.

     
  • Tim Hoffmann

    Tim Hoffmann - 2014-08-09

    fixed by hg 4653 (6e555222431e).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks