SDL 1.3 Text editing

Hello guys,

I’m working on a multi-window GUI and now working on text input.

It works perfect but when I want to implement text editing events and character composition, I would like to display it as well. The problem is that corresponding event structure is missing windowID and I don’t know to what window the final text input goes…

Here for this event, windowID is not specified…

typedef struct SDL_TextEditingEvent
{
Uint32 type; /< ::SDL_TEXTEDITING */
char text[SDL_TEXTEDITINGEVENT_TEXT_SIZE]; /
< The editing text */
int start; /< The start cursor of selected editing text */
int length; /
< The length of selected editing text */
} SDL_TextEditingEvent;

And then when character is finally composed, I know the windowID:

typedef struct SDL_TextInputEvent
{
Uint32 type; /< ::SDL_TEXTINPUT */
Uint32 windowID; /
< The window with keyboard focus, if any */
Uint8 which; /< The keyboard device index */
Uint8 padding1;
Uint8 padding2;
Uint8 padding3;
char text[SDL_TEXTINPUTEVENT_TEXT_SIZE]; /
< The input text */
} SDL_TextInputEvent;

Could that be fixed or is it a limitation of some operating system??

I could hack some code and remember what was the last active window, but that’s not very safe probably.

Pavel

Hi Pavel,On Thu, Apr 15, 2010 at 3:41 AM, Pavel Kanzelsberger wrote:

I’m working on a multi-window GUI and now working on text input.

It works perfect but when I want to implement text editing events and character composition, I would like to display it as well. The problem is that corresponding event structure is missing windowID and I don’t know to what window the final text input goes…

Here for this event, windowID is not specified…

typedef struct SDL_TextEditingEvent
{
? ?Uint32 type; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/< ::SDL_TEXTEDITING */
? ?char text[SDL_TEXTEDITINGEVENT_TEXT_SIZE]; ?/
< The editing text */
? ?int start; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/< The start cursor of selected editing text */
? ?int length; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /
< The length of selected editing text */
} SDL_TextEditingEvent;

And then when character is finally composed, I know the windowID:

typedef struct SDL_TextInputEvent
{
? ?Uint32 type; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/< ::SDL_TEXTINPUT */
? ?Uint32 windowID; ? ? ? ? ? ? ? ? ? ? ? ? ?/
< The window with keyboard focus, if any */
? ?Uint8 which; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/< The keyboard device index */
? ?Uint8 padding1;
? ?Uint8 padding2;
? ?Uint8 padding3;
? ?char text[SDL_TEXTINPUTEVENT_TEXT_SIZE]; ?/
< The input text */
} SDL_TextInputEvent;

Could that be fixed or is it a limitation of some operating system??

I could hack some code and remember what was the last active window, but that’s not very safe probably.

Indeed, that can be fixed. Can you give me a sample code that how you
are going to use this API with multi-window? Even pseudo-code will
help me understand the situation better.

Currently the text input implementation is a bit broken for
multi-window since I only added a field edit to the front most window
on Cocoa_StartTextInput(). It can be solved once we switched to use
the field edit provided by NSWindow. I am working on it.

  • Jiang

Hello,

well code is quite complicated but I try to describe it better, if
that doesn’t help I could provide some easier pseudo-code.

Basically I need character composition only for korean, japanese and
chinese languages. Each glyph is composed from 2,3 or 4 characters.
All these characters are send through TextEditingEvent as
intermmediate character that is not finished yet, I need to display it
so user knows if the desired glyph is ok or not, that’s what other
programs do as well. When I get TextInputEvent I know I’ve got final
glyph and I move to another one…

The issue is that my application could have multiple windows and each
could have an editing control where input goes. Usually I don’t know
which window is currently active, so I process my events based on
windowID for each event. That’s why I’m missing a windowID for
TextEditingEvent as I don’t know where it should go…

I uploaded a screenshot from the GUI here:
http://img202.imageshack.us/img202/3267/picture1rg.png

You can see there could active focused edit control in any window and
when composing a glyph event should carry a windowID where this
occured, because user can simply switch between windows anytime
between TextInputEvents and it’s not very safe to hack this other way
without windowID in TextEditingEvent.

