Bug 425181

Summary: Modal error popup by livepreview / Okular
Product: [Applications] kile Reporter: Albert Zeyer <albzey>
Component: user interfaceAssignee: Michel Ludwig <michel.ludwig>
Status: REPORTED ---    
Severity: normal    
Priority: NOR    
Version First Reported In: master   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Bug Depends on:    
Bug Blocks: 342772    
Attachments: Patch that hopefully reduces the number of times the loading error dialog is shown

Description Albert Zeyer 2020-08-10 09:40:45 UTC
SUMMARY


Background: Nothing special, except maybe that my Latex project (Phd thesis) is quite big, and consists of several tex files.
Demo: https://github.com/albertz/big-latex-demo

Often during a background recompilation for the LivePreview, while browsing through the code at the same time (and e.g. switching the tab to another tex file, belonging to the same master document), I get a error in a modal message box:

"Could not open file:/...pdf"

Note that the error itself might be valid, and there might be another problem causing this. Although I think that LivePreview maybe just tries to display the PDF too soon, and has not correctly waited until the compilation finished. Or so. But this is not what this bug report is about.

Here I just want to address the issue that there is a modal message box at all. This is really annoying when you are currently typing in some text, and then you get these messages just in the middle of typing.

It would be ok if the message appears in the warning log somewhere.

From the backtrace, I see that this comes from Okular:

#9  0x00007ffff69d2ad5 in KMessageBox::error(QWidget*, QString const&, QString const&, QFlags<KMessageBox::Option>) ()
   from /lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#10 0x00007fffed11efd7 in Okular::Part::openUrl(QUrl const&, bool) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/okularpart.so
#11 0x00007ffff7dea3b5 in KileTool::LivePreviewManager::ensureDocumentIsOpenInViewer (this=0x5555564cdb70, previewInformation=0x555557878d10,
    hadToOpen=0x0) at /home/az/Programmierung/kile/src/livepreview.cpp:712
#12 0x00007ffff7deabc5 in KileTool::LivePreviewManager::synchronizeViewWithCursor (this=0x5555564cdb70, textInfo=0x555555680280,
    view=0x5555570a33f0, newPosition=..., calledFromCursorPositionChange=false) at /home/az/Programmierung/kile/src/livepreview.cpp:761
#13 0x00007ffff7deb993 in KileTool::LivePreviewManager::showPreviewCompileIfNecessary (this=0x5555564cdb70, latexInfo=0x555555680280,
    view=0x5555570a33f0) at /home/az/Programmierung/kile/src/livepreview.cpp:885
#14 0x00007ffff7ded052 in KileTool::LivePreviewManager::handleTextViewActivated (this=0x5555564cdb70, view=0x5555570a33f0, clearPreview=true,
    forceCompilation=false) at /home/az/Programmierung/kile/src/livepreview.cpp:1115

Full backtrace and screenshot here: https://gist.github.com/albertz/186703aacfca83d4b5a0c7b738442f57

Maybe the best way would be to tell Okular to not display such global modal messages, and instead report them somewhere else. But I guess this is not so simple.

So probably the next best way is to try our best in Kile to not let this happen. I.e. double check that the file is valid before we open it in Kile.

I'm not really familiar with the code at all, so far.
I guess mostly relevant is livepreview.cpp.

I thought that one way to fix this is just to ignore the preview update if the compilation is still in progress.
So I tried to patch showPreviewCompileIfNecessary like this:

--- a/src/livepreview.cpp
+++ b/src/livepreview.cpp
@@ -881,6 +881,8 @@ void LivePreviewManager::showPreviewCompileIfNecessary(KileDocument::LaTeXInfo *
         }
         else {
             KILE_DEBUG_MAIN << "hashes match";
+            if(m_runningPreviewInformation == previewInformation) // currently running compilation
+                return;
             showPreviewSuccessful();
             synchronizeViewWithCursor(latexInfo, view, view->cursorPosition());
             emit(livePreviewSuccessful());

This seems to get rid of the error in many cases (but not all cases). I assume this is not quite correct, and probably also not the best way to do it.


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Ubuntu 20.04
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Michel Ludwig 2020-08-30 12:29:44 UTC
Created attachment 131285 [details]
Patch that hopefully reduces the number of times the loading error dialog is shown

Could you try out the attached patch?