Bladeren: recent bestand niet zichtbaar op verwachte plek in systeemkiezer #2561
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
release-blocker
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck#2561
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Gebruikersmelding: na een ander programma een bestand heeft gemaakt, toont Bladeren… in de echte map oudere bestanden maar het nieuwe niet; gemeld voor macOS én Linux.
Codeonderzoek: Openen roept FileService.pickMarkdownFiles aan met FileType.any; op macOS opent de eigen NSOpenPanel met lege allowedContentTypes en shouldEnable=true. Op Linux ontvangt de XDG-portalroute geen extensiefilter. Er is in deze route geen leeftijdsfilter.
MacOS-proef: in een lokale tijdelijke map werden oude en nieuwe .md-bestanden meteen zichtbaar, ook wanneer een tweede bestand werd aangemaakt terwijl het paneel openstond. In de gesynchroniseerde OciDeck-bibliotheek vond de paneelzoekfunctie een recent .md-bestand dat in de gewone bovenste lijstregels niet verscheen. De gewone lijst kan anders gesorteerd of gegroepeerd zijn; nog niet bewezen dat het bestand daar volledig ontbreekt. De in-app zoeklijst vond hetzelfde bestand wel. Linux-gedrag is nog niet lokaal gereproduceerd.
Vervolg: reproduceer op Linux en op een macOS-map met dezelfde bestandsprovider, leg bestandsnaam/extensie, sortering en provider vast zonder inhoud te kopiëren; bepaal daarna of de oorzaak in de portal/het systeemvenster, de bestandsprovider of een OciDeck-aanroep zit. Voeg pas een codefix toe met een test op de bewezen oorzaak. #2558 herstelt alleen de verouderde in-app scan en sluit dit issue niet.
Opgepakt in tak
claude/oplossen-2561-0521a2. Eerst de oorzaak vastleggen (FileService.pickMarkdownFiles, macOS NSOpenPanel-kant en Linux-portalroute); reikwijdte volgt.Onderzoek (geen codewijziging):
OciDeck(gewone APFS-map, gesynchroniseerd door Synology Drive in legacymodus; geen File Provider, dus geen verouderde providerlijst) heeft 92.md-bestanden plus mappen. Het jongste bestand (gewijzigd 23-10 21:16) staat in naamvolgorde op regel 39 van 103. Bij een paneelhoogte van 448 pt (NSNavPanelExpandedSizeForOpenMode) valt dat buiten de bovenste regels. Dat past bij de eerdere proef: de paneelzoekfunctie vindt het bestand wél (de lijst kent het), en in een tijdelijke map met weinig bestanden is alles direct zichtbaar.AppDelegate.swiftzetallowedContentTypes = []enshouldEnable = true, en geeft alleendirectoryURLmee. NSOpenPanel heeft geen publieke API om de sortering te kiezen. Linux:file_picker_linux2.0.0 geeftinitialDirectorydoor als portal-current_folder, zonder filter. Ook de GTK-kiezer sorteert standaard op naam.Conclusie: er is geen OciDeck-oorzaak gevonden die een codefix met test rechtvaardigt. Wie in Bladeren… op de kolom Gewijzigd klikt, zou het bestand bovenaan moeten zien; macOS onthoudt die keuze. Wie het recentste bestand zoekt, gebruikt het Openen-dialoog (ververst sinds #2558). Het issue blijft open tot de schermcontrole is gedaan.
macOS: oorzaak bewezen op het scherm. Het ligt niet aan OciDeck. (Dit corrigeert mijn vorige reactie: het venster sorteert níet op naam.)
Bladeren… in de geïnstalleerde v0.7.0, bibliotheek
OciDeck: het systeemvenster groepeert op Date Last Opened (Previous 7 Days / Previous 30 Days / September / August / Earlier) en sorteert binnen elke groep op Date Added. Bestanden die nooit via macOS geopend zijn, hebben geen Date Last Opened (--). Die vallen allemaal in Earlier, helemaal onderaan, ongeacht hoe nieuw ze zijn. Zo staatCommunicatie_in_vijf_stappen.md(toegevoegd 21-10) onder bestanden uit augustus. Een bestand dat een ander programma net heeft gemaakt, heeft per definitie nog geen 'laatst geopend' en komt dus altijd daar terecht.Waar dat vandaan komt:
defaults read com.apple.finder FK_ArrangeBy=Date Last Opened. Dit is de systeembrede instelling voor alle Open/Bewaar-vensters van alle apps (FileKit), gekozen via het weergavemenu van het venster. De map zelf (.DS_Store: sortColumn name) en OciDeck (AppDelegate.swift: alleendirectoryURL, legeallowedContentTypes) zetten geen groepering. NSOpenPanel heeft er ook geen publieke API voor.Oplossing voor de gebruiker: zet in het venster de weergave-knop (het rasterpictogram met pijltje) → Groepen gebruiken uit, of Rangschik op → Geen / Datum toegevoegd. Dat geldt dan voor alle apps.
Geen codefix: er is geen OciDeck-oorzaak om met een test vast te leggen.
Linux is nog niet gereproduceerd. De portalroute geeft wél
current_foldermee en geen filter (file_picker_linux2.0.0). Daarvoor blijft dit issue open met needs-info: graag de desktopomgeving/portal-backend en de groepeer/sorteerinstelling van die kiezer.Linux: oorzaak gevonden in de bron, niet op een scherm. Melder bevestigt: de kiezer opende in Recent, met de AppImage/tar/AUR-build (geen Flatpak).
OciDeck geeft bij Openen → Bladeren… de bibliotheekmap mee als portal-optie
current_folder, zonder filter (file_picker_linux2.0.0,_pickFilesInternal). Maar de portal-frontend xdg-desktop-portal t/m 1.16 laatcurrent_folderbijOpenFilestil vallen. De optie staat niet inopen_file_options[](gecontroleerd insrc/file-chooser.cop tags 1.14.6 en 1.16.0).xdp_filter_options()geeft alleen opties op die lijst door aan de backend. Pas 1.18.0 stuurt de optie door ("current_folder is intentionally left out" + aparte afhandeling inhandle_open_file). De backends zelf (-gtk,-gnome) passen hem wel toe bij open.Gevolg op Debian 12 (1.16) en Ubuntu 22.04 (1.14): het GTK-venster begint in Recent. Die lijst toont alleen bestanden uit
recently-used.xbel: oudere, ooit via de desktop geopende bestanden wél, een net door een ander programma geschreven bestand niet. Dat is precies het gemelde beeld.Zelfde patroon als macOS: in beide gevallen hangt 'recent' in het systeemvenster af van een register dat het besturingssysteem bijhoudt, en een vers geschreven bestand staat daar niet in. OciDeck kan een oude portal niet dwingen de map te openen. Het interfaceversienummer is in 1.16 en 1.18 allebei 3, dus de app kan het verschil ook niet betrouwbaar detecteren.
Wat er gebeurt: een item in
docs/KNOWN_LIMITATIONS.md(+.nl.md) dat beide gevallen en de omweg beschrijft. Het Openen-venster van OciDeck zelf leest de map en toont het bestand wel (sinds #2558).Niet gedaan: een schermcontrole op een echte Linux-desktop (geen machine beschikbaar). Welke portalversie op die machine draait (
/usr/libexec/xdg-desktop-portal --version) zou de laatste stap bevestigen.Afgerond in PR #2582 (merge
c2f3912de0):docs/KNOWN_LIMITATIONS.md+.nl.md, sectie Browse… shows what the system file dialog shows / Bladeren… toont wat het systeemvenster toont. Beide oorzaken staan erin, met de omweg.Geen codefix: macOS (groepering via
FK_ArrangeBy) en Linux (portal ≤1.16 laatcurrent_foldervallen) liggen buiten OciDeck en zijn vanuit de app niet te sturen of te detecteren.Niet in deze afronding: een schermcontrole op de Linux-machine zelf. Toont
/usr/libexec/xdg-desktop-portal --versiondaar 1.18 of hoger en opent de kiezer tóch in Recent, dan klopt de Linux-verklaring niet: heropen dit issue dan.