Some times you have to open two, three or more files simultaneously, with the same name but a different location. Right now it's very complicated to distinguish which is which by looking at the window title. You have to go to the menu "File -> Properties" to find out this information, which makes you waste some precious time. So it would be very useful to have an option to show the full path of the file in the window title, instead of the file name only. Thanks.
I'm agree with that, at least the actual directory and one or better a couple of precedents directories.
I think better target version 4.4, no new features in the previous versions.
Why the importance was changed to low? It is a really useful enhancement.
I think this sounds good, but I would would like it not as standard, maybe LO should detect it itself if two files with the same name are open. In addition, it could be an alternative option the user can choose if he/she likes it.
*** Bug 83887 has been marked as a duplicate of this bug. ***
Another recommendation for display of 'full path' in filename field (as a user-selectable option). If space is too limiting perhaps it could be done in a way similar to URL flyovers -- i.e., full path displayed only when mouse pointer is moved over the 'filename.'
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
Not clear this is of any real value, my response from -- http://nabble.documentfoundation.org/Full-Path-in-Title-Bar-tc4201654.html ... the project intentionally keeps the OS and its Desktop Environment unencumbered--and we let the OS and DE do their thing. On Windows that means we keep the MS Windows Standard Frame and do not change default Windows application frame to show more than program name, and the file name of an open document and the standard Windows frame button widgets. [1][2] I do not expect that we would change from that default here or for other OS/DE. Especially as you can customize a toolbar (Tools -> Customize: Toolbars tab), and show the "Load URL" widget. It is unchecked but available by default on the Standard toolbar... It can be moved to the bottom -> right of the toolbar, and can be added to any toolbar you choose. The only rub I have with the widget is its fixed width, should be able to adjust. =-refs-= [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb688195(v=vs.85).aspx [2] http://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx#5663
Miguelangel had sent a note asking... but if string text for 'file name' is passed to the OS by LIbreOffice, like it is the 'program name', that can be modified on the expert configuration, like it's explained on https://bugs.documentfoundation.org/show_bug.cgi?id=73803. Perhaps it's no needed interfere with the OS? =-=-= As noted the ooName can be set, but that changed LO value does not get picked up by the Windows Frame manager as the program name until LibreOffice is restarted--so I don't think we could inject the full path there. But it might be possible to optionally pad the opened document name with its path/URI/URL--again don't know that this is really of any value cross platform.
I think the file name only can be passed when it is known, that only happens at the time a new file is opened and there window is created. If I'm not wrong when it's done now. In relation with the utility, maybe for some users not, but when working with several files with the same file name than can come from different folders it's very useful, like 'year folder/months folders/files' with relative path links. And nowadays that you can open a file from your computer or a nas or a place on the cloud becomes even more useful. There are a lot of questions on the net about how to solve it for different apps like MSO.
While the use case is clear I don't agree with the full path solution. Rather than spamming options we should show the distinguishing parts (as m.a.riosv pointed out) by default. The path itself is useless to average users since Windows hides c:\user\whatever and starts from the simple Documents. The same is true for file manager on Linux. The rare corner cases could be ignored. For example: c:\temp\doc1.odt and c:\users\<name>\documents\<this>\doc1.odt will be shown both as doc1.odt but c:\users\<name>\documents\2016\Nov\doc1.odt vs. c:\users\<name>\documents\2016\Dec\doc1.odt as Nov\doc1.odt vs. Dec\doc1.odt. And c:\users\<name>\documents\2016\Dec\doc1.odt vs. c:\users\<name>\documents\2015\Jan\doc1.odt as 2016\Nov\doc1.odt and 2017\Jan\doc1.odt. Similarly on MacOS with hiding \\Users\<name>\ and Linux \\home\<name>\.
definitely not as default.. and if, then with a shortened path xxx/.../yyy/foo.odf Maybe better to have the mouse over for Window > filex, show the full path as is done with File > Recent documents ?
I agree this as an option is important and would be very useful.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
An alternative might be to make the width of the 'Load URL' element of the 'Standard' toolbar changeable.(There are disadvantages, of course.) I visited this bug due to a comment by an impatient user in https://ask.libreoffice.org/en/question/44280/ . He thought waiting >6 years should be enough.
I would like to add to the requests that the full path to a document in the window title would be very useful functionality to have natively in LibreOffice. So please implement the enhancement — 9 years is a long time to wait. This said, I bit the bullet and worked out how to achieve this using a macro — which might suit folks for now. The code for the macro and basic instructions on how to set it up are given here: https://forum.openoffice.org/en/forum/viewtopic.php?p=540971#p540971 Note that I am not in any way an experienced coder, I just stumbled my way to the solution I found. On that basis there is no error checking in the macro code but it works fine in my tests. Hope this helps.