wxCocoa: (Re)implementation of wxNSView(TextInput)

classic Classic list List threaded Threaded
3 messages Options
KT
Reply | Threaded
Open this post in threaded view
|

wxCocoa: (Re)implementation of wxNSView(TextInput)

KT
I develop a word processor using wxWidgets which uses a custom text editing view. (Think wxRichTextCtrl but more specialized/optimized.)

The problem is that there are a number of Mac-specific text-editing niceties that are missing due to the placeholder implementation of wxNSView(TextInput) in window.mm. These include things like the accent/diacritic long-press popup, proper positioning of IME panels, etc.

The way to address this is, I believe, to properly implement the NSTextInputClient protocol, but that really can't be done in a generalized manner because the implementation is going to need to get a lot of application-specific information.

So really my question is, has anyone looked into this in any depth? I'm no Objective-C expert, unfortunately, but I'm trying to understand if it's possible to replace the placeholder implementation of wxNSView(TextInput) that's in window.mm with a complete, application-specific implementation on the user side of things. (That is, without actually maintaining a separate copy of window.mm, or at least that part of it — something that would become very complicated very quickly.)

Thanks.

KT

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxCocoa: (Re)implementation of wxNSView(TextInput)

Vadim Zeitlin-4
On Mon, 12 Nov 2018 14:00:44 -0800 (PST) KT wrote:

K> I develop a word processor using wxWidgets which uses a custom text editing
K> view. (Think wxRichTextCtrl but more specialized/optimized.)
K>
K> The problem is that there are a number of Mac-specific text-editing
K> niceties that are missing due to the placeholder implementation of
K> wxNSView(TextInput) in window.mm. These include things like the
K> accent/diacritic long-press popup, proper positioning of IME panels, etc.
K>
K> The way to address this is, I believe, to properly implement the
K> NSTextInputClient protocol, but that really can't be done in a generalized
K> manner because the implementation is going to need to get a lot of
K> application-specific information.

 I don't know anything about this particular protocol, but usually the
"application-specificity" is achieved by either generating events or
calling virtual methods, which can be overridden at the application level,
from the protocol methods. Would this work here?

K> So really my question is, has anyone looked into this in any depth? I'm no
K> Objective-C expert, unfortunately, but I'm trying to understand if it's
K> possible to replace the placeholder implementation of wxNSView(TextInput)
K> that's in window.mm with a complete, application-specific implementation on
K> the user side of things. (That is, without actually maintaining a separate
K> copy of window.mm, or at least that part of it — something that would
K> become very complicated very quickly.)

 Using Objective-C in your own project might be possible but it would be
better to add missing support to wxMac itself. Could we start with some
concrete, ideally small and simple, feature that is currently missing and
see what would it take to add support for it?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
KT
Reply | Threaded
Open this post in threaded view
|

Re: wxCocoa: (Re)implementation of wxNSView(TextInput)

KT
On Friday, November 16, 2018 at 6:39:11 AM UTC-5, Vadim Zeitlin wrote:
On Mon, 12 Nov 2018 14:00:44 -0800 (PST) KT wrote:

I don't know anything about this particular protocol, but usually the
"application-specificity" is achieved by either generating events or
calling virtual methods, which can be overridden at the application level,
from the protocol methods. Would this work here?

Virtual functions would be the way to go in that case. Whether they end up being in wxWindow in general or only the wxCocoa derivative is another matter. I wouldn't want to pollute wxWindow unnecessarily, but if the functions were general enough, it might be a useful way of future-proofing for other platforms/functionality as well.

(Basically what's needed is to be able to report back things like the current text selection, the onscreen position of the insertion point or selection, etc. — things a custom text control currently has no way of communicating.)

I'll keep that in mind. I have some other custom wxCocoa modifications that add missing functionality that I've been meaning to tidy up into a presentable form anyway.


--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users