2.0.4 bug wrap

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by forcing
OpenGL in my project, which leaves a portion of the Windows market out of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset and
build my own version of the library now - but I need some guidance from you
devs to format a proper patch (if this doesn’t fall completely out of the
scope of SDL).On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:


Trygve Vea

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardiOn Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by forcing
OpenGL in my project, which leaves a portion of the Windows market out of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset and
build my own version of the library now - but I need some guidance from you
devs to format a proper patch (if this doesn’t fall completely out of the
scope of SDL).


Trygve Vea


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

I can have a look at this bug since I got a Samsung S3 from a colleagueOn Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by forcing
OpenGL in my project, which leaves a portion of the Windows market out of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset and
build my own version of the library now - but I need some guidance from you
devs to format a proper patch (if this doesn’t fall completely out of the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker

Trying to ./configure it (running on Ubuntu), I get this:

Using ibus : NO

I don’t recall ibus being mentioned at all before, so I guess it’s a
recent addition. Whatever, what do I need to install in order for ibus
to work? I’m definitely interested on testing ibus support (I have
Anthy installed).

2014-07-16 13:37 GMT-03:00, Sylvain Becker <sylvain.becker at gmail.com>:> I can have a look at this bug since I got a Samsung S3 from a colleague

On Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some
devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like
addressed,
please reply to this thread with a link to a bug report. If there isn’t
a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by
forcing
OpenGL in my project, which leaves a portion of the Windows market out
of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset
and
build my own version of the library now - but I need some guidance from
you
devs to format a proper patch (if this doesn’t fall completely out of
the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker


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

Hi,

You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).

I’d be interested to know if It works well for you. I have only tested
it thoroughly with ibus-mozc.

AlexOn 16/07/14 18:45, Sik the hedgehog wrote:

Trying to ./configure it (running on Ubuntu), I get this:

Using ibus : NO

I don’t recall ibus being mentioned at all before, so I guess it’s a
recent addition. Whatever, what do I need to install in order for ibus
to work? I’m definitely interested on testing ibus support (I have
Anthy installed).

2014-07-16 13:37 GMT-03:00, Sylvain Becker <sylvain.becker at gmail.com>:

I can have a look at this bug since I got a Samsung S3 from a colleague

On Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some
devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like
addressed,
please reply to this thread with a link to a bug report. If there isn’t
a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by
forcing
OpenGL in my project, which leaves a portion of the Windows market out
of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset
and
build my own version of the library now - but I need some guidance from
you
devs to format a proper patch (if this doesn’t fall completely out of
the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker


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


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

OK, libibus-1.0-dev was it (I couldn’t figure out the name XD)

Well, it works… sorta. I’m pretty much blind typing since I can’t
see the candidate list. I’m probably missing something though, since I
was completely unable to debug this before (due to SDL not supporting
IME input on Linux). What coordinates should be passed to
SDL_SetTextInputRect? I have the coordinates of the cursor.

2014-07-16 15:53 GMT-03:00, Alex Baines :> Hi,

You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).

I’d be interested to know if It works well for you. I have only tested
it thoroughly with ibus-mozc.

Alex

On 16/07/14 18:45, Sik the hedgehog wrote:

Trying to ./configure it (running on Ubuntu), I get this:

Using ibus : NO

I don’t recall ibus being mentioned at all before, so I guess it’s a
recent addition. Whatever, what do I need to install in order for ibus
to work? I’m definitely interested on testing ibus support (I have
Anthy installed).

2014-07-16 13:37 GMT-03:00, Sylvain Becker <sylvain.becker at gmail.com>:

I can have a look at this bug since I got a Samsung S3 from a colleague

On Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some
devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like
addressed,
please reply to this thread with a link to a bug report. If there
isn’t
a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by
forcing
OpenGL in my project, which leaves a portion of the Windows market out
of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset
and
build my own version of the library now - but I need some guidance
from
you
devs to format a proper patch (if this doesn’t fall completely out of
the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker


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


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


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

The candidate list should appear at 0,0 of the window by default, not
sure why it isn’t appearing for you.

SDL_SetTextInputRect takes coordinates relative to the window too, so
0,0 is top left. When the window is moved, the list should be
automatically moved.On 16/07/14 20:42, Sik the hedgehog wrote:

OK, libibus-1.0-dev was it (I couldn’t figure out the name XD)

Well, it works… sorta. I’m pretty much blind typing since I can’t
see the candidate list. I’m probably missing something though, since I
was completely unable to debug this before (due to SDL not supporting
IME input on Linux). What coordinates should be passed to
SDL_SetTextInputRect? I have the coordinates of the cursor.

2014-07-16 15:53 GMT-03:00, Alex Baines <@Alex_Baines>:

Hi,

You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).

I’d be interested to know if It works well for you. I have only tested
it thoroughly with ibus-mozc.

Alex

On 16/07/14 18:45, Sik the hedgehog wrote:

Trying to ./configure it (running on Ubuntu), I get this:

Using ibus : NO

I don’t recall ibus being mentioned at all before, so I guess it’s a
recent addition. Whatever, what do I need to install in order for ibus
to work? I’m definitely interested on testing ibus support (I have
Anthy installed).

2014-07-16 13:37 GMT-03:00, Sylvain Becker <sylvain.becker at gmail.com>:

I can have a look at this bug since I got a Samsung S3 from a colleague

On Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some
devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like
addressed,
please reply to this thread with a link to a bug report. If there
isn’t
a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by
forcing
OpenGL in my project, which leaves a portion of the Windows market out
of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset
and
build my own version of the library now - but I need some guidance
from
you
devs to format a proper patch (if this doesn’t fall completely out of
the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker


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


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


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


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

I have taken a look at the Anthy IM and I think I know what’s going on now.

The SDL ibus code tells IBus it has IBUS_CAP_PREEDIT_TEXT in order to
get events about the text as it is being edited. These get translated
into SDL’s TextEditingEvents.

However, using IBUS_CAP_PREEDIT_TEXT means that Ibus expects the
application to render the text as it is being edited, so for Anthy (and
probably other IMs) it doesn’t display a candidate list until you press
space to complete the editing and then press down to choose a
non-default selection.

This would work fine if the application interprets all the
TextEditingEvents and renders it somehow.

If IBUS_CAP_PREEDIT text is not passed, then Ibus with Anthy will render
the text in it’s own candidate list UI - BUT it will not give out any
pre-edit text events, so SDL won’t be able to send any TextEditingEvents.

Ibus-mozc seemingly always shows its candidate list.

So there are two possibilities that the SDL IBus code could do:

  1. CAP_PREEDIT_TEXT (current)

    • SDL sends TextEditingEvents
    • User is expected to render the text as it is being edited.
  2. No CAP_PREEDIT_TEXT

    • SDL won’t send any TextEditingEvents, only TextInput.
    • IBus renders the text as it is being edited.

There isn’t currently a way to let SDL know if you want to render the
text or not with SDL_StartTextInput, so I guess one would have to be
chosen at compile time.On 16/07/14 21:24, Alex Baines wrote:

The candidate list should appear at 0,0 of the window by default, not
sure why it isn’t appearing for you.

SDL_SetTextInputRect takes coordinates relative to the window too, so
0,0 is top left. When the window is moved, the list should be
automatically moved.

On 16/07/14 20:42, Sik the hedgehog wrote:

OK, libibus-1.0-dev was it (I couldn’t figure out the name XD)

Well, it works… sorta. I’m pretty much blind typing since I can’t
see the candidate list. I’m probably missing something though, since I
was completely unable to debug this before (due to SDL not supporting
IME input on Linux). What coordinates should be passed to
SDL_SetTextInputRect? I have the coordinates of the cursor.

2014-07-16 15:53 GMT-03:00, Alex Baines <@Alex_Baines>:

Hi,

You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).

I’d be interested to know if It works well for you. I have only tested
it thoroughly with ibus-mozc.

Alex

On 16/07/14 18:45, Sik the hedgehog wrote:

Trying to ./configure it (running on Ubuntu), I get this:

Using ibus : NO

I don’t recall ibus being mentioned at all before, so I guess it’s a
recent addition. Whatever, what do I need to install in order for ibus
to work? I’m definitely interested on testing ibus support (I have
Anthy installed).

2014-07-16 13:37 GMT-03:00, Sylvain Becker <sylvain.becker at gmail.com>:

I can have a look at this bug since I got a Samsung S3 from a colleague

On Wed, Jul 16, 2014 at 2:38 PM, Ardillas del Monte wrote:

I’d like that 2.0.4 addresses bug#2291 (Android: Red screen on some
devices)
https://bugzilla.libsdl.org/show_bug.cgi?id=2291

