Created attachment 87457 [details] Screenshot Hello, Another bug inherited from OOo, if a file has a name with an Complex RTL script, it does not display properly on the window bar. So far I've tried with Arabic and Hebrew, it is broken. However, file names with Runic RTL scripts display properly. Attaching a screenshot now.
would you please attach a test document with such a problematic filename?
Is this LibreOffice/OpenOffice specific? Looks like OS issue to me, what happens if you open the file (or similarly named one) in other applications?
That bug does not manifest on Windows as the program window is not mirrored there. But that's how the current title is displayed when titlebar is RTL.
Created attachment 89684 [details] Same file in TextEdit This is a LO/AOO/NO specific issue, here you can see the same file opened with TextEdit. Anyway, I am setting this issue to NEW, since it is obviously broken.
Emir, would a test odt be useful in this case? Can you point out clearly what is not displayed correctly? For people unfamiliar with arabic or hebrew text it might not be obvious.
In my system TextEdit shows only the file name in the titlebar, so I can’t compare this. But the LibreOffice issue can be easily explained; LibreOffice sets the title as <file name> - LibreOffice <app name>, if the file name starts with a strong left to right character then Mac OS X displays the string with RTL base direction, and then we get the ugly mix of RTL and LTR text. You can easily reproduce this by typing the string: نص.odt - LibreOffice Writer In Writer and setting the text direction to RTL, you will end up with the same mix. One solution to this is to drop the " - LibreOffice <app name>" from the title bar entirely. Another solution is to force the title to always have a LTR direction by appending a U+200E (Left To Right Mark), but what about users using RTL UI? Detect it and insert U+200F (Right To Left Mark) instead?
I'll try to reproduce the issue with different software and post the results to see how they are handling. I think the best way would be dropping the LibreOffice name, software name is already displayed on the menu bar, so there is no need for a second presentation I think. Also this would prevent any future bugs or inconsistencies possible.
I can reproduce this bug, marked as NEW
Where does the code reside for this? I searched but I could not find. I want to try to fix this.
Check https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=vcl/osx/salframe.cxx;h=6b236d6779840c0bc251f9798e092f2aab62cb51;hb=HEAD#l299 and the code that calls it.
I just did a quick search on the Apple Developer Base, and found this. If we would drop the file name from the titlebar, would this fix this bug: NSString* pTitle = CreateNSString( rTitle ); [mpNSWindow setTitleWithRepresentedFileName: pTitle];
Update: I replaced the string in salframe.cxx, first build attempt aborted because I did not add the string to salframe.h. For the second build attempt I got this error: /Users/Emir/lo/core/vcl/osx/salframe.cxx:308:5: warning: instance method '-SetTitleWithRepresentedFileName:' not found (return type defaults to 'id') [-Wobjc-method-access] [mpNSWindow SetTitleWithRepresentedFileName: pTitle]; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/Emir/lo/core/vcl/osx/salframe.cxx:328:13: warning: instance method '-SetTitleWithRepresentedFileName:' not found (return type defaults to 'id') [-Wobjc-method-access] [mpDockMenuEntry SetTitleWithRepresentedFileName: pTitle]; Any ideas?
Like all (?) Objective-C method names, the first letter is lower-case: setTitleWithRepresentedFilename. But that won't help, I think, or at least will be confusing, as it will just make OS X think the whole title string, including the " - LibreOffice BlaBla", is part of the file name. Instead, you should find out what it is that constructs the window title on higher levels (unfortunately, a quick git grep for " - " did not help), and there drop the application name in the case of OS X.
Could possibly be the code in TitleHelper::impl_updateTitleForFrame() in framework/source/fwe/helper/titlehelper.cxx , testing that. (But it will take a while as my Mac build is currently ongoing.)
I also read that setTitleWithRepresentedFilename does always force displaying of proxy icon, in whick LO has a problem already (Bug 59163). I think this titlebarhelper.cxx is the part which displays LibreOffice Writer, Calc on the title bar according to the component wouldn't it make more sense to drop it all completely? In Mac all modern Mac applications app name is never shown on the title bar, in LO case it is understandable since it has many components, but I think it would not harm to drop it all completely, since I think everyone knows which component they are working on.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eeb840d6ba930015b969c3d0a98031f0ae508d61 fdo#70376: Put only document (file) name in window title on OS X The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 93340 [details] after the patch!
Thank you Tor! Fixed and verified! LO titlebar looks neater now! Any chance to port this for 4.2 as well?
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=53bd91ad654495130ceba74dd72d4a6f95c94fc5&h=libreoffice-4-2 fdo#70376: Put only document (file) name in window title on OS X It will be available in LibreOffice 4.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.