thanks,
PavelOn 15.4.2010, at 5:38, Jjgod Jiang wrote:

Hi Pavel,

On Thu, Apr 15, 2010 at 3:41 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

I’m working on a multi-window GUI and now working on text input.

It works perfect but when I want to implement text editing events
and character composition, I would like to display it as well. The
problem is that corresponding event structure is missing windowID
and I don’t know to what window the final text input goes…

Here for this event, windowID is not specified…

typedef struct SDL_TextEditingEvent
{
Uint32 type; /
< ::SDL_TEXTEDITING */
char text[SDL_TEXTEDITINGEVENT_TEXT_SIZE]; /
< The editing
text */
int start; /< The start
cursor of selected editing text */
int length; /
< The length of
selected editing text */
} SDL_TextEditingEvent;

And then when character is finally composed, I know the windowID:

typedef struct SDL_TextInputEvent
{
Uint32 type; /< ::SDL_TEXTINPUT */
Uint32 windowID; /
< The window with
keyboard focus, if any */
Uint8 which; /< The keyboard
device index */
Uint8 padding1;
Uint8 padding2;
Uint8 padding3;
char text[SDL_TEXTINPUTEVENT_TEXT_SIZE]; /
< The input text */
} SDL_TextInputEvent;

Could that be fixed or is it a limitation of some operating system??

I could hack some code and remember what was the last active
window, but that’s not very safe probably.

Indeed, that can be fixed. Can you give me a sample code that how you
are going to use this API with multi-window? Even pseudo-code will
help me understand the situation better.

Currently the text input implementation is a bit broken for
multi-window since I only added a field edit to the front most window
on Cocoa_StartTextInput(). It can be solved once we switched to use
the field edit provided by NSWindow. I am working on it.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Hello,

I’ve got another question. What encoding is used for text in these two
events? I handle it as if it was UTF-8 but I’m not really sure if
that’s the case… and sometimes I get CoreText crashes when I draw it
on screen as UTF-8.

PavelOn 15.4.2010, at 5:38, Jjgod Jiang wrote:

Hi Pavel,

On Thu, Apr 15, 2010 at 3:41 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

I’m working on a multi-window GUI and now working on text input.

It works perfect but when I want to implement text editing events
and character composition, I would like to display it as well. The
problem is that corresponding event structure is missing windowID
and I don’t know to what window the final text input goes…

Here for this event, windowID is not specified…

typedef struct SDL_TextEditingEvent
{
Uint32 type; /
< ::SDL_TEXTEDITING */
char text[SDL_TEXTEDITINGEVENT_TEXT_SIZE]; /
< The editing
text */
int start; /< The start
cursor of selected editing text */
int length; /
< The length of
selected editing text */
} SDL_TextEditingEvent;

And then when character is finally composed, I know the windowID:

typedef struct SDL_TextInputEvent
{
Uint32 type; /< ::SDL_TEXTINPUT */
Uint32 windowID; /
< The window with
keyboard focus, if any */
Uint8 which; /< The keyboard
device index */
Uint8 padding1;
Uint8 padding2;
Uint8 padding3;
char text[SDL_TEXTINPUTEVENT_TEXT_SIZE]; /
< The input text */
} SDL_TextInputEvent;

Could that be fixed or is it a limitation of some operating system??

I could hack some code and remember what was the last active
window, but that’s not very safe probably.

Indeed, that can be fixed. Can you give me a sample code that how you
are going to use this API with multi-window? Even pseudo-code will
help me understand the situation better.

Currently the text input implementation is a bit broken for
multi-window since I only added a field edit to the front most window
on Cocoa_StartTextInput(). It can be solved once we switched to use
the field edit provided by NSWindow. I am working on it.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Hi,On Thu, Apr 15, 2010 at 4:52 PM, Pavel Kanzelsberger wrote:

well code is quite complicated but I try to describe it better, if that
doesn’t help I could provide some easier pseudo-code.

