The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
SDL_StartTextInput WinRT
asdron


Joined: 05 Nov 2014
Posts: 13
Is this feature available in SDL for winrt projects? I'm trying use it, but nothing happened. Seems, that "_this->StartTextInput" in "void SDL_StartTextInput(void)" is NULL. How can I use this for my game on win8.1/wp8.1?
asdron


Joined: 05 Nov 2014
Posts: 13
I have found, that can use SDL_KEYUP event. But there is another question: how can I handle with different languages?
DLudwig


Joined: 09 Feb 2012
Posts: 179
Support for StartTextInput in WinRT is still pending. I can plan on trying to take a closer look at implementing SDL_TEXTINPUT event support within the next few weeks. Alternatively, if you'd like to submit a patch to add support for such, this could expedite things substantially (and be much appreciated!)

One technical note regarding user input: it may be a while, and potentially impossible, to add programmatic show/hide on-screen keyboard support in WinRT, for the time being. For one, my understanding is that on-screen keyboards in WinRT require XAML, support for which is being worked on (for SDL), but is apt to take a while to get working well + reasonably stable (beyond some fairly experimental XAML code that's in-place now). Second, my understanding is that Microsoft has taken steps to prevent on-screen keyboards from being shown programmatically. MSDN has an article at http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx with more details (see the section titled, "User-driven invocation", which is currently near the bottom of the page.) There may be a workaround to this, or they may have changed policy since, but it doesn't look promising, IMO.

Cheers,
-- David L.
SDL_StartTextInput WinRT
Sik


Joined: 26 Nov 2011
Posts: 905
2014-11-25 11:48 GMT-03:00, DLudwig:
Quote:
One technical note regarding user input: it may be a while, and potentially
impossible, to add programmatic show/hide on-screen keyboard support in
WinRT, for the time being. For one, my understanding is that on-screen
keyboards in WinRT require XAML, support for which is being worked on (for
SDL), but is apt to take a while to get working well + reasonably stable
(beyond some fairly experimental XAML code that's in-place now). Second, my
understanding is that Microsoft has taken steps to prevent on-screen
keyboards from being shown programmatically. MSDN has an article at
http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx with more
details (see the section titled, "User-driven invocation", which is
currently near the bottom of the page.) There may be a workaround to this,
or they may have changed policy since, but it doesn't look promising, IMO.

It seems like SDL_StartTextInput and SDL_StopTextInput should be
enough to handle the keyboard in those cases (once implemented).
Except for the part that apparently this here relies on UI controls
(which SDL doesn't use), and you can't pop-up the keyboard by giving
focus to a spurious control...

It sounds like they expect every WinRT program to use UI controls no
matter the situation (you already need to do something like this on
iOS if you want VoiceOver to work as-is, if I recall correctly, so
this isn't exactly a new problem either).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_StartTextInput WinRT
Jared Maddox
Guest

Quote:
Date: Tue, 25 Nov 2014 14:48:41 +0000
From: "DLudwig"
To:
Subject: Re: [SDL] SDL_StartTextInput WinRT
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"


Quote:
Second, my understanding is that Microsoft has taken steps to prevent
on-screen keyboards from being shown programmatically. MSDN has an article
at http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx with
more details (see the section titled, "User-driven invocation", which is
currently near the bottom of the page.) There may be a workaround to this,
or they may have changed policy since, but it doesn't look promising, IMO.


From reading the first little bit of it, I suspect that the smartest
possible path is to call SDL_SetTextInputRect() when you first display
a text window, instead of waiting for the user to do something that
tells you they're ready for it. I can see this outgrowing the current
interface very quickly, very easily. You might have to get Sam & Ryan
to approve some sort of SDL_TextControl structure and functions to use
it, depending on the details.


Quote:
Date: Tue, 25 Nov 2014 12:02:26 -0300
From: Sik the hedgehog
To:
Subject: Re: [SDL] SDL_StartTextInput WinRT
Message-ID:

Content-Type: text/plain; charset=UTF-8


Quote:
It sounds like they expect every WinRT program to use UI controls no
matter the situation (you already need to do something like this on
iOS if you want VoiceOver to work as-is, if I recall correctly, so
this isn't exactly a new problem either).


Fortunately it sounds like they're at least tolerant of custom-drawn
UI widgets, so it's not as bad as it could be. Imagine a new release
of Winamp being required to use Microsoft look-and-feel for the
library's search box.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_StartTextInput WinRT
Sik


Joined: 26 Nov 2011
Posts: 905
2014-11-26 6:27 GMT-03:00, Jared Maddox:
Quote:
Fortunately it sounds like they're at least tolerant of custom-drawn
UI widgets, so it's not as bad as it could be. Imagine a new release
of Winamp being required to use Microsoft look-and-feel for the
library's search box.

Well yeah, they expect every program in WinRT to have its own
look-and-feel after all, so that isn't the issue Razz The problem is
that SDL programs don't even use the system's UI controls in the first
place, built-in or custom (they implement their own interface
instead).

Mind you, maybe having UI support within SDL itself could be pretty
useful. I had to recreate nearly all of the GUI look-and-feel behavior
for the level editor in Sol, it could have been really useful if SDL
allowed me to place invisible UI objects (that I'd draw on top of) and
then let me retrieve their current status, then the OS itself would
take care of handling them and I'd only need to bother with drawing.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_StartTextInput WinRT
Jared Maddox
Guest

Quote:
Date: Wed, 26 Nov 2014 06:42:00 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] SDL_StartTextInput WinRT
Message-ID:

Content-Type: text/plain; charset=UTF-8

2014-11-26 6:27 GMT-03:00, Jared Maddox:
Quote:
Fortunately it sounds like they're at least tolerant of custom-drawn
UI widgets, so it's not as bad as it could be. Imagine a new release
of Winamp being required to use Microsoft look-and-feel for the
library's search box.

Well yeah, they expect every program in WinRT to have its own
look-and-feel after all, so that isn't the issue Razz

Seriously? I thought they wanted to move people to a unified
look-and-feel so that apps seemed more "integrated" to WinRT.

Though admittedly I can see how they would consider this a no-go for games.


Quote:
The problem is
that SDL programs don't even use the system's UI controls in the first
place, built-in or custom (they implement their own interface
instead).

Mind you, maybe having UI support within SDL itself could be pretty
useful. I had to recreate nearly all of the GUI look-and-feel behavior
for the level editor in Sol, it could have been really useful if SDL
allowed me to place invisible UI objects (that I'd draw on top of) and
then let me retrieve their current status, then the OS itself would
take care of handling them and I'd only need to bother with drawing.


Yeah, I suspect that at least for the text input that's what Ludwig
will have to implement.

What was the other UI support that you wanted, though? I can't think
of any other UI components that would be likely to BELONG in SDL
itself, but if there was something else you were wanting then listing
it now would increase the chances of enough HOOKS being added to allow
a widget library to (at least somewhat) transparently provide them.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
DLudwig


Joined: 09 Feb 2012
Posts: 179
Ok, I just added some basic, initial support for SDL_TEXTINPUT events in SDL/WinRT (via https://hg.libsdl.org/SDL/rev/dc4ad21d8596 ). The change translates text-input events that WinRT was already making available (CoreWindow.CharacterReceived, for those interested), into SDL_TEXTINPUT events. It doesn't do anything to help out SDL_StartTextInput though, such as enabling an IME, or showing an on-screen keyboard.

There is a chance that showing/hiding an on-screen keyboard might be possible without text control trickery, although I'm not sure of this. There's some talk regarding IMEs and 'soft' keyboards at https://social.msdn.microsoft.com/Forums/windowsapps/en-US/7a8e92dc-d2b9-4b46-b71c-f5366e82ddbf/how-to-use-corewindowcharacterreceived?forum=winappswithnativecode , which might also allude to being able to programmatically show or hide any on-screen keyboard, but I'm not sure of this. In all honesty, it's a bit out of my field of knowledge. I'll try taking a look at it at some point, but I might not be able to get to it for a while, and make no guarantees as to its success. In the meantime, patches welcomed. :-)

Cheers,
-- David L.
SDL_StartTextInput WinRT
Sik


Joined: 26 Nov 2011
Posts: 905
2014-11-26 20:48 GMT-03:00, Jared Maddox:
Quote:
Seriously? I thought they wanted to move people to a unified
look-and-feel so that apps seemed more "integrated" to WinRT.

Well, given they encourage the use of CSS to style the individual apps...

Quote:
What was the other UI support that you wanted, though? I can't think
of any other UI components that would be likely to BELONG in SDL
itself, but if there was something else you were wanting then listing
it now would increase the chances of enough HOOKS being added to allow
a widget library to (at least somewhat) transparently provide them.

Just look at these screenshots to get an idea:
http://i.imgur.com/Gl8xBMK.png
http://i.imgur.com/eiqKT6L.png
http://i.imgur.com/9CEeRk5.png

The easiest way would have been to place normal UI controls and then
draw over them. However, SDL doesn't have this, and UI toolkits don't
let you do that either (and the few that are game-oriented still
expect to render by themselves, ugh), so the only other option is to
implement it myself.

Note, that I know that on Windows I could probably just subclass the
controls (overriding only their drawing event) and slap them on top of
the game window, but 1) that's platform specific and 2) Linux doesn't
have any reasonable equivalent to that...
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_StartTextInput WinRT
Eric Wing
Guest

On 11/27/14, Sik the hedgehog wrote:
Quote:
2014-11-26 20:48 GMT-03:00, Jared Maddox:
Quote:
Seriously? I thought they wanted to move people to a unified
look-and-feel so that apps seemed more "integrated" to WinRT.

Well, given they encourage the use of CSS to style the individual apps...

Quote:
What was the other UI support that you wanted, though? I can't think
of any other UI components that would be likely to BELONG in SDL
itself, but if there was something else you were wanting then listing
it now would increase the chances of enough HOOKS being added to allow
a widget library to (at least somewhat) transparently provide them.

Just look at these screenshots to get an idea:
http://i.imgur.com/Gl8xBMK.png
http://i.imgur.com/eiqKT6L.png
http://i.imgur.com/9CEeRk5.png

The easiest way would have been to place normal UI controls and then
draw over them. However, SDL doesn't have this, and UI toolkits don't
let you do that either (and the few that are game-oriented still
expect to render by themselves, ugh), so the only other option is to
implement it myself.

Note, that I know that on Windows I could probably just subclass the
controls (overriding only their drawing event) and slap them on top of
the game window, but 1) that's platform specific and 2) Linux doesn't
have any reasonable equivalent to that...

Native UI is an area that is important to me (long term) and one of
the primary reasons in the past I've been forced out of the SDL
universe. This is something I would like to fix (as much as reasonably
possible). There is another thread from months back where I think Ryan
was starting to add hooks into SDL for integration related to this.
I've been meaning to chime in...maybe this holiday weekend I'll
finally get around to it.

Throwing native controls on top of a hardware accelerated surface is
possible on other platforms and has become extremely important in the
mobile space. It is also useful in other domains like scientific
visualization, though it is becoming more useful for games to
platforms and libraries that automatically want to invoke a pre-made
(native) GUI for you, such as Apple Game Center, or you can imagine a
plugin for something like Twitter or Facebook.

Anyway, being able to do this:
- OS X added this ability with Core Animation (CALayers and
Layer-backed views) in 10.5. However, it is also been historically
buggy as heck and thus you really need up-to-date OpenGL drivers. This
is where clinging to backwards compatibility in the Mac universe will
get you killed. 10.8 is where it started becoming usable in my
opinion, but still benefits from the latest drivers. WebView is the
most painful native widget and still isn't guaranteed to work.

- iOS had this feature from the start. It is built also on Core
Animation, but they built iOS on Core Animation from the start so it
doesn't have OS X's problems, nor it's dual view nature (i.e. no need
for layer backed views).

- Android also has this ability. It got strikingly better in Android
4.0 with "Project Butter" where they finally hardware accelerated
their surfaces so there was less impedance mismatch. WebView and I
think MapView have given me the most problems though.

- I know somebody doing this with Windows Phone. I don't know all the
details. I think it involves XAML and Silverlight. I heard something
about there is a bug that their event loop which is too slow to call
you back when opting into this mode which slows down your game frame
rate.

- I don't know about the normal Windows desktop. I'm kind of expecting
is possible starting from Vista due to the compositing architecture.
Based on your response in this thread, I'm guessing this is possible.

- No idea about Linux desktops and compositing managers. I'm kind of
expecting the more modern ones to support this, but few who actually
know about it or how to do it.


While I'm indifferent to whether SDL directly adds support to this, I
do want SDL to provide the hooks so we can do this kind of stuff when
the platform allows it. The rest of us can pull our resources and
figure out what is and isn't possible on the different platforms and
build satellite libraries or whatever.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
asdron


Joined: 05 Nov 2014
Posts: 13
Wow, thanks for replies guys!
DLudwig wrote:
The change translates text-input events that WinRT was already making available (CoreWindow.CharacterReceived, for those interested)

I have implemented and tested this method too, everything was good, but there was a problem with showing keyboard as you said. I have found this article http://msdn.microsoft.com/en-us/library/windows/apps/jj247546(v=vs.105).aspx, but it looks a bit outdated and not applicable for windows 8.1 store apps. I also spent some time for reading documentation of "UI Automation Control Patterns" (From this post http://stackoverflow.com/questions/26649044/usage-of-software-input-panel-in-directx-based-app).
But finally I decided to switch to Direct3d+XAML project. My game is integrated with facebook, so I have no choice. Since, I'm using ANGLE library, I created new project from their template and I'm not using SDL_window. I don't have enough time now to patch SDL, so I just used window initialization from ANGLE and created own touch handlers, that translate touch events to SDL. But I ran into problems too Smile. Firstly I tried to create textbox control, focus it to show keyboard and then translate input text to my ingame textinput (I used this trick on android and ios before). Everything was fine except one thing. If you hide keyboard manually ("hide keyboard" option in keyboard menu or smth either), than next time setting focus to textbox won't invoke keyboard. But if you hide keyboard programmatically - everything works fine. I don't know where is the problem. So, after googling a while I decided to show native input text box with xaml and hide it after user ends text input. So he can always invoke keyboard (automatically or manually by tapping textbox).
Meldryt


Joined: 22 Oct 2014
Posts: 36
Location: Munich
Thanks to Microsoft, looks like porting games to windows phone via SDL isnt a good idea (yet), especially for network games -,-
Anyways, you guys are doing a great job.
So i have to implement an onscreen keyboard manually.
Something like draw a keyboard texture and check if one of the rects is hit.