Yes, the bug isn’t closed yet, but I’d like 2.0.4 to be rock-solid at
choosing visuals with depth buffer on Android (all my apps need depth
buffer)

ardi

On Tue, Jul 15, 2014 at 7:08 PM, Trygve Vea <trygve.vea at gmail.com> wrote:

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like
addressed,
please reply to this thread with a link to a bug report. If there
isn’t
a
patch already hopefully the community will jump on and take a look.

Awesome to hear about 2.0.4.

I work around https://bugzilla.libsdl.org/show_bug.cgi?id=2421 by
forcing
OpenGL in my project, which leaves a portion of the Windows market out
of
being able to run my project (http://i.imgur.com/Ilfr3TG.png).

I’m also interested in merging in 2594, as I maintain a local patchset
and
build my own version of the library now - but I need some guidance
from
you
devs to format a proper patch (if this doesn’t fall completely out of
the
scope of SDL).


Trygve Vea


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


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


Sylvain Becker


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


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


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


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


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

2014-07-16 17:24 GMT-03:00, Alex Baines :

SDL_SetTextInputRect takes coordinates relative to the window too, so
0,0 is top left. When the window is moved, the list should be
automatically moved.

Wait, just realized… Are only the top-left coordinates of the
rectangle used? I always got confused about this function because I
just assumed all four coordinates were used.

2014-07-16 17:48 GMT-03:00, Alex Baines :

However, using IBUS_CAP_PREEDIT_TEXT means that Ibus expects the
application to render the text as it is being edited, so for Anthy (and
probably other IMs) it doesn’t display a candidate list until you press
space to complete the editing and then press down to choose a
non-default selection.

Yep, I figured out this one. The problem is that even if I press space
the candidate list will not show up in any form, forcing me to
blindly choose a kanji from memory.

I asked about SDL_SetTextInputRect because I’m not even sure if I’m
calling it, since after all the code is incomplete because I wasn’t
able to test it (there’s barely enough to receive text input).

If IBUS_CAP_PREEDIT text is not passed, then Ibus with Anthy will render
the text in it’s own candidate list UI - BUT it will not give out any
pre-edit text events, so SDL won’t be able to send any TextEditingEvents.

The implication here seems to be that the program should be required
to render both the placeholder text and the candidate list. SDL
never gives the candidate list to the program (nor which option is
currently selected), so it’s impossible to do this properly in
practice.

Wait, just realized… Are only the top-left coordinates of the
rectangle used? I always got confused about this function because I
just assumed all four coordinates were used.

All four coords are sent to ibus, I’m not sure how it uses the width and
height though.

Yep, I figured out this one. The problem is that even if I press space
the candidate list will not show up in any form, forcing me to
blindly choose a kanji from memory.

After you press space, try pressing the down arrow, does the candidate
list not appear then either?

If IBUS_CAP_PREEDIT text is not passed, then Ibus with Anthy will render
the text in it’s own candidate list UI - BUT it will not give out any
pre-edit text events, so SDL won’t be able to send any TextEditingEvents.

The implication here seems to be that the program should be required
to render both the placeholder text and the candidate list. SDL
never gives the candidate list to the program (nor which option is
currently selected), so it’s impossible to do this properly in
practice.

No, the application never has to render the candidate list, only the
placeholder text that is being edited.

I’m not very familiar with Anthy but in my limited testing it didn’t
seem to open a candidate list in any application (i.e. firefox, gedit)
unless I pressed the down arrow after pressing the space bar to choose a
different option.> _______________________________________________

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

2014-07-16 19:10 GMT-03:00, Alex Baines :

All four coords are sent to ibus, I’m not sure how it uses the width and
height though.

I looked it up, wondering if this is the correct function:
http://ibus.googlecode.com/svn/docs/ibus-1.5/IBusEngine.html#IBusEngine-set-cursor-location

x : X coordinate of the cursor.
y : Y coordinate of the cursor.
w : Width of the cursor.
h : Height of the cursor.

OK, no idea how is that any better than the non-description of
SDL_SetTextInputRect… Maybe I should look up what it does on Windows
to get an idea of what it’s supposed to do.

I tried bruteforcing by doing this, since I assumed that maybe the
rectangle is 0?0 and so the candidate list may have been the same
size:

     SDL_Rect rect;
     rect.x = 10;
     rect.y = 10;
     rect.w = 100;
     rect.h = 300;
     SDL_SetTextInputRect(&rect);

Alas, that did nothing :confused:

After you press space, try pressing the down arrow, does the candidate
list not appear then either?

Nope, regardless of whether I press ?, ? or space, even multiple
times. The candidate list is definitely working though because I can
change the kanji, it’s just invisible.

No, the application never has to render the candidate list, only the
placeholder text that is being edited.

Oh OK, good to know.

I’m not very familiar with Anthy but in my limited testing it didn’t
seem to open a candidate list in any application (i.e. firefox, gedit)
unless I pressed the down arrow after pressing the space bar to choose a
different option.

I use Anthy all the time (I talk to Japanese people), so I know
perfectly how it works :stuck_out_tongue: (the first space press selects the first
kanji, further presses or the arrow keys make the candidate list
appear to choose another kanji)

I should feel bad for not trying this before (ignore the lack of
placeholder text, I didn’t get around implementing that in my game yet

OK, so the candidate list does appear, but only in windowed mode (it
doesn’t appear in fullscreen mode, and yes, it’s
SDL_WINDOW_FULLSCREEN_DESKTOP). I guess that the game window being on
top is hiding the candidate list. Whoops.

Also ignore the order of the kanji, that’s because I was blind typing
before so the prefered order got messed up :stuck_out_tongue:

I’m glad the candidate list did appear after all, but I’m not sure if
anything can be done from the SDL side to make it work with fullscreen.

FWIW the list appears above FULLSCREEN_DESKTOP windows for me.

Regarding the IBUS_CAP_PREEDIT_TEXT thing, I was thinking it might be
better to forget about the SDL_TextEditingEvents altogether and just let
ibus handle it all.

The only real downside to this is that you can’t render the
edit-in-progress text in a pretty font at a certain size.

The upside is you remove the need for every single SDL programmer to
handle the editing events themselves if they want ibus to work. It will
just magically work with any app that handles the standard TextInput events.

I would like other people’s opinions on which SDL should do.

Thanks, Alex.On 17/07/14 06:28, Sik the hedgehog wrote:

I should feel bad for not trying this before (ignore the lack of
placeholder text, I didn’t get around implementing that in my game yet

OK, so the candidate list does appear, but only in windowed mode (it
doesn’t appear in fullscreen mode, and yes, it’s
SDL_WINDOW_FULLSCREEN_DESKTOP). I guess that the game window being on
top is hiding the candidate list. Whoops.

Also ignore the order of the kanji, that’s because I was blind typing
before so the prefered order got messed up :stuck_out_tongue:


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

2014-07-17 12:09 GMT-03:00, Alex Baines :

I’m glad the candidate list did appear after all, but I’m not sure if
anything can be done from the SDL side to make it work with fullscreen.

FWIW the list appears above FULLSCREEN_DESKTOP windows for me.

I’m using vanilla Ubuntu 14.04 x86-64, if that matters.

Regarding the IBUS_CAP_PREEDIT_TEXT thing, I was thinking it might be
better to forget about the SDL_TextEditingEvents altogether and just let
ibus handle it all.

The only real downside to this is that you can’t render the
edit-in-progress text in a pretty font at a certain size.

The problem is that probably the main use for SDL is games, and games
nearly universally have their own custom GUIs (and when they don’t,
they just use a standard GUI library for the dialogs, not SDL). This
means that being able to render the text on its own is pretty much a
must.

FWIW the list appears above FULLSCREEN_DESKTOP windows for me.

I’m using vanilla Ubuntu 14.04 x86-64, if that matters.

It works for me on both Ubuntu 12.04 x86-64 with MATE and Debian sid
i686 with Fluxbox. But I’m pretty sure this isn’t something that can be
fixed on the SDL side, just a window manager quirk.

The problem is that probably the main use for SDL is games, and games
nearly universally have their own custom GUIs (and when they don’t,
they just use a standard GUI library for the dialogs, not SDL). This
means that being able to render the text on its own is pretty much a
must.

That’s a good point.

Also it seems that the behaviour can be overridden by changing the
"embed_preedit_text" config option in gconf / gsettings. With this
option unchecked you get the same effect as if CAP_PREEDIT_TEXT wasn’t
advertised, even though it was. So the current code gets the best of
both worlds, sort of.

Alex.

2014-07-17 15:32 GMT-03:00, Alex Baines :

FWIW the list appears above FULLSCREEN_DESKTOP windows for me.

I’m using vanilla Ubuntu 14.04 x86-64, if that matters.

It works for me on both Ubuntu 12.04 x86-64 with MATE and Debian sid
i686 with Fluxbox. But I’m pretty sure this isn’t something that can be
fixed on the SDL side, just a window manager quirk.

Coming to think on it, I didn’t take the shell into the equation.
Using Gnome Classic here (no way I’m touching Unity, ever).

While yeah, it’s unlikely this can be fixed properly, the behavior is
pretty much unacceptable. If there’s no other option, we may need to
make SDL pass the candidate list to the program and have the program
itself draw it (just like it happens with the placeholder text). Is
that even feasible? Not like I like the idea, but doesn’t seem like
there’s anything else we can do.

It would be technically possible to get the candidate list info from
ibus required to draw one, but SDL has no API to pass this info to the
user so it would have to render it internally.

That poses a lot of problems, like would it use software or OpenGL to
render it? Would it use a different window for the list? How would it
interact with what the user application renders? I can see there being a
huge number of issues arising.

It’s certainly not something that can be done in the short term.

AlexOn 17/07/14 20:35, Sik the hedgehog wrote:

While yeah, it’s unlikely this can be fixed properly, the behavior is
pretty much unacceptable. If there’s no other option, we may need to
make SDL pass the candidate list to the program and have the program
itself draw it (just like it happens with the placeholder text). Is
that even feasible? Not like I like the idea, but doesn’t seem like
there’s anything else we can do.

2014-07-17 15:32 GMT-03:00, Alex Baines :

FWIW the list appears above FULLSCREEN_DESKTOP windows for me.
I’m using vanilla Ubuntu 14.04 x86-64, if that matters.

It works for me on both Ubuntu 12.04 x86-64 with MATE and Debian sid
i686 with Fluxbox. But I’m pretty sure this isn’t something that can be
fixed on the SDL side, just a window manager quirk.
Coming to think on it, I didn’t take the shell into the equation.
Using Gnome Classic here (no way I’m touching Unity, ever).

Hi,

I was an avid user of Ubuntu until the release of Unity.
Gnome 2.x rocked and Unity was just awful.
I use Kubuntu now, thanks!

JesseOn 07/17/2014 03:35 PM, Sik the hedgehog wrote:

While yeah, it’s unlikely this can be fixed properly, the behavior is
pretty much unacceptable. If there’s no other option, we may need to
make SDL pass the candidate list to the program and have the program
itself draw it (just like it happens with the placeholder text). Is
that even feasible? Not like I like the idea, but doesn’t seem like
there’s anything else we can do.


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

2014-07-17 16:53 GMT-03:00, Alex Baines :> On 17/07/14 20:35, Sik the hedgehog wrote:

It would be technically possible to get the candidate list info from
ibus required to draw one, but SDL has no API to pass this info to the
user so it would have to render it internally.

That poses a lot of problems, like would it use software or OpenGL to
render it? Would it use a different window for the list? How would it
interact with what the user application renders? I can see there being a
huge number of issues arising.

It’s certainly not something that can be done in the short term.

Honestly the only way this idea would work feasibly is by adding
functions (and possibly events) to the API. Remember, I basically said
to let the program do the drawing. This also probably requires having
the program tell SDL that it can draw the list on its own, for the
sake of backwards compatibility.

Making SDL show its own window could be an alternative too, after all
it already has its own window code for message boxes. But again, this
is not exactly trivial either.