Basically I need character composition only for korean, japanese and chinese
languages. Each glyph is composed from 2,3 or 4 characters. All these
characters are send through TextEditingEvent as intermmediate character that
is not finished yet, I need to display it so user knows if the desired glyph
is ok or not, that’s what other programs do as well. When I get
TextInputEvent I know I’ve got final glyph and I move to another one…

The issue is that my application could have multiple windows and each could
have an editing control where input goes. Usually I don’t know which window
is currently active, so I process my events based on windowID for each
event. That’s why I’m missing a windowID for TextEditingEvent as I don’t
know where it should go…

I uploaded a screenshot from the GUI here:
http://img202.imageshack.us/img202/3267/picture1rg.png

You can see there could active focused edit control in any window and when
composing a glyph event should carry a windowID where this occured, because
user can simply switch between windows anytime between TextInputEvents and
it’s not very safe to hack this other way without windowID in
TextEditingEvent.

Here is a patch to add windowID for text editing event (against latest SDL
from hg).

Basically you only need to run SDL_StartTextInput() once then the field
editor will be placed to the front most window automatically whenever you
switched to another window. So you can keep receiving SDL_TEXTINPUT and
SDL_TEXTEDITING events and check the source with event.{text,edit}.windowID.

I just tested it with a simple program, works fine for me.

Hi,On Thu, Apr 15, 2010 at 5:20 PM, Pavel Kanzelsberger wrote:

I’ve got another question. What encoding is used for text in these two
events? I handle it as if it was UTF-8 but I’m not really sure if that’s the
case… and sometimes I get CoreText crashes when I draw it on screen as
UTF-8.

Should always be UTF-8, both text from SDL_TEXTINPUT and SDL_TEXTEDITING
events.

How did you invoke your Core Text renderer? I suppose you already converted
them into CFStringRef or NSString with UTF-8 as character encoding?

  • Jiang

Hi,

ok so I should use SDL_StartTextInput only when I expect an input and
should do it separately for windows when user is switching between them?

Right now I have this function call only on startup and keep it until
the application quits.

Will you commit this patch to HG repository as well so when I update
it later it will be included? Anyway thank you very much for your
help, I’m going to test it right away.

PavelOn 15.4.2010, at 12:02, Jjgod Jiang wrote:

Hi,

On Thu, Apr 15, 2010 at 4:52 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

well code is quite complicated but I try to describe it better, if
that
doesn’t help I could provide some easier pseudo-code.

Basically I need character composition only for korean, japanese
and chinese
languages. Each glyph is composed from 2,3 or 4 characters. All these
characters are send through TextEditingEvent as intermmediate
character that
is not finished yet, I need to display it so user knows if the
desired glyph
is ok or not, that’s what other programs do as well. When I get
TextInputEvent I know I’ve got final glyph and I move to another
one…

The issue is that my application could have multiple windows and
each could
have an editing control where input goes. Usually I don’t know
which window
is currently active, so I process my events based on windowID for
each
event. That’s why I’m missing a windowID for TextEditingEvent as I
don’t
know where it should go…

I uploaded a screenshot from the GUI here:
http://img202.imageshack.us/img202/3267/picture1rg.png

You can see there could active focused edit control in any window
and when
composing a glyph event should carry a windowID where this occured,
because
user can simply switch between windows anytime between
TextInputEvents and
it’s not very safe to hack this other way without windowID in
TextEditingEvent.

Here is a patch to add windowID for text editing event (against
latest SDL
from hg).

Basically you only need to run SDL_StartTextInput() once then the
field
editor will be placed to the front most window automatically
whenever you
switched to another window. So you can keep receiving SDL_TEXTINPUT
and
SDL_TEXTEDITING events and check the source with event.
{text,edit}.windowID.

I just tested it with a simple program, works fine for me.


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Hi,

well CoreText is used only on Mac, for Linux and Windows I’m using
freetype, so my strings are kept as UTF-8 strings and then on display
they’re converted to CFStringRef from UTF8 C string. I’m not using
NSString since there’s no Cocoa involved in my code.

PavelOn 15.4.2010, at 12:06, Jjgod Jiang wrote:

