Bug 355399

Maybe here is a workaroud for this:

Now I notice the restore-previous-session feature of KDE is able to restore the opened files of Okular and finally functions well after Plasma 5.8, so it is less important for me to require such a function in Okular.

This bug/feature request still stands for people using Okular on desktops other than KDE. In other words, the session restore feature mentioned by the original poster is not available in other desktop environments, including Unity, Gnome, etc. So the users of Okular using alternative desktops still need the number of recent documents increased, or a desktop-independent, application-specific session restore feature implemented.

"desktop-independent session restore" is implemented, maybe it's just that your desktop doesn't support session restore, complain to them.

I'm the creator of the ticket. My purpose is not to have opened PDFs restored on next session. It really is to be able to see the last 20, 50 or 100 PDFs that were opened, because I open/close a lot of them, and I very often need to open a recently opened one. 10 is far far too little for me.
I'm pretty sure i'm not the only one having this use case.

I am interested in implementing this feature, where do I start?

https://api.kde.org/frameworks/kconfigwidgets/html/classKRecentFilesAction.html

Not Okular-specific, since Okular uses the KRecentFilesAction class that's common to many KDE apps. Support needs to be added there, and then all KDE apps will benefit from it.

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

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

KRecentFilesAction has setMaxItems(); Okular can make use of it to fix this bug report.

I would recommend making the UI to change that number visible globally and affect everything that uses KRecentDocuments, rather then just doing it for Okular.

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

This bug become more relevant since the introduction of "Ctrl+Shift+I to open command plate".

I wish I can just increase the limit to 1000, so that I can open any old PDF from command plate blazing fast/

