I would like to add that the same thing happens when a watched file is refreshed.
This is extremely annoying when Okular is used to view a PDF that is being regularly updated by a tool like pdflatex.
The user must reclick on the thumbnails tab every time a change is made!

@thekswenson that's a different bug, i'm not convinced the state of the side panel has to be remembered when opening/closing okular, but reloading is defenitely a bug, please open a different bug so it can be tracked separately

the state of the side panel should be saved on a per document basis.  when i re-open a PDF it comes back on the same page and the same line that i closed it at.  why shouldn't the panel be in the same state too (and at the same thumbnail, etc., that it was left at)?

i'll open a new bug anyway.

I'd be especially interested in the sidebar retaining its "no panel open" state across okular restarts.

I can second the request to retaining the "no panel open" state across okular restarts. This is probably the most annoying bug in KDE I am struggling with every day!

Just to note, this seems like a duplicate of: https://bugs.kde.org/show_bug.cgi?id=335189

Also in this bug the feature was requested, but prematurely dismissed by Albert Astals Cid due to bug reporting formalities:
https://bugs.kde.org/show_bug.cgi?id=355530

I am simply astonished something like this hasn't been implemented years ago. It can't be difficult: Okular can remember whether the navigation panel was open or not in the last session, and Okular can remember the position and even zoom of a specific document. Now it has to be a simple step to add "ShowLeftPanel=false" or "ShowLeftPanel=true" to the xml files in /home/user/.local/share/okular/docdata
In those files there already is something like:
  <views>
   <view name="PageView">
    <zoom value="1.25" mode="0"/>
   </view>
  </views>"
While in /home/user/.config/okularpartrc I find:
 [Main View]
 ShowLeftPanel=false
(when the navigation panel is open, however, there isn't "ShowLeftPanel=true", but just nothing, maybe this should change)
Why not add this to the individual document files? I tried to change an xml file myself, but that didn't work.
The next step (I suppose more difficult) is to remember which of the panels (thumbnails or contents) was opened.
All this is standard behavior in Adobe Acrobat Reader DC on Windows 7, do you think Adobe is getting lots of angry emails about this? It's also standard behavior on the new WPS pdf reader.

Just to make clear my personal user case: I generally read pdf text files (or djvu or epub, thank you very much for adding these file types to Okular), so the thumbnails panel is mostly useless for me. The contents panel is very handy however, but not every pdf has contents, and sometimes these 'contents' are IMG_0001, IMG_0002, etc. In those cases I don't need a navigation panel at all. So Okular remembering for each file if the panel was open or not is very useful to me.

I really like okular and I want to get involved in KDE so this looks like a great starting point :)

I'm not really sure this is a junior job.

I haven't downloaded the code yet, but checking:

https://github.com/KDE/okular/blob/1dc81340bcfecf054f27c17279cb241316a7c16c/core/document.cpp

it seems to me that the code that handles per-document properties is not the right place to handle app UI properties, I guess this was by design.

I also dunno exactly what are the rendering steps once a document is opened in okular: I would guess that first the app UI is rendered, with or without left panel depending on the "global" settings persisted in:

~/.config/okularpartrc

And only once the "frame" is in place, document rendering takes place, according to its specific view settings (persisted on a document basis).

So IMO to achieve what's requested by the logger, this process should be reviewed, either by delaying rendering of part of the app UI, or by drawing it with some defaults/global state, and then re-draw the left panel according to per-document settings, if any are stored (which could cause some re-rendering glitches, I guess?)

Also, I dunno whether left panel properties (on/off and tab id) could be stored in the per-document XML file within a <view name=LeftPanel> element, for example.

Is there an XSD defining the structure of documentInfo?

<documentInfo url="/home/andrea/Documents/Casa/Diagnostiques/2043 (DIAG ELEC).pdf">
 <generalInfo>
  <history>
   <oldPage viewport="0;C2:0.499767:0.209379:1"/>
   <current viewport="3;C2:0.499803:0.545531:1"/>
  </history>
  <views>
   <view name="PageView">
    <zoom mode="1" value="2.47816"/>
    <continuous mode="1"/>
    <viewMode mode="0"/>
    <trimMargins value="0"/>
   </view>
  </views>
 </generalInfo>
</documentInfo>

(In reply to andrea.ippo from comment #9)
> I'm not really sure this is a junior job.
> 
> I haven't downloaded the code yet, but checking:
> 
> https://github.com/KDE/okular/blob/1dc81340bcfecf054f27c17279cb241316a7c16c/
> core/document.cpp
> 
> it seems to me that the code that handles per-document properties is not the
> right place to handle app UI properties, I guess this was by design.
> 
> I also dunno exactly what are the rendering steps once a document is opened
> in okular: I would guess that first the app UI is rendered, with or without
> left panel depending on the "global" settings persisted in:
> 
> ~/.config/okularpartrc
> 
> And only once the "frame" is in place, document rendering takes place,
> according to its specific view settings (persisted on a document basis).
> 
> So IMO to achieve what's requested by the logger, this process should be
> reviewed, either by delaying rendering of part of the app UI, or by drawing
> it with some defaults/global state, and then re-draw the left panel
> according to per-document settings, if any are stored (which could cause
> some re-rendering glitches, I guess?)
> 
> Also, I dunno whether left panel properties (on/off and tab id) could be
> stored in the per-document XML file within a <view name=LeftPanel> element,
> for example.
> 
> Is there an XSD defining the structure of documentInfo?
> 
> <documentInfo url="/home/andrea/Documents/Casa/Diagnostiques/2043 (DIAG
> ELEC).pdf">
>  <generalInfo>
>   <history>
>    <oldPage viewport="0;C2:0.499767:0.209379:1"/>
>    <current viewport="3;C2:0.499803:0.545531:1"/>
>   </history>
>   <views>
>    <view name="PageView">
>     <zoom mode="1" value="2.47816"/>
>     <continuous mode="1"/>
>     <viewMode mode="0"/>
>     <trimMargins value="0"/>
>    </view>
>   </views>
>  </generalInfo>
> </documentInfo>

I think you didn't understand what the user wants at all, they only want that if the last time they were open a document it was on thumbnails, open again in thumbnails not in contents, there's no need for changing anything render related *at all*.

The only question is if would do this globally or per file, but that only means the setting is change in one place or the other.

It's been a while, but I've got something working. I've done it globally but I'm not sure it's very useful... Per file may makes more sense. What do you think?

Yes, probably per file makes more sense.

If that could be implemented that would be so useful!!