Hi,

On Thu, Apr 15, 2010 at 5:20 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

I’ve got another question. What encoding is used for text in these
two
events? I handle it as if it was UTF-8 but I’m not really sure if
that’s the
case… and sometimes I get CoreText crashes when I draw it on
screen as
UTF-8.

Should always be UTF-8, both text from SDL_TEXTINPUT and
SDL_TEXTEDITING
events.

How did you invoke your Core Text renderer? I suppose you already
converted
them into CFStringRef or NSString with UTF-8 as character encoding?

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Hi,

Hi,

ok so I should use SDL_StartTextInput only when I expect an input and should
do it separately for windows when user is switching between them?

Right now I have this function call only on startup and keep it until the
application quits.

No need to call it separately, you can just call it once on startup.

Will you commit this patch to HG repository as well so when I update it
later it will be included? Anyway thank you very much for your help, I’m
going to test it right away.

Sure. If everything works fine, I will ask Sam to include it into HG repository.

  • JiangOn Thu, Apr 15, 2010 at 7:43 PM, Pavel Kanzelsberger wrote:

Hello Jiang,

just to let you know, your patch works really perfect, will keep this revision of SDL 1.3 until it appears in the repository and it seems you can push it to Sam right away.

If you’re interested in some short video of this feature in action, I can upload something :slight_smile:

PavelOn 15.4.2010, at 16:00, Jjgod Jiang wrote:

Hi,

On Thu, Apr 15, 2010 at 7:43 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger> wrote:

Hi,

ok so I should use SDL_StartTextInput only when I expect an input and should
do it separately for windows when user is switching between them?

Right now I have this function call only on startup and keep it until the
application quits.

No need to call it separately, you can just call it once on startup.

Will you commit this patch to HG repository as well so when I update it
later it will be included? Anyway thank you very much for your help, I’m
going to test it right away.

Sure. If everything works fine, I will ask Sam to include it into HG repository.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello there,

I was just checking some Chinese input methods and some of them will pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my edit control is placed. On Mac however this seems to not take care of Window decorations so it’s misplaced in final. Currently I need to offset it by 1 pixel to the right and approx. 19 pixels down to get in right position (not covering my edit control). Could you have a look if there’s really problem not taking care of Cocoa window decorations?

I think I understand it correctly because in other programs it’s displayed correctly below edit control.

PavelOn 15.4.2010, at 16:00, Jjgod Jiang wrote:

Hi,

On Thu, Apr 15, 2010 at 7:43 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger> wrote:

Hi,

ok so I should use SDL_StartTextInput only when I expect an input and should
do it separately for windows when user is switching between them?

Right now I have this function call only on startup and keep it until the
application quits.

No need to call it separately, you can just call it once on startup.

Will you commit this patch to HG repository as well so when I update it
later it will be included? Anyway thank you very much for your help, I’m
going to test it right away.

Sure. If everything works fine, I will ask Sam to include it into HG repository.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi Pavel,On Fri, Apr 16, 2010 at 3:34 AM, Pavel Kanzelsberger wrote:

I was just checking some Chinese input methods and some of them will pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my edit control is placed. On Mac however this seems to not take care of Window decorations so it’s misplaced in final. Currently I need to offset it by 1 pixel to the right and approx. 19 pixels down to get in right position (not covering my edit control). Could you have a look if there’s really problem not taking care of Cocoa window decorations?

I think I understand it correctly because in other programs it’s displayed correctly below edit control.

You are right, that’s a bug. Please try attached patch to see if it
works for you.

Wow, I’m loving this workflow…

hg import Jiang’s patch
edit, commit locally
hg import Jiang’s next patch
hg push

Complete changes, full history.

Woot! :)On Thu, Apr 15, 2010 at 10:23 PM, Jjgod Jiang wrote:

Hi Pavel,

On Fri, Apr 16, 2010 at 3:34 AM, Pavel Kanzelsberger wrote:

