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.

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!

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



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

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 wrote:

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:



--
Sylvain Becker
_______________________________________________
SDL mailing list

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

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:
_______________________________________________
SDL mailing list

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.

Alex

On 16/07/14 18:45, Sik the hedgehog wrote:
_______________________________________________
SDL mailing list

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:
_______________________________________________
SDL mailing list

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:
_______________________________________________
SDL mailing list

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:
_______________________________________________
SDL mailing list

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

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

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:

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).


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.
_______________________________________________
SDL mailing list

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

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


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


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

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

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

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 :/


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.


Oh OK, good to know.


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

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

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
- it's かみ if you wonder):
http://i.imgur.com/EdedWsy.png

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
_______________________________________________
SDL mailing list

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

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:
_______________________________________________
SDL mailing list

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

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

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


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.
_______________________________________________
SDL mailing list

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

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.


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.
_______________________________________________
SDL mailing list

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

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

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.
_______________________________________________
SDL mailing list

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

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.

Alex
_______________________________________________
SDL mailing list

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

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

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!

Jesse



_______________________________________________
SDL mailing list

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

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

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.
_______________________________________________
SDL mailing list

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

While not SDL per-se, it'll be nice to have newer releases of add-on
libraries like SDL_mixer, so bug fixes find their ways into more places.

I mainly think of bugs like this (fixed in hg):
https://bugzilla.libsdl.org/show_bug.cgi?id=2140
_______________________________________________
SDL mailing list

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

Hello,

This is not a showstopper bug, but may be important : I notice events
from my touch-screen were in pixels, whereas there were scaled to [0;
1] in Android and IOS.

https://bugzilla.libsdl.org/show_bug.cgi?id=2307

There is a patch to convert them to [0; 1] on X11. (note: it might
break some trackpad)
And also a patch to convert the fingertouch coordinates to the Logical
Render size, if needed. (I haven't tested it on android, but I will do
it).

Patches are tested to be working on linux/x11.

The idea is that there are more and more touch-screens on desktops,
laptops and that it would be better if the same events on different
platform were using the same convention.

Cheers,
Sylvain


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



--
Sylvain Becker
_______________________________________________
SDL mailing list

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

Hello,

I'd like to see bug https://bugzilla.libsdl.org/show_bug.cgi?id=2269 fixed. It is a showstopper to anyone who uses logical size and clipping rectangle as it doesn't consider the logicalsize x/y when set. Everytime black bars are needed (desired ratio != screen ratio), the clipping rectangle gets misplaced.


I wrote a patch for the OpenGL(ES(2)) renderer (which is attached to the bug), but I couldn't test if DirectX renderers has the same problem.



2014-07-21 3:49 GMT-03:00 Sylvain Becker:

Hey,

the software renderer most definitely has the same issue, as well as some others of its own:
https://bugzilla.libsdl.org/show_bug.cgi?id=2646


The patch there handles this by getting the intersecting rectangle of the viewport and the clipping rectangle.


I'd say there's a good chance that this needs to be done for (at least some of) the other renderers as well, although
I haven't checked the code.


Also, should the user be expected to clear the renderer to get neat black bars, or should that be handled implicitly by
the renderer? Different configurations produce different results in regards to the behaviour of the unrendered area, especially when resizing.
On my Intel/Mesa laptop, the software renderer (with the patch from the bug report) will render the black boxes reliably,
yet produces garbage with the OpenGL renderer. On my desktop with the nVidia blob, however, the behaviour is inverse:
the software renderer produces lots of garbage, but the OpenGL equivalent shows none. This is with the same shared library on both machines.


--
Melker Narikka


On Mon, Jul 21, 2014 at 6:26 PM, Leonardo Guilherme wrote:

Hey!

I'd really appreciate it if this were merged, since it's been sitting idly by for a good while:
https://bugzilla.libsdl.org/show_bug.cgi?id=2343

--
Melker Narikka


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

A crash bug on OS X was introduced since 2.0.3’s release, it’d be great to get that fixed before 2.0.4 goes live: https://bugzilla.libsdl.org/show_bug.cgi?id=2666


At the very least it would be good to get more eyes on the issue so we can come up with a usable fix. :)


I also have a small patch to fix compilation when SDL_syswm.h is included in modern Objective-C (or Objective-C++) code on OS X and iOS: https://bugzilla.libsdl.org/show_bug.cgi?id=2641

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

On 7/30/14, 1:33 PM, Alex Szpakowski wrote:

This one is in, thank you. I'll take a look at reproducing the other issue.

--ryan.


_______________________________________________
SDL mailing list

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

If this bug https://bugzilla.libsdl.org/show_bug.cgi?id=2500 could be
addressed prior to releasing 2.0.4 it would be great. It's certainly
not a show stopper though! It has a couple of patches that could fix
the issue. I am willing to make any corrections, test and submit new
patches if that makes it easier.

