Description: I’d like the saved directory path for replacing images to be saved for each document. Currently it seems to be saved globally. If this cannot be done for each document (or when no history of opened files of the current session is existing for this exact document), I’d propose to set the open path to the document-containing folder. Steps to Reproduce: Replace one image in one first document and then try to replace an image in another second document. Actual Results: The file-chooser dialog is opened at the path where you picked the image for the first document’s replace action. Expected Results: I think this could be improved by saving this path per document, so that you either end up where you picked one file _for that exact document_ before, or alternatively (fallback) at the folder of the document. Reproducible: Always User Profile Reset: No Additional Info:
Additionally, in case of my flatpak deployment sometimes the flatpak-internal path `~/.var/…/…/…` gets opened. This also is not useful and should be avoided. ;)
The linean part where the user will find the part which may be going to get the part for which it must be having the function to make it processes through https://uaetechnician.ae/logitech-h111-mic-not-working-resolve-this-problem-quickly-just-in-few-easy-steps that find the settings perfectly.
Insert > Image opens by default user/gallery what you can change at Tools > Options > Path > Images. Both Insert as well as Replace inherit the last used folder (or the default). Works for me, you too?
Yeah, but when you work simultaneously on multiple documents (because you might have several distinct projects at work), paths of document #1 get to be the default for actions in document #2. Which is why I’d like ask if this could be changed so that this “inherited last used folder” gets to be document-specific.
You mean two parallel open applications and you switch from A using folder AI to B with BI. Or document X using A1 and later Y for B1? The only hurdle in this case is that you have to load once from the correct path. Not a big deal. What do you think, Michael. Do we want to store the (image) folder(s) with the document?
I think storing that in the document itself would not be helpful, because then LO might display your path to other users. I guess it’s better to store such data in the local LO user data. When LO (the general application) gets opened, all previous used documents are shown to the user. I think it would make sense to append such paths to the according (document-specific) code structures there?
i agree with comment #6; i think currently we don't store any paths as settings in documents.
(In reply to zyklon87 from comment #6) > I think storing that in the document itself would not be helpful, because > then LO might display your path to other users. I guess it’s better to store > such data in the local LO user data. When LO (the general application) gets > opened, all previous used documents are shown to the user. I think it would > make sense to append such paths to the according (document-specific) code > structures there? Hm, good point. So the change would be to remove Tools > Options > Path (resp. have it hidden under the expert options) and silently remember the last used path. Could imagine that admins are not too happy with this change. Your opinion, Justin?
(In reply to Heiko Tietze from comment #8) > and silently remember the last used path. OP is specifically asking that it is remembered PER DOCUMENT. If I understand OP correct, LibreOffice already silently remembers the last used path at an application level. > So the change would be to remove Tools > Options > Path > (resp. have it hidden under the expert options) When LO starts, it can still honour this initial setting. There is no reason to change the application-level default to resolve this per-document bug. Any document meta-data setting would simply override the application default.
(In reply to Justin L from comment #9) > ...understand OP correct, LibreOffice already silently remembers the last used > path at an application level. The positon changed because of security reasons - you have to store private data . We have a per session memory taking the initial value from options. That could be moved into expert options and overwritten per session.
(In reply to Justin L from comment #9) > OP is specifically asking that it is remembered PER DOCUMENT. If I > understand OP correct, LibreOffice already silently remembers the last used > path at an application level. Correct. :) > When LO starts, it can still honour this initial setting. There is no reason > to change the application-level default to resolve this per-document bug. > Any document meta-data setting would simply override the application default. Sounds good!
Embedding the path into the ODF would not be the way to go. Next would be demands to turn it off or bypass it "for security". IMHO a reasonable enhancement, use case for working with several documents is valid--and it just depends on how much effort it would require to make it per document. That is if not well supported with current document handling in user profile, probably not worth the effort to force it in. Status quo is functional if a bit more demanding of the user to track their environment. Can the Path.NamedPath['Graphic'], even be moved from per session to per document? Otherwise can the FilePicker_Graph be set per active document and included with each documents Histories picklist? So if a scheme to hold the path per document within the user's profile, great! I don't see that as any different than the current document path held for MRU Histories picklist and the document thumbnails that are already held in the regsitrymodifications.xcu. And when the document is removed from the MRU picklist--any other path related details would be removed as well.
Let's resolve this. Storing the path in the document is a security/privacy issue. And actually I'd say working on multiple open documents that access a lot of images from different sources is not a frequently situation.