On most programs in OSX, if you press for example e, and keep your finger on the key, a small "window" appears and permits you to select various accented versions of this character.
You can test this in TextEdit, TextMate, Microsoft Word or Matlab.
It's not a general solution to keyboard problems. But it is helpful, if you have the wrong keyboard for the language written or if you have to write a name with foreign accents.
Unfortunately, this does not work in LibreOffice.
I would like to thank you for this program I use with great pleasure and which is definitely very helpful to me
Best reagrds, Mathias
Thank you very much for your report/request! I'm sorry that it was not processed earlier (we have few MacOS X users in the QA team, of course).
The functionality you mention was introduced with MacOS X 10.7, right? (At least I don't see it in MacOS X 10.6).
I can confirm that this functionality does not work in LibreOffice, therefore setting the Status of this report to NEW.
I change the Summary to make it easier to see that this is a feature request.
*** Bug 49967 has been marked as a duplicate of this bug. ***
I have access to a Mac OS X 10.7.5 macbook pro: I can confirm that this is common in most applications and should be integrated into LibO. (dunno when this feature was introduced, I don't have access to any other versions right now)
Created attachment 89361 [details]
TextEdit and NeoOffice Write in comparison
Just for the record: I just installed NeoOffice 3.4 and they have that feature included but sadly that way that you have to click e long and that many eeees will be produced until the optional characters are displayed. In TextEdit only one e is added and the "popup" is displayed.
With super reaction someone is able to post only three "e"s in the new document until the popup is displayed. see additional the cropped screenshot.
OSX has had the ability to easily enter accented characters since 10.7, which is a great help to anyone who writes in more languages than just English. This is supported in ANY OSX application, with the sole and remarkable exception of LibreOffice as well as OpenOffice. A search on Google for the issue produces enough hits to suggest it's no longer a trivial 'enhancement', OSX based newcomers to LibreOffice now flag this as a bug with a fairly direct and critical impact on usability for multilingual use.
Online recommendations to "use another editor" such as MS Office or Pages (which both do support the accented character facility) can now be found, but are naturally rather unhelpful to people like us that seek to promote LibreOffice everywhere they go and work.
Please help us to help you*. Cheers, D
* Happy to beta test, am using OSX 10.10.5.
*** Bug 98364 has been marked as a duplicate of this bug. ***
Sorry, but this is *NOT* a bug as supporting "this or that" OS X Cocoa NSObject widget implements by Apple requires development effort beyond the core cross platform code in LibreOffice.
Yes, support for the OS X PressAndHold.app added by Apple at 10.7 (Lion) is a reasonable enhancement that requires a developer with interest in native OS X Cocoa widgets to take an interest.
It is already an "OS X Shine and glow" meta.
Until then, the LibreOffice Special Character dialog supports this use requirement, and its capabilities are being actively improved. Admittedly it will never be as seamless as PressAndHold may be for OS X users, but until a developer takes on this enhancement it is what is available cross platform.
*** Bug 109154 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #7)
> Sorry, but this is *NOT* a bug as supporting "this or that" OS X Cocoa
> NSObject widget implements by Apple requires development effort beyond the
> core cross platform code in LibreOffice.
No, I would define this as standard functionality expected by users of the platform. Key to OSX and macos is usability, which also happens to be one of the guiding arguments to install LibreOffice in the first place because it has a more stable UI.
> Yes, support for the OS X PressAndHold.app added by Apple at 10.7 (Lion) is
> a reasonable enhancement that requires a developer with interest in native
> OS X Cocoa widgets to take an interest.
> It is already an "OS X Shine and glow" meta.
Does this mean there already is a possibility to enable this functionality for macos but you omit this deliberately?
> Until then, the LibreOffice Special Character dialog supports this use
> requirement, and its capabilities are being actively improved.
With all due respect, that "support" could do with a lot of improvement for anyone who has to use this functionality for more than once in a day so I would welcome an update on what improvements are underway. It's not like this bug has only been outstanding for a few days.
Anyone who works in more languages than just English needs this. Improvements which macos already provides but maybe it would be better to replicate this approach so all platforms can enjoy it. In that case, it also needs to be as optional as it is for macos - I would not allege Apple's approach to be perfect either (as it swaps key repeat for selected keys with accent functionality) but it's a factor better than the current functionality in LO.
For the moment, it means that people who write more than occasionally in non-English languages are not served well in LibreOffice, a fact also illustrated by the update process that is sufficiently non-trivial for those who have the temerity not to speak American (as opposed to English) to disqualify it for serious end user deployment (and yes, I'll file a bug for that in a minute).
> will never be as seamless as PressAndHold may be for OS X users, but until a
> developer takes on this enhancement it is what is available cross platform.
Isn't there a conditional in the compiler so you can tell it to use this input function when compiling for macos? It's not just that LibreOffice functionality isn't as useful, it means that on macos, the use LibreOffice effectively reduces functionality that users expect and that does not help deployment in multi-lingual environments.
It's OK if you have, for instance, LO in a language of the country itself because keyboards typically support all accents directly - a classic example of that is the Swiss keyboard that has to support several languages at once and is thus a pain to use for programming, or the French who use AZERTY (which always takes me a few minutes to get used to), but users who operate in English and have an English keyboard - well, they're stuck. Not just in macos.
This is a serious, long lasting issue.
As reported on https://apple.stackexchange.com/questions/308104/activate-pressandhold-for-libreoffice-or-openoffice, it is basically the only text editor or macos app with this text input issue for non-English languages.
The only known alternative we have is to use Microsoft Office for Mac in the mean time, which is quite an expensive solution just to get default keyboard input support.
"The only known alternative we have is to use Microsoft Office for Mac in the mean time, which is quite an expensive solution just to get default keyboard input support"
With all due respect for the covert Microsoft advertising, there IS an alternative with both better price and usability à la LibreOffice: NeoOffice, which is compiled specifically for MacOS.
Not only does that solve the foreign language input (which, I must add, I agree with you as a tragic and frankly embarrassing omission), but it also solves the installer and update conundrum: it is ONE file, which installs for all supported languages, and an update is user compatible too in that it is again one action that does not destroy the language settings of the user (which in LO/OO requires an extra action post language pack installation).
In other words, if you want a non-Englisg speaker to install LibreOffice on Mac, the NeoOffice derivative is more than worth its frankly puny donation, to the point of making me consider to make it a standard part of our office build and pay the guy a bit more per unit for the hassle he saves us. But I digress.
n summary, agree with the foreign language input, but there ARE alternative solution that do not involve paying a tithe to Redmond for ruining your productivity :).
With the arrival of MacOS 10.14 Mojave I think we can now consider this a bug instead of a mere feature request as this has been outstanding since MacOS 10.7, or since LO v3.4.3, or maybe the observation that this bug will celebrate its sixth anniversary in the system at the end of the month may be sufficiently illustrative.
Is something really still a "feature request" if non-implementation actively conflicts with usability on a platform usability? Has anyone actually tried to use LO's native facility which is, umm, not quite as useful?
I suspect that this request got buried under all the other fun stuff added to LO to bring it to v6, so I'm pulling from underneath the pile, dust if off a bit and put it back where it can be seen, faded as it has become over time..
Sorry it is still an enhancement, as with comment 7 all the wishing in the world will not materialize a dev to integrate support of a native NSObject PressAndHold.app
Otherwise the LibreOffice special character dialog and the <alt>+X Unicode toggle are what is provided.
Lions and Tigers and Bears! The last time I made an irreverent comment such as yours about ancient OSX bugs and engaged in a bit of Civil Disobedience (35361) I was roundly scolded, rofl...
Bottom line is that apparently there are not a lot of people who want to work on these OSX issues so they just get ignored.
Oh, I don't mind prodding the bears a bit if it sorts out a problem - hopefully I didn't poke too hard as it was more meant as a bit of good natured ribbing. I am principally against blatting people who do free work for a community because that feels rather ungrateful.
If it is more a matter of someone with MacOS background assisting to get this in place rather than not-invented-here syndrome I have some semblance of an answer and can now see if I can find someone who wants to assist.
I'll just use NeoOffice for now, but I'll have a look around for someone who could pick this up.
I'll be back ( ™1984 by Schwarzenegger)..
(In reply to Fred from comment #15)
> If it is more a matter of someoneth MacOS background assisting to get
> this in place rather than not-invented-here syndrome I have some semblance
> of an answer and can now see if I can find someone who wants to assist.
The project definitely has a lack of devs who are comfortable/familiar with the specifics of MacOS development - the more merrier, if you can manage to bring any on board, it would be most welcome !
*** Bug 121319 has been marked as a duplicate of this bug. ***
*** Bug 123664 has been marked as a duplicate of this bug. ***
Reading through the comments here after posting my own request for the feature (and having it linked to this thread), I see that many other commenters see the need for it. Some of them stated the need much more eloquently than I. I understand the need for development to take care of other more important things first, but I must agree that the implementation of this feature is way overdue.
Changing priority to 'high' since the number of duplicates is 5 or higher