On Tue, Jul 15, 2014 at 1:23 PM, Sam Lantinga wrote:
_______________________________________________
SDL mailing list

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

On Tue, Jul 15, 2014 at 09:23:56AM -0700, Sam Lantinga wrote:

If this bug https://bugzilla.libsdl.org/show_bug.cgi?id=2667 could be
addressed prior to releasing 2.0.4 it would be great.

I've attached a suggested patch for it.

Cheers,

--
Regards,
Andreas
_______________________________________________
SDL mailing list

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

I've submitted patches for two iOS bugs.  I'd appreciate if these were reviewed for 2.0.4.

https://bugzilla.libsdl.org/show_bug.cgi?id=2661 - Screen size incorrect when changing orientations and resuming
https://bugzilla.libsdl.org/show_bug.cgi?id=2660 - SDL_IsScreenKeyboardShown doesn't respond to keyboard being dismissed 

Both patches are short and simple.

Thanks!
-Phil



On Thursday, July 31, 2014 10:50 AM, Andreas wrote:



On Tue, Jul 15, 2014 at 09:23:56AM -0700, Sam Lantinga wrote:

If this bug https://bugzilla.libsdl.org/show_bug.cgi?id=2667 could be
addressed prior to releasing 2.0.4 it would be great.

I've attached a suggested patch for it.

Cheers,

--
Regards,
Andreas
_______________________________________________
SDL mailing list

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

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

A couple of important issues that should really be addressed:

https://bugzilla.libsdl.org/show_bug.cgi?id=2650

https://bugzilla.libsdl.org/show_bug.cgi?id=2655

Cheers

Seems to be broken on OpenBSD 5.5 right now. I just tried to compile SDL from hg:

I would like to see https://bugzilla.libsdl.org/show_bug.cgi?id=2655
merged in, since it fixes several issues with the OSX coordinate system
_______________________________________________
SDL mailing list

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

Ugh, not again /o\
https://bugzilla.libsdl.org/show_bug.cgi?id=1658#c4
_______________________________________________
SDL mailing list

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

There are some patches at
https://bugzilla.libsdl.org/show_bug.cgi?id=2662 that could be good to
review & include before the release.

Alex.
_______________________________________________
SDL mailing list

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

I actually just ran into this bug in 2.0.3: https://bugzilla.libsdl.org/show_bug.cgi?id=2078


Certainly not critical, but it would be useful if this behaved consistently with the rest of the API.



On Sun, Aug 10, 2014 at 7:41 AM, Alex Baines wrote:

This bug is somewhat critical for certain countries/keyboard layouts (probably not the biggest ones though): https://bugzilla.libsdl.org/show_bug.cgi?id=2455

There is no patch because even though the issue is extremely simple to fix (either TranslateMessage is removed and its behavior reproduced fully or ToUnicode is replaced with WM_CHAR handling), there's the problem of me not knowing if either fix would break something. The original author of the change clearly had something in mind when WM_CHAR handling was partially replaced with ToUnicode and the related code, and if I could know what that was, I would most likely be able to make a patch myself.

libibus-dev is installed on the Linux buildbots (as of right now), so
we'll get some basic coverage on this code now.

--ryan.



_______________________________________________
SDL mailing list

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

On 8/5/14, 5:44 PM, tehcloud wrote:

I just fixed this a day or two ago, making the FreeBSD and OpenBSD
buildbots happy again. If this is still giving you trouble, please let
me know!

--ryan.



_______________________________________________
SDL mailing list

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

this one https://bugzilla.libsdl.org/show_bug.cgi?id=2704
an edge case, but not that uncommon (as you see, I found another person who had the same problem)
as people tend to have gamepads of the same brand, I think...

Hi,
Wondering if anyone else could try reproducing this: https://bugzilla.libsdl.org/show_bug.cgi?id=2713

SDL_WINDOW_FULLSCREEN produces a cropped window on Windows 8 w/ DPI scaling on above 100%. The test case is easy, just set 150% scaling in Windows settings, log out and log back in, run testgl2 included with SDL's source, and press Ctrl+Enter to go fullscreen, and the drawing will be off-center.

Would be interested if it is just my computer or happens on other versions of Windows too.

Thanks,
Eric

_______________________________________________
SDL mailing list

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

I made a patch for this bug that causes a "beep" sound every time Alt hotkeys are used in windowed Windows apps:
https://bugzilla.libsdl.org/show_bug.cgi?id=2669

OSX: Removed joysticks wrongly marked as closed when they are not.
This caused a few problems for me when handling hot-pluged joystick closing.

Just filed the bug with a patch included:
https://bugzilla.libsdl.org/show_bug.cgi?id=2738

Cheers!