(In reply to shenlebantongying from comment #13)
> This bug become more relevant since the introduction of "Ctrl+Shift+I to
> open command plate".

What's "command plate" ??

(In reply to Thomas Capricelli from comment #14)
> What's "command plate" ??

On Windows it's Ctrl+Alt+I instead. You can find it under Help > Find Action... at the menubar.
It indeed makes searching recent PDFs very efficient, as it can display up to 22 files in the search result box.

> I would recommend making the UI to change that number visible globally and affect everything that uses KRecentDocuments, rather then just doing it for Okular.

recentlyused:/ replacement for recentdocuments:/ has currently not history limit.
You can easily strip last days, hours or months though.

Note you can make special urls like recentlyused:/files/?type=application/pdf (copy paste this in dolphin url field) to get recently accessed pdf. (Details at http://www.bivouak.fr/recently-used-ioslave/)

I have plans to cap the number of entries and/or their recency plus whilelist/blacklist paths in complement to applications.
I plan also to make it affect Gtk applications history.

In the meantime I consider this fixed. New input welcome.
(recentdocuments:/ is to be considered deprecated and should be removed soonish.

> I have plans to cap the number of entries and/or their recency plus whilelist/blacklist paths in complement to applications.
> I plan also to make it affect Gtk applications history.
> 
> In the meantime I consider this fixed. New input welcome.
If you plan to add this feature in the future, then it can't be fixed yet, right? :) Right now we have the ability to disable file history completely, but not configure the number of shown items. Let's close it only once the feature is merged.

(In reply to Nate Graham from comment #17)
> > I have plans to cap the number of entries and/or their recency plus whilelist/blacklist paths in complement to applications.
> > I plan also to make it affect Gtk applications history.
> > 
> > In the meantime I consider this fixed. New input welcome.
> If you plan to add this feature in the future, then it can't be fixed yet,
> right? :) Right now we have the ability to disable file history completely,
> but not configure the number of shown items. Let's close it only once the
> feature is merged.

All right.

I closed it in the first place because of the user workflow:

> For people like me who open dozens of PDFs a day (and other formats, too), the 9 or 10 items in the "Open recent ..." menu is really too short. I'm pretty sure I'm not an exception about this.

Is already sorta fixed.
Default size is now 30 entries and this is configurable (for tech savy users I will admit)

The fix suggestion (and bug title) did not focus on any workflow, but the one here is kinda covered, since users can display any number of recent entries and filter by mimetype, should they take the time to set things up.

(original author of the ticket here, which was about okular)
I'm not sure to understand all here, but:
* 30 is still too short for me
* You seem to say that we can have a lot more history, but from something else, not from within okular. I kinda.. dislike this. I dont want to go somewhere else to find something related to the software i'm currently using (nope ?)

For "something else", you mention "command plate", still not sure what this is; and I guess the "recentlyused:/" stuff if from dolphin ?

(In reply to Thomas Capricelli from comment #19)
> (original author of the ticket here, which was about okular)
> I'm not sure to understand all here, but:
> * 30 is still too short for me
> * You seem to say that we can have a lot more history, but from something
> else, not from within okular. I kinda.. dislike this. I dont want to go
> somewhere else to find something related to the software i'm currently using
> (nope ?)

Does the Open/Save dialog counts ? Ctrl+o

Your talking about something entirely different the application internal cache of recently opened files for apps.
I.e https://api.kde.org/frameworks/kconfigwidgets/html/classKRecentFilesAction.html
I misunderstood your first comment.

In fact this history here is defined by applications and they can choose how many entries there store.
So what you'd need is either change okular to have or allow this number of entries to be bigger, or we could have a system wide default for this value editable.

> 
> For "something else", you mention "command plate", still not sure what this
> is; 

Ctrl+Alt+I in okular and you get the command plate opened, a way to quickly access entries in the menu with the keyboard.

> and I guess the "recentlyused:/" stuff if from dolphin ?

Yes, you can try to open recentlyused:/files/?type=application/pdf?limit=50

We probably need for all the various lists of recent files in apps, Kickoff, and the list of recent files provided by the KIO worker to be consistent and use the same number, and that number should be globally configurable.

Right now:
- recentlyused:/files/ shows me 16 things
- Kickoff > Places > History shows me 14 things
- Kate's "Recent Files" list shows me 10 things

(In reply to Nate Graham from comment #21)
> We probably need for all the various lists of recent files in apps, Kickoff,
> and the list of recent files provided by the KIO worker to be consistent and
> use the same number, and that number should be globally configurable.

I agree but we will need IMO two settings as the two serve different purposes.

> 
> Right now:
> - recentlyused:/files/ shows me 16 things
> - Kickoff > Places > History shows me 14 things

Those two use the same backend, kactivitystats, data is session wide.
Allowing you to see files open in kate and while in dolphin, opening it with another program or its parent folder for instance.

> - Kate's "Recent Files" list shows me 10 things

That's KRecentFilesAction a per-app history, only the files accessed in this app.

-- Side notes
We also have KRecentDocument and ~/.local/share/recently-used.xbel to share data session-wide with gtk. It serves both use cases, per-app and system-wide.

Also we might want one day to have KRecentFilesAction use kactivity-stats as backend, to reduce data duplication.

As a side note recentlyused:/ entry number is configurable for instance: recentlyused:/?limit=50 (next KIO-extras will allow limit bigger than 50 but for now this is limited https://invent.kde.org/network/kio-extras/-/merge_requests/180)

Why would we need two settings? We may use different data sources for these UIs, but that's an implementation detail that the user doesn't care about, right?

(In reply to Nate Graham from comment #23)
> Why would we need two settings? We may use different data sources for these
> UIs, but that's an implementation detail that the user doesn't care about,
> right?

Say you have one setting, you set it to 30, you open 30 files in okular.
Then in dolphin recentlyused:/ you only see those thirty despite just before you opened a few files in kate.

In comparison, say you have two settings, the setting per-app set to 30 and session-wide to 100.
In this case with the same scenario I get the last 30 files opened in okular and 70 previously accessed files in other applications.

My previous comment was not explicit enough, the two histories are not the same and serve different purposes.

(In reply to Méven Car from comment #24)
> (In reply to Nate Graham from comment #23)
> > Why would we need two settings? We may use different data sources for these
> > UIs, but that's an implementation detail that the user doesn't care about,
> > right?
> 
> Say you have one setting, you set it to 30, you open 30 files in okular.
> Then in dolphin recentlyused:/ you only see those thirty despite just before
> you opened a few files in kate.
> 
> In comparison, say you have two settings, the setting per-app set to 30 and
> session-wide to 100.
> In this case with the same scenario I get the last 30 files opened in okular
> and 70 previously accessed files in other applications.
> 
> My previous comment was not explicit enough, the two histories are not the
> same and serve different purposes.

I would also say that the files in the right-click menu of app icons and those in the within-app menus serve different purposes and I'd like the latter to be much longer.

(In reply to David from comment #25)
> (In reply to Méven Car from comment #24)
> > (In reply to Nate Graham from comment #23)
> > > Why would we need two settings? We may use different data sources for these
> > > UIs, but that's an implementation detail that the user doesn't care about,
> > > right?
> > 
> > Say you have one setting, you set it to 30, you open 30 files in okular.
> > Then in dolphin recentlyused:/ you only see those thirty despite just before
> > you opened a few files in kate.
> > 
> > In comparison, say you have two settings, the setting per-app set to 30 and
> > session-wide to 100.
> > In this case with the same scenario I get the last 30 files opened in okular
> > and 70 previously accessed files in other applications.
> > 
> > My previous comment was not explicit enough, the two histories are not the
> > same and serve different purposes.
> 
> I would also say that the files in the right-click menu of app icons and
> those in the within-app menus serve different purposes and I'd like the
> latter to be much longer.

You are talking about right-clif in app-icon in kickoff, i.e the taskbar, I presume.
In this case the backend is kactivities-stats , the number of entries displayed there is simply a UI thing.
We could have a setting in kickoff to set this.
That's yet another case, that would be worth reporting in its own separate bug.

(In reply to Méven Car from comment #26)
> (In reply to David from comment #25)
> > (In reply to Méven Car from comment #24)
> > > (In reply to Nate Graham from comment #23)
> > > > Why would we need two settings? We may use different data sources for these
> > > > UIs, but that's an implementation detail that the user doesn't care about,
> > > > right?
> > > 
> > > Say you have one setting, you set it to 30, you open 30 files in okular.
> > > Then in dolphin recentlyused:/ you only see those thirty despite just before
> > > you opened a few files in kate.
> > > 
> > > In comparison, say you have two settings, the setting per-app set to 30 and
> > > session-wide to 100.
> > > In this case with the same scenario I get the last 30 files opened in okular
> > > and 70 previously accessed files in other applications.
> > > 
> > > My previous comment was not explicit enough, the two histories are not the
> > > same and serve different purposes.
> > 
> > I would also say that the files in the right-click menu of app icons and
> > those in the within-app menus serve different purposes and I'd like the
> > latter to be much longer.
> 
> You are talking about right-clif in app-icon in kickoff, i.e the taskbar, I
> presume.
> In this case the backend is kactivities-stats , the number of entries
> displayed there is simply a UI thing.
> We could have a setting in kickoff to set this.
> That's yet another case, that would be worth reporting in its own separate
> bug.

But those are marked as duplicates of this bug: https://bugs.kde.org/show_bug.cgi?id=389957

(In reply to David from comment #27)
> (In reply to Méven Car from comment #26)
> > (In reply to David from comment #25)
> > > (In reply to Méven Car from comment #24)
> > > > (In reply to Nate Graham from comment #23)
> > > > > Why would we need two settings? We may use different data sources for these
> > > > > UIs, but that's an implementation detail that the user doesn't care about,
> > > > > right?
> > > > 
> > > > Say you have one setting, you set it to 30, you open 30 files in okular.
> > > > Then in dolphin recentlyused:/ you only see those thirty despite just before
> > > > you opened a few files in kate.
> > > > 
> > > > In comparison, say you have two settings, the setting per-app set to 30 and
> > > > session-wide to 100.
> > > > In this case with the same scenario I get the last 30 files opened in okular
> > > > and 70 previously accessed files in other applications.
> > > > 
> > > > My previous comment was not explicit enough, the two histories are not the
> > > > same and serve different purposes.
> > > 
> > > I would also say that the files in the right-click menu of app icons and
> > > those in the within-app menus serve different purposes and I'd like the
> > > latter to be much longer.
> > 
> > You are talking about right-clif in app-icon in kickoff, i.e the taskbar, I
> > presume.
> > In this case the backend is kactivities-stats , the number of entries
> > displayed there is simply a UI thing.
> > We could have a setting in kickoff to set this.
> > That's yet another case, that would be worth reporting in its own separate
> > bug.
> 
> But those are marked as duplicates of this bug:
> https://bugs.kde.org/show_bug.cgi?id=389957

I have unmarked it as duplicate, it is not.
Bug triagers can make mistakes, everyone can help on that front, including you pointing a mistake out.
Thanks

Well, it *was* a valid duplicate of this bug when this bug was tracking the idea of a globally configurable number of recent files that's respected everywhere. If we don't want to do that, and we want to make these separately configurable between in-app lists and shell features (etc), then it makes sense to have multiple bug reports, one tracking each place we'll need to have a setting.

That said, I'm not convinced it's a good idea. I think the distinction between different types of "Recent [thing]" lists with different sources won't have meaning to users, and committing to multiple settings would complicate and fragment the UI.

(In reply to Méven Car from comment #20)
> Does the Open/Save dialog counts ? Ctrl+o

Nope, it's a kind of global list, right ?
Btw, It's weird to have lot of files that okular can't open appear in such a list.

> Your talking about something entirely different the application internal
> cache of recently opened files for apps.

Yes, I guess. I'm talking about the menu "file/recent files" (i think the original report was clear about this, no ). I currently still have 10 entries there. I didn't even know there was those global recent files stuff.

The original report was about okular, not about kde in general. I even pointed to the KRecentFilesAction::setMaxItems()

> So what you'd need is either change okular to have or allow this number of
> entries to be bigger, or we could have a system wide default for this value
> editable.

I am definitely asking for a change in okular, not system wide.

> Ctrl+Alt+I in okular and you get the command plate opened, a way to quickly
> access entries in the menu with the keyboard.

Hey, indeed. I didn't know that. But of course, you only get what the menu have.

(In reply to Méven Car from comment #20)
> Your talking about something entirely different the application internal
> cache of recently opened files for apps.

For the record, the original title i had put to the ticket was "make # of recent files configurable". 

I dont know when the 'globally' waa added (nor by whom)

(In reply to Thomas Capricelli from comment #31)
> (In reply to Méven Car from comment #20)
> > Your talking about something entirely different the application internal
> > cache of recently opened files for apps.
> 
> For the record, the original title i had put to the ticket was "make # of
> recent files configurable". 
> 
> I dont know when the 'globally' waa added (nor by whom)

It is also targeting product systemsettings.
Feel free to correct this, since you are the bug reporter you are best placed to correct this.

This ended up opening several points, but not directly related.

And for your feature request, we can always fix it in several ways.
I'd rather have a default number of entries configurable for in-app history and then apps can tweak things as they like.
Maybe you want 50 entries in okular, but wouldn't you say that useful in kate as well for instance ?

(In reply to Méven Car from comment #32)
> And for your feature request, we can always fix it in several ways.
> I'd rather have a default number of entries configurable for in-app history
> and then apps can tweak things as they like.
> Maybe you want 50 entries in okular, but wouldn't you say that useful in
> kate as well for instance ?

I dont use kate :-)
I dont really need as much entries in other applications, but i would definitely prefer 50 everywhere than current situation.
I dont have an example here, but i know some applications do have the # of entries configurable in their (own, not kde, not global) settings.