I was just checking some Chinese input methods and some of them will pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my edit control is placed. On Mac however this seems to not take care of Window decorations so it’s misplaced in final. Currently I need to offset it by 1 pixel to the right and approx. 19 pixels down to get in right position (not covering my edit control). Could you have a look if there’s really problem not taking care of Cocoa window decorations?

I think I understand it correctly because in other programs it’s displayed correctly below edit control.

You are right, that’s a bug. Please try attached patch to see if it
works for you.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Hello Jiang,

thank you very much for your patch I verified on 10.5 Leopard 32bit
and 10.6 Snow Leopard 64bit and patch works perfect!! Another
candidate for repository commit :wink:

Here’s a screenshot:
http://img714.imageshack.us/img714/2233/picture1qyv.png

PavelOn 16.4.2010, at 7:23, Jjgod Jiang wrote:

Hi Pavel,

On Fri, Apr 16, 2010 at 3:34 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

I was just checking some Chinese input methods and some of them
will pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my
edit control is placed. On Mac however this seems to not take care
of Window decorations so it’s misplaced in final. Currently I need
to offset it by 1 pixel to the right and approx. 19 pixels down to
get in right position (not covering my edit control). Could you
have a look if there’s really problem not taking care of Cocoa
window decorations?

I think I understand it correctly because in other programs it’s
displayed correctly below edit control.

You are right, that’s a bug. Please try attached patch to see if it
works for you.


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Hello Sam,

yeah I like this as well, that’s pretty fast :slight_smile:

You can import the 2nd patch as well, I fully tested on both 10.5
Leopard and 10.6 Snow Leopard in 32bits and 64bits as well and it
works perfect.

PavelOn 16.4.2010, at 7:29, Sam Lantinga wrote:

Wow, I’m loving this workflow…

hg import Jiang’s patch
edit, commit locally
hg import Jiang’s next patch
hg push

Complete changes, full history.

Woot! :slight_smile:

On Thu, Apr 15, 2010 at 10:23 PM, Jjgod Jiang wrote:

Hi Pavel,

On Fri, Apr 16, 2010 at 3:34 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger wrote:

I was just checking some Chinese input methods and some of them
will pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my
edit control is placed. On Mac however this seems to not take care
of Window decorations so it’s misplaced in final. Currently I need
to offset it by 1 pixel to the right and approx. 19 pixels down to
get in right position (not covering my edit control). Could you
have a look if there’s really problem not taking care of Cocoa
window decorations?

I think I understand it correctly because in other programs it’s
displayed correctly below edit control.

You are right, that’s a bug. Please try attached patch to see if it
works for you.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pavel Kanzelsberger


E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633

Yup, it’s in, thanks!On Fri, Apr 16, 2010 at 4:48 AM, Pavel Kanzelsberger wrote:

Hello Sam,

yeah I like this as well, that’s pretty fast :slight_smile:

You can import the 2nd patch as well, I fully tested on both 10.5 Leopard
and 10.6 Snow Leopard in 32bits and 64bits as well and it works perfect.

Pavel

On 16.4.2010, at 7:29, Sam Lantinga wrote:

Wow, I’m loving this workflow…

hg import Jiang’s patch
edit, commit locally
hg import Jiang’s next patch
hg push

Complete changes, full history.

Woot! :slight_smile:

On Thu, Apr 15, 2010 at 10:23 PM, Jjgod Jiang wrote:

Hi Pavel,

On Fri, Apr 16, 2010 at 3:34 AM, Pavel Kanzelsberger wrote:

I was just checking some Chinese input methods and some of them will
pop-up some suggestion palette with glyphs you can choose from.

I’m using SDL_SetTextInputRect() to acknowledge the OS where my edit
control is placed. On Mac however this seems to not take care of Window
decorations so it’s misplaced in final. Currently I need to offset it by 1
pixel to the right and approx. 19 pixels down to get in right position (not
covering my edit control). Could you have a look if there’s really problem
not taking care of Cocoa window decorations?

I think I understand it correctly because in other programs it’s
displayed correctly below edit control.

You are right, that’s a bug. Please try attached patch to see if it
works for you.

  • Jiang

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Pavel Kanzelsberger
http://www.kanzelsberger.com
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC