https://bugs.kde.org/show_bug.cgi?id=410395
Kraps <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Kraps <[email protected]> --- recentlyused: registration is still inconsistent. Some methods of opening files do not put them in the registry. Details in the AI summary below. ***AI SUMMARY Adding some additional data points that reinforce comment #3 (the KRecentDocument vs KActivities backend split) and extend the scope beyond Kate's own internal-vs-taskbar mismatch. It appears the split is even more consequential than a simple "two lists out of sync" issue: several common ways of launching a file bypass KRecentDocument registration entirely, regardless of which backend is queried afterward. STEPS TO REPRODUCE (KRunner / external launchers) 1. Launch a file (e.g. a video) via KRunner (Alt+Space), typing part of the filename and activating the match directly (not via the "Recent Documents" runner, but via a generic file-search match, e.g. Baloo/Locate runner) 2. Check recentlyused:/ (Dolphin) or the app's taskbar jump list afterward 3. The file does not appear 4. Open the same file a second time via the application's own native "Open File..." dialog 5. The file now appears correctly in recentlyused:/ and the jump list Same result reproduced with: - FSearch (third-party file search tool) launching a file with its default handler - Files opened by different media players (tested with both Haruna and VLC) reaching the target app as a command-line argument instead of through the app's own file-open dialog In all cases, the *application's own internal* recent-files list (e.g. Haruna's File > Recent Files, VLC's Media > Open Recent Media) correctly shows these files, confirming the app itself is aware of them - it's specifically the KRecentDocument registration step that's being skipped when the file arrives as a launch argument rather than through the app's own dialog. This suggests the gap isn't just "Kate vs KActivities" but a more general pattern: whichever code path handles files passed in via argv (command line, KRunner, xdg-open-style launches, other search tools like FSearch) doesn't consistently call KRecentDocument::add(), while the code path behind the native file-open dialog does. Since this depends on each individual application remembering to add the call in every entry point, the result is inconsistent recent-files tracking across the whole ecosystem, independent of the KActivities/KRecentDocument backend split itself. Given that, would it be feasible to have the registration happen at a more central point instead of relying on every application to call KRecentDocument::add() from every launch path? For example, KRunner (or more generally KIO::run / the desktop file exec pathway) registering the resource itself when it hands off a file to an application, rather than leaving it entirely up to the receiving app. That would sidestep the need to audit/fix every individual application's launch-argument handling separately. -- You are receiving this mail because: You are watching all bug changes.
