Menu

#112 main.flip_page() issue

SVN
closed-fixed
nobody
None
5
2018-10-08
2018-09-30
John E
No

Hello,

for a while I've had this issue with stable mcomix and finally investigated it on latest master.

My problem is that sometimes scrolling at the end of an archive opens another directory instead of the following archive.

The reason for that is simple: I scrolled a bit too much at the end and it called main.flip_page() multiple times.
The first call to main.flip_page() will set self.filehandler.file_loaded to None for a bit during filehandler.open_file()'s execution.
If filehandler.open_file() is still running, the following calls to main.flip_page() will see self.filehandler.file_loaded as None, call main.next_book() that will also see self.filehandler.file_loaded as None, which will call filehandler.open_next_directory().
Simply returning on "if not self.filehandler.fileloaded:" in main.flip_page() does the trick for me, but I assume that's not the correct approach for you.
Probably refusing to do something in main.flip_page() if filehandler.open_file() is running would be the correct solution. You already have file_opened() to show that, but it sets self.filehandler.file_loaded which has another meaning...

Unrelated, but I believe in filehandler you call _close() too much, as most calls precede open_file() that will call _close() anyway

Thank you!

Discussion

  • Ark

    Ark - 2018-10-01

    I think I am already aware of this issue because I often ran into something obscure like this myself. Thus, thank you very much for your help, I might have a closer look into your suggested bugfix later.

     
  • John E

    John E - 2018-10-02

    You're very welcome!

    I think in some cases this issue could also lead to opening a much further archive instead of a directory, the behavior is the same but I'm guessing by the time it calls main.next_book() self.filehandler.file_loaded has been set. I haven't investigated this since it happened only when I was debugging the previous issue, so I could be wrong.

    Also, related to the issue mentioned, but not a big deal at all:

    if the new archive is loaded, but the images are not yet shown properly, probably because mcomix is scaling them or something, the scrolling step when the mouse is on top of the images part seems to be the same as if the mouse was on top of the thumbnails part.
    Hence it is easy to get much further into the Archive than expected when I scrolled WAY too much to go to the next archive and not stopped when it was loaded.
    This is easy to remedy, I just need to not scroll like a mad man :)
    In theory if my archives were only a few images big, I suppose this could lead to skipping archives.
    I have not investigated this one, nor do I have a good idea on what to do. Stepping fast is useful if one does want to start on a much further image in the archive, but that's already feasible with the thumbnails so maybe not...

    Thank you!

     
  • Ark

    Ark - 2018-10-07

    Sorry to keep you waiting.

    The fix you proposed works as expected, and it also seems to be the best solution. Included in [30700bf58198379b334a7446773489687e30e939]. Thank you very much. I do not quite understand your last paragraph, though, but I think everything involving the reading position (not only viewport position but also directory walking etc.) needs a complete overhaul anyway.

     

    Related

    Commit: [30700b]

  • Ark

    Ark - 2018-10-07
    • status: open --> closed-fixed
     
  • John E

    John E - 2018-10-08

    I meant that if I mouse scroll a lot on the last page of an archive, and most likely still during the initial load of the next archive, maybe for half a sec not sure, I would end up in my new archive say page 25 instead of page 1. But if I had scrolled the same amount when the archive was fully loaded, I probably would be page 3 or so as moving from one page to another needs a few scrolls not just one. So it seems scrolling during loading does not use the same step as scrolling when loading is done.

    Again it's not a big deal, I just scrolled a lot during debugging of the issue as I had to move to the next archvie a lot to trigger the bug and then investigate it.

    I'm glad the fix worked out for you easily and thank you for looking into it!

     

Log in to post a comment.