when you execute commands from terminal, it is out of KDE's control nor okular
But it is the shell's matter
depending on the shell you use, you should be able to log recently executed commands.  e.g  for Bash shell there is "history" command and ~/.bash_history 

I dont think we could do much about this, could we?

A central file for recently accessed files? it is simple and possible to sync across instances

Nelson, this has nothing to do with the shell, nor does it take into account the fact that most of the time Okular is launched by other applications (such as via the file manager).

David, as far as I can tell, "recent documents" is not synced across instances in other applications either, for example kate. This might just be a KDE limitation. Furthermore, your proposal glosses over the issues that would have to be handled when syncing a "recent files" file across instances, such as locking it for updates.

The long and short of it is that it is not a big deal to sync across instances, file locking, syncing etc etc are all computing issues long since solved to death.  

I think it would be a nice feature and, given the way I work opening up and closing okular many times during the day, having many different "recent" file lists is annoying.

To suggest it can't be done for technical reasons is silly. The question here is there enough support for the idea to warrant the effort.

I did not say "it can't be done", merely that getting the "syncing, locking, etc." *right* is more work than you so breezily imply. If you don't believe me, have a look at code say, pine, employs to lock mailbox files and handle all the corner cases that come out of it. I'd say having an older version of "recent files" list in some of your running instances is less annoying than having a corrupted list.

@David: With "the question here is there enough support for the idea to warrant the effort." are you saying that you want to work on a patch for this?

I don't think pine is a good example here.  The filelocking in pine is complex but this is because of several reasons: pine stem from a time when system file locking was not standardised, pine had to deal with many different systems and files systems (some of which did not support file locking), pine has to operate with many different non cooperative programs who would access the files and pine had to deal with critical data, loss of which was unacceptable.

The situation here is rather different on all of these counts and a very simple file locking system would be just fine. The history is written to a config file on exit (presumably this has a lock mechanism to avoid race conditions?).  This is reread on starting.  Just reread this once in a while (and update it once in a while).

OK, pine is an example of how far you need to go to have as bullet-proof a solution as possible. An overkill for Okular, I agree, and you can make it less robust for the sake of simplicity. There are Qt classes that let you do (advisory) file locking, but you better get it right, because as I said, the current behaviour is way better than ending up with a corrupt config file.

Even if the current instance of okular doesn't sync with the recent documents it would be nice if new instances knew the recent documents and not just "the last ones from the last instance of okular that closed even if it had been running for weeks and was well out of date".

The file locking issue is a big red herring.  Just keep a separate config file and append the file name each time the file is opened then reread it occasionally or when file:open:recent is called.

It seems that pretty much anything other than okular manages to make "recent" mean recent rather than "arbitrary and possibly well out of date"

It doesn't seem to pick up recent documents even from kile? (Then again, neither does kile...)

*** Bug 195645 has been marked as a duplicate